In today’s rapidly changing digital environment, where fast-paced organizations are now demanding fast and reliable software delivery; it is at this point that DevOps plays a critical role. In essence, DevOps allows the relationship between development and operations to flourish so as to allow those working on your team to take ideas and convert them into deployable outputs (in an agile manner) while maintaining high levels of accuracy. However, for true seamless deployments, you need both the tools required to accomplish this task and a well-defined plan that synchronizes the requirements, automation, testing and ongoing monitoring.
In addition to providing guidance on the technical aspects of implementing DevOps using GitHub CI and Azure Cloud, we will include examples, context and best practices that will help in taking the right architecture for your code.
Understanding the Core of DevOps
DevOps is not just a methodology, but a cultural and technical trend that integrates both software development and IT operations to develop applications in a faster and more reliable manner.
It eliminates conventional silos and creates an organizational culture of teamwork in which developers, testers and system administrators are working towards a common objective of delivering continuous value.
Setting up your Pipeline
Before we write code, we will need:
-
GitHub Repository containing your application's code.
-
Azure Subscription that contains an existing Resource Group.
-
Service Principal to allow GitHub to Deploy your application to Azure (store as AZURE_CREDENTIALS secret on GitHub).
Once you have these, you are ready to begin automating your workflow.
Example: Dynamic GitHub Actions Environment per Feature Branch
In this example, the automated workflow includes building, testing, and deploying your application to Azure. With each feature branch, you create an isolated environment.
name: CI/CD Pipeline
on:
pull_request:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
- run: npm install
- run: npm run build
test:
runs-on: ubuntu-latest
needs: build
strategy:
matrix:
node-version: [16, 18]
steps:
- uses: actions/checkout@v3
- name: Run Tests
run: npm test
deploy:
runs-on: ubuntu-latest
needs: test
steps:
- uses: actions/checkout@v3
- name: Azure Login
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Deploy Infrastructure with Bicep
run: |
az deployment group create --resource-group my-rg --template-file main.bicep --parameters environment=feature-${{ github.ref_name }}
- name: Deploy App to Azure App Service
run: |
az webapp deploy --resource-group my-rg --name myapp-${{ github.ref_name }} --src-path ./build
There are 3 stages defined in this YAML file: Build, Test and Deploy.
When you make changes to a branch and then commit them, or when you open a Pull Request, these changes trigger GitHub Actions to run this automated workflow.
Then, during the deployment phase of this workflow, it will use your credentials to log onto Azure and will also deploy both your app and your infrastructure.
Infrastructure as Code (IaC): Building Reproducible Environments
Understanding IaC
Infrastructure as Code (IaC) transforms the ways of team management and infrastructure provisioning. Rather than using manual configuration of servers, networks and databases, IaC enables engineers to configure infrastructure with code, making it consistent and repeatable. This has the benefit of removing configuration drift, accelerating environment setup, and agile infrastructure management as nimble as the software development itself.
Popular IaC Tools
Contemporary DevOps groups are depending on IaC solutions, such as Terraform, Ansible, and AWS CloudFormation, to automate the provisioning and configuration. These tools employ declarative syntax, allowing teams to describe their desired state of infrastructure, version it, and deploy the same environments to development, staging, and production with a few commands.
GitHub Actions and IaC together
You have created a workflow that is described in the YAML file. Now, after creating this workflow, you might be wondering - Why did we go from YAML to Infrastructure As Code (IaC) all of a sudden?
Your application's workflow is defined by the YAML file you created for automation which dictates your build-test-deploy process.
However, your application will need an environment on the cloud to run in (i.e., servers, databases, etc.). This is where Infrastructure as Code (IaC) comes into play.
-
You commit your code to GitHub.
-
GitHub Action workflows are triggered — your app is built/tested.
-
Azure CLI commands are run from within your pipeline to apply your Bicep (IaC) template
-
The Bicep template tells Azure what to provision for your infrastructure.
-
After Azure has provisioned your resources, your app will be automatically deployed to those resources.
With this method, your application code and infrastructure grow simultaneously across all of your environments.
Example: Azure Bicep Module
This File (main.bicep) Creates A Basic Web Application
You Can Use This Framework Across All Of Your Environments - Dev, Staging And Production.
param environment string
resource appService 'Microsoft.Web/sites@2022-03-01' = {
name: 'myapp-${environment}'
location: resourceGroup().location
kind: 'app'
properties: {
serverFarmId: '/subscriptions/.../resourceGroups/my-rg/providers/Microsoft.Web/serverfarms/myplan'
}
}
The moment you run your GitHub Action with az deployment group create, Azure will read through this file and create all of the necessary resources for you.
Ensuring Security in DevOps (DevSecOps Approach)
Embedding Security in Every Stage
Security is no longer a luxury in contemporary software delivery, but rather something that should be integrated at each stage of the DevOps pipeline. The combined methodology is known as DevSecOps, which is used to secure code, infrastructure, and configurations.
Through early implementation of automated security checks, organisations are in a position to detect vulnerabilities during early stages before they get to production and low-risk and remediation costs are incurred.
Tools and Practices
The use of security automation is critical in the context of the constant protection that has to be maintained. Snyk, SonarQube, and Aqua Security are tools that are used to identify vulnerabilities in code dependencies, container images, and configurations.
Furthermore, sensitive credentials cannot be accessed by unauthorised users due to the proper management of secrets using vaults or encrypted stores.
By implementing such tools into CI/CD pipelines, teams can follow a security-non-slow path in development by maintaining security.
Conclusion
The flawless deployments of DevOps change how organisations develop software. Since often defined requirements to Infrastructure as Code and proactive feedback loops, each provides a way to help deliver more reliable releases at a faster pace.
Efficiency, stability, and scalability can be attained by teams that adopt a DevSecOps attitude and address the obstacles that typically occur during deployment.
With the current changes in DevOps, these best practices will help organizations to be agile, competitive and be able to produce high-quality software that will satisfy user expectations all the time.