Skip to main content

What is Continuous Delivery?

Continuous delivery (CD) is a set of processes, tools, and techniques for rapid, reliable, and continuous software development and delivery.

It means that continuous delivery goes beyond the release of software through a pipeline. The pipeline is a crucial component and the focus of this course, but continuous delivery is more.

Look at the eight principles of continuous delivery:

  • The process for releasing/deploying software must be repeatable and reliable.
  • Automate everything!
  • If something is difficult or painful, do it more often.
  • Keep everything in source control.
  • Done means "released."
  • Build quality in!
  • Everybody has responsibility for the release process.
  • Improve continuously.
  • Software architecture (monoliths are hard to deploy).
  • Testing strategy (manual tests don't scale well).
  • Organization (separated business and IT departments don't work smoothly), and so forth.
Continuous delivery is an enabler for DevOps. DevOps focuses on organizations and bringing people together to build and run their software products.
Continuous delivery is a practice. It's being able to deliver software on demand. Not necessarily 1000 times a day. Deploying every code change to production is what we call continuous deployment.
To achieve this, we need something like Continuous Delivery.

To deploy more often, we need to reconsider our:



We need to move towards a situation where the value isn't piled up and released all at once but flows through a pipeline.
So, work must be prioritized in the right way. As you can see, the pipeline has green and red outlets. These are the feedback loops or quality gates that we want to have in place. A feedback loop can be different things:

  • A unit test to validate the code.
  • An automated build to validate the sources.
  • An automated test on a Test environment.
  • Some monitor on a server.
  • Usage instrumentation in the code.
Every single piece of workflow through the pipeline until it ends up in the tray of value.
Last year around 80% of all companies claimed that they adopted Scrum as a software development practice. Using Scrum, many teams can produce a working piece of software after a sprint of maybe two or three weeks.

Comments

Popular posts from this blog

PowerShell: Get Actual Error

I was having hard time to find the reason why I was not able to find a custom method in a .Net DLL. Find your Assembly: PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts > [appdomain]::currentdomain . getassemblies() | Where - Object FullName - Match "MyAssembly" GAC Version Location --- ------- -------- False v4 . 0.30319 C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts\Tools\MyAssembly . dll PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts & gt; $ a = [appdomain]::currentdomain . getassemblies() | Where - Object FullName - Match "MyAssembly" PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts & gt; $ a GAC Version Location --- ------- -------- False v4 . 0.30319 C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts\Tools\MyAssembly . dll When I was trying to get the Types in the assembly, I was getting the exception: PS C:\vstsagent\A1\_work\r1\a\_DevOps_CI\Scripts > ...

What is release, and what is a deployment?

T o understand the concepts and the technical implementation in many tools, you need to know how tool vendors define the difference between a release and a deployment. A  release  is a package or container containing a versioned set of artifacts specified in a release pipeline in your CI/CD process. It also includes a snapshot of all the information required to carry out all the tasks and activities in a release pipeline, such as: The stages or environments. The tasks for each one. The values of task parameters and variables. The release policies such as triggers, approvers, and release queuing options. On the other hand,  Deployment  is the action of running the tasks for one stage, which results in a tested and deployed application and other activities specified for that stage. Starting a release starts each deployment based on the settings and policies defined in the original release pipeline. There can be multiple deployments of each release, even for one stage. ...

Considerations for deployment to stages

When you have a clear view of the different stages you'll deploy, you need to think about when you want to deploy to these stages.  Continuous Delivery is about deploying multiple times a day and can deploy on-demand. When we define our cadence, questions that we should ask ourselves are: Do we want to deploy our application? Do we want to deploy multiple times a day? Can we deploy to a stage? Is it used? A typical scenario we often see is continuous deployment during the development stage. Every new change ends up there once it's completed and builds. Deploying to the next phase doesn't always occur multiple times but only at night. When designing your release strategy, choose your triggers carefully and consider the required release cadence. Some things we need to take into consideration are: What is your target environment? Does one team use it, or do multiple teams use it? If a single team uses it, you can deploy it frequently. Otherwise, it would be best if you were a ...