Posted on Leave a comment

Automatic rollback procedure for Azure DevOps

Azure devops pipelines provide a variety of tools for automated procedures. One mechanism that administrators can build using the YAML structure is an automated rollback mechanism during a deployment.

This means that after a deployment you can revert the previous state using your YAML tasks without having to redeploy. Another case would be a broken deployment which can be identified by monitoring tools and then a validation could approve or not the final release. This is exactly depicted in the below image. After releasing a version we have a validation step that requires manual approval from an administrator. If the validation is approved the release will proceed else the rollback will be triggered.

This mechanism is described below with YAML. Release stage includes release, validation and rollback jobs. Release job performs the actual release. Validation will depend on release job and will continue only if is approved. The rollback job will run only if validation failed which means that an administrator canceled the approval.

trigger: none
pr: none

stages:

- stage: releaseStage
  jobs:

  - deployment: release
    displayName: Release
    environment:
      name: dev
      resourceType: VirtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
            - task: PowerShell@2
              displayName: hostname
              inputs:
                targetType: 'inline'
                script: |
                    deployment script here...
  
  - job: validation
    dependsOn: release
    pool: server
    steps:
    - task: ManualValidation@0
      inputs:
        notifyUsers: 'admin@domain.com'
        instructions: 'continue?'
        onTimeout: reject

  - deployment: rollback
    displayName: rollback
    dependsOn: validation
    condition: failed()
    environment:
      name: dev
      resourceType: VirtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
            - task: PowerShell@2
              displayName: rolling back
              inputs:
                targetType: 'inline'
                script: |
                    rollback script here..
                    Write-Host "rollback"

When the release can be verified from the administrator the rollback will be skipped. This is the case when the validation is approved from the user.

Validation task will ask the user for a review.

On the other hand if validation is rejected the rollback stage will run.

Posted on Leave a comment

Automate your deployments with .gitlab-ci.yml and Openshift – Gitlab Devops

This article describes how to create a Gitlab CI/CD pipeline using gitlab-runner and docker as the build strategy in order to deploy microservices on Openshift.

On my previous articles I have explained how to create your own hosted gitlab instance and deploy a single CI/CD pipeline using gitlab-runner. The whole setup was based on containers, as a result the infrastructure needed can be deployed on Openshift as well.

The pipeline consists of three steps, housekeeping, staging and cleaning. It is based on the default example that gitlab provides and uses oc commands to communicate with Openshift. It is configured to be triggered only for develop branch and every time a new commit is added the build starts.

  • The housekeeping step will remove every resource that has been created from a previous build.
  • The staging step will build the microservices based on your Dockerfile instructions as the build strategy is set to docker.
  • The cleaning task will remove the building pods that have been created from Openshift.

The housekeeping step is allowed to fail so that if no resources are found, the building step will continue its work.

You can see below a simple run of the pipeline.

You can find the code of the pipeline in the below repository:

https://github.com/geralexgr/gitlab-cicd-openshift-deploy/blob/main/gitlab-ci.yml