Skip to main content

Explore Release Pipeline

A release pipeline takes artifacts and releases them through stages and finally into production.


The first component in a release pipeline is an artifact:

  • Artifacts can come from different sources.
  • The most common source is a package from a build pipeline.
  • Another commonly seen artifact source is, for example, source control.
  • A manual trigger, where people start to release by hand.
  • A scheduled trigger, where a release is triggered based on a specific time.
  • A continuous deployment trigger, where another event triggers a release. For example, a completed build.

Furthermore, a release pipeline has a trigger: the mechanism that starts a new release.

A trigger can be:

Another vital component of a release pipeline is stages or sometimes called environments. It's where the artifact will be eventually installed. You can have many stages (environments); part of the release strategy is finding the appropriate combination of stages.

Another component of a release pipeline is approval. People often want to sign a release before installing it in the environment. In more mature organizations, this manual approval process can be replaced by an automatic process that checks the quality before the components move on to the next stage.

Finally, we have the tasks within the various stages. The tasks are the steps that need to be executed to install, configure, and validate the installed artifact.

 

Navigation


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 > ...

Release approvals

Continuous Delivery is all about delivering on-demand.  But, as we discussed in the differences between release and deployment, delivery, or deployment, it's only the technical part of the Continuous Delivery process.  It's all about how you can technically install the software on an environment, but it doesn't say anything about the process that needs to be in place for a release. Release approvals don't control  how  but control  if  you want to deliver multiple times a day. Manual approvals also suit a significant need. Organizations that start with Continuous Delivery often lack a certain amount of trust. They don't dare to release without manual approval. After a while, when they find that the approval doesn't add value and the release always succeeds, the manual approval is often replaced by an automatic check. Things to consider when you're setting up a release approval are: What do we want to achieve with the approval? Is it an approval that we need...

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. ...