<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pipeline on Romano Roth</title><link>https://romanoroth.com/en/tags/pipeline/</link><description>Recent content in Pipeline on Romano Roth</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Romano Roth</copyright><lastBuildDate>Wed, 11 Jan 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://romanoroth.com/en/tags/pipeline/index.xml" rel="self" type="application/rss+xml"/><item><title>GitHub DevSecOps Part 2: Creating a Simple Project and Your First Workflow</title><link>https://romanoroth.com/en/blogs/github-devsecops-creating-a-project/</link><pubDate>Wed, 11 Jan 2023 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/github-devsecops-creating-a-project/</guid><description>&lt;p>Before we plug security tools into anything, we need a repository, a pipeline, and a working build. In Part 2 of our GitHub DevSecOps series, Patrick Steger and I create a private GitHub repo for a small Java Spring Boot service, enable GitHub Actions, and wire up a two-workflow pipeline that compiles the code and runs the unit tests. This is the skeleton everything else in the series hangs on.&lt;/p></description></item><item><title>GitLab vs. GitHub: DevSecOps Pipeline</title><link>https://romanoroth.com/en/blogs/gitlab-vs-github-devsecops/</link><pubDate>Wed, 28 Dec 2022 11:25:25 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-vs-github-devsecops/</guid><description>&lt;p>by &lt;a href="https://www.linkedin.com/in/romanoroth/" target="_blank" rel="noreferrer">Romano Roth&lt;/a> and &lt;a href="https://www.linkedin.com/in/patrick-steger-ch/" target="_blank" rel="noreferrer">Patrick Steger&lt;/a>&lt;/p>
&lt;p>&lt;figure>&lt;img
 class="my-0 rounded-md"
 loading="lazy"
 decoding="async"
 fetchpriority="auto"
 alt=""
 width="1280"
 height="720"
 src="https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1_hu_21f4da4944ff7974.png"
 srcset="https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1_hu_21f4da4944ff7974.png 800w, https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1.png 1280w"
 sizes="(min-width: 768px) 50vw, 65vw"
 data-zoom-src="https://romanoroth.com/images/blog/gitlab-vs-github-devsecops-inline-1.png">&lt;/figure>
&lt;/p>
&lt;p>This video series will show you how to build up an enterprise-ready DevSecOps Pipeline with GitLab and GitHub and compare the two platforms.&lt;/p></description></item><item><title>GitLab DevSecOps Part 2: Creating a Simple Project and Your First Pipeline</title><link>https://romanoroth.com/en/blogs/gitlab-devsecops-creating-a-project/</link><pubDate>Wed, 10 Aug 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/gitlab-devsecops-creating-a-project/</guid><description>&lt;p>Before we can shift any security checks left, we need a project, a repository, and a pipeline that actually builds something. In Part 2 of our GitLab DevSecOps series, Patrick Steger and I log into GitLab, create a new .NET Core project from a template, and look at the &lt;code>.gitlab-ci.yml&lt;/code> file that GitLab generates for us — including the build and test jobs that will become the foundation for everything we add later.&lt;/p></description></item><item><title>What is Release on Demand?</title><link>https://romanoroth.com/en/blogs/what-is-release-on-demand/</link><pubDate>Wed, 11 May 2022 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-release-on-demand/</guid><description>&lt;p>Release on Demand is the final step in the SAFe for DevOps continuous delivery pipeline, and it is the step that ties everything together. In this video, I walk through how Release on Demand works, why separating deployment from release is so powerful, and how the whole pipeline enables organizations to build the right thing right.&lt;/p></description></item><item><title>What Is Continuous Deployment (CD)?</title><link>https://romanoroth.com/en/blogs/what-is-continuous-deployment/</link><pubDate>Thu, 06 Aug 2020 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-continuous-deployment/</guid><description>&lt;p>Continuous Deployment is the final, most aggressive step in the CI/CD progression. CI proves the code builds and the unit tests pass. Continuous Delivery proves the artifact works in a production-like environment. Continuous Deployment removes the last manual checkpoint: if every test along the way is green, the change goes straight to production. No &amp;ldquo;deploy&amp;rdquo; button, no Friday-afternoon release window, no human in the loop for the final step.&lt;/p></description></item><item><title>What Is Continuous Delivery (CD)?</title><link>https://romanoroth.com/en/blogs/what-is-continuous-delivery/</link><pubDate>Wed, 05 Aug 2020 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-continuous-delivery/</guid><description>&lt;p>Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.&lt;/p></description></item><item><title>What is CI/CD?</title><link>https://romanoroth.com/en/blogs/what-is-ci-cd/</link><pubDate>Tue, 04 Aug 2020 18:49:47 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-ci-cd/</guid><description>&lt;p>In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.&lt;/p></description></item><item><title>What Is Continuous Integration (CI)?</title><link>https://romanoroth.com/en/blogs/what-is-continuous-integration/</link><pubDate>Tue, 04 Aug 2020 00:00:00 +0000</pubDate><guid>https://romanoroth.com/en/blogs/what-is-continuous-integration/</guid><description>&lt;p>In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.&lt;/p></description></item></channel></rss>