OpenHackDevOps Experience

Date published: October 18, 2022

I was selected to attend the Microsoft OpenHackDevOps event in London Office. It was my first OpenHack event, and I did not know what to expect from it. This post aims to document my experience and give insights into the Microsoft Open Hack 3-day training session.

Project Overview

The training used a fictitious insurance company that allows customers to assess their driving skills. The environment consists of the Azure App Service in Linux:

• Trips - connected to the client application
• POI (Trip Points of Interest) –Points of interest on trips
• User – This is a Node.JS for the users of the client application
• User-Java - Java that routes for the client application users.
• Mobile Apps - It is for iOS and Android devices that displays driving trip data

Overview Architecture

Day 1 Presentation on GitHub

Before we got started, we had a presentation on end-to-end intern sourcing and secure deployment with GitHub by Chris Reddington. This session discussed the security development lifecycle and demonstrated the process using GitHub Actions, co-pilot and code space.

Setting Azure DevOps Enviornment and deployment of Infrastructure

On day 1, we put into different teams with different people with various technical skills.

We first had to choose as a team whether we wanted to use GitHub or Azure DevOps for our CI/CD deployment. After discussing it with colleagues in the group, we decided to go with Azure DevOps for our Board for tasks and use Terraform for our infrastructure as a code tool.

We also used the free Microsoft teams to communicate with other team members. The first thing we had to do is setting up the Azure DevOps by following the Microsoft GitHub repo here https://github.com/microsoft/OpenHack/tree/main/byos.

In this challenge, we completed the following:

• Creation of Azure DevOps Organisation
• Change to Agile project process
• Customise Azure DevOps board with tasks
• Add work items using the Work Items

In the second challenge, we had to implement a branching policy in Azure DevOps to prevent any code changes from being committed to the main branch without being reviewed by someone. We assigned everyone to be an owner of API services and implemented a branching policy to help protect the team code quality and enforce the standards required for a successful branch merge.

The branch policy we created are:

• Require a minimum number of reviewers – 2
• Disable “Allow users to approve own changes.
• Checked for “Linked Work Items” required
• Build Validation: - Each API had its validation to complete
• Automatically included reviewers – The individual that is the owner of an API

Once we had successfully set up the branching strategy, the next challenge we had to do was to deploy the Infrastructure to Azure using terraform and create a validation process. In this challenge, we set up the deployment infrastructure using a pipeline, implemented the validation process via pull request workflow and used the checkov static code analysis to validate code.

Day 2 Implement Continuous Integration and Continuous Deployment

After we set up the Azure DevOps environment and infrastructure deployed to Azure, the next task was to ensure we met the Implement Continuous Integration and Deployment CI/CD process to complete the challenge.

• Ensure workflow triggered API on a Pull Request (PR) only when changes are committed to the main. -Created pipeline to push container images via one per API to Azure Container Registry. We created this pipeline by ensuring it uses the latest image tag for referencing the image. We completed four of the API.

• Pipeline ensures that the code deploys to the Azure App Service staging slot every time code goes to the main.

Day 3 Implement a Blue/Green and DevSecOps basics

On day 3, we had to implement a blue/green deployment for each API service. We had to ensure that each deployment was automatically deployed to a staging environment to production with zero downtime. Afterwards, we had to use triggers to determine whether it was safe to swap to the new version and select the version of the container in production (green) and the version of the container in staging (blue).

After completing the last challenge, the next challenge is clearing all the secrets in terraform code. We did this to ensure all the app services with API were set up and configured to get secrets from Azure Key Vault. However, to complete this, we had to use variable groups so it authenticated to the key vault.

In the evening, we had some free time left, and our coach gave us the time to learn sometime new in Azure. I used my time to look into Azure Grafana and how it is used for monitoring resources.

Conclusion

In the end, after a fantastic 3-day Open Hack, I would highly recommend this to anyone to attend; who would like to improve their knowledge or is new to DevOps. Each of the challenges will be harder, and you will learn more. This event is an excellent way to learn more about the blue/green deployment concept.

I think my team comprises myself and another experienced team member who previously used Azure and Azure DevOps because two of my team member were new to Azure. I was the only person who knew and used terraform. However, you will get assigned a Microsoft proctor who you can use to get ideas and assistance if required. I was grateful that I knew my protector previous Microsoft Event.

I look forward to my next event and hear you with a special quote from Microsoft “Learn from each other and the team. Divide and Conquer” :)