Skip to main content

Release gates

Release gates give you more control over the start and completion of the deployment pipeline. They're often set up as pre-deployment and post-deployment conditions.

Think of downtime of a database server or an update of an API. It takes much time and effort, and the only thing needed is a signal if the release can continue. 

You can create a mechanism where people press a button on a form when the release can't advance. 

When the release starts, it checks the state of the gate by calling an API. If the "gate" is open, we can continue. Otherwise, we'll stop the release.

By using scripts and APIs, you can create your release gates instead of manual approval. Or at least extending your manual approval.

Approvals and gates give you more control over the start and completion of the deployment pipeline.

Whereas, a quality gate is the best way to enforce a quality policy in your organization. It's there to answer one question: can I deliver my application to production or not?

A quality gate is located before a stage that is dependent on the outcome of a previous stage. A quality gate was typically something that a QA department monitored in the past. They had several documents or guidelines, and they verified if the software was of a good enough quality to move on to the next stage.

We need to reconsider the notion of quality gates and see how we can automate these checks as part of our release pipeline

Many quality gates can be considered.

  • No new blocker issues.
  • Code coverage on new code greater than 80%.
  • No license violations.
  • No vulnerabilities in dependencies.
  • No further technical debt was introduced.
  • Is the performance not affected after a new release?
  • Compliance checks

    • Are there work items linked to the release?

    • Is the release started by someone else as the one who commits the code?

Defining quality gates improves the release process, and you should always consider adding them.


Navigation

Comments

Popular posts from this blog

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

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

Enable Trace on Dynamcis 365 on premise using PowerShell

Enable trace settings through Windows PowerShell Note These changes made in Windows PowerShell do not update the Registry. These changes update the DeploymentProperties and ServerSettingsProperties tables in the MSCRM_CONFIG database. Register the cmdlets 1.      Log in to the administrator account on your Microsoft Dynamics CRM server. 2.      In a Windows PowerShell window, type the following command: Add-PSSnapin Microsoft.Crm.PowerShell To obtain a list of the current settings, type the following command: Get-CrmSetting TraceSettings Set the trace settings 1.      Type the following command: $setting = Get-CrmSetting TraceSettings 2.      Type the following command to enable tracing: $setting.Enabled=$True 3.      Type the following command to set the trace settings: Set-CrmSetting $setting 4.      Type the following command...