Emmanuel started a blog series highlighting the process of migrating a Microsoft Stack from a local VM to Microsoft Azure as well as the experience we had. If you missed that find it here.
In this blog I will go deep into explaining how we implemented a CI/CD pipeline for the applications running on Azure App Service. Azure App Service is a fully managed "Platform as a Service" (PaaS) that integrates Microsoft Azure Websites into a single service, adding new capabilities that enable integration with on-premises or cloud systems. Azure App Service gives users several capabilities;
Due to these built in features, setting up a CI/CD pipeline was more straight forward unlike when using virtual machines. Using Azure App Service Migration Assistant, all the code was downloaded to a central location which will be used as a development environment. This is because the code base was very huge to download on a personal machine for all the applications.
We then created a GitHub Team account that helps create unlimited private repositories and set team and user permissions. GitHub is a web-based version-control and collaboration platform for software developers. It is delivered through a software-as-a-service (SaaS) and can act as a secondary storage for your codebase.
We pushed all the code to the new GitHub repositories on the master branch. You can have different configuration of test branches, feature branches etc as required.
Next thing we did was configure the pipeline from Azure Portal. Below are the steps to follow to implement that.
App service followed by the
deployment slots. Click on Add new slot as shown below
Provide a name for the deployment slot and
configure source as the production environment. This setting helps set up the environment in a similar way to the production environment hence saving you time with basic configurations for the
To configure the
source control, click on deployment options. Choose
GitHub as the source, select the
authorization credentials and the
GitHub repository as well as the
branch to build from as shown below.
This configuration enables the changes pushed to GitHub to be automatically pushed to a
testing/staging slot. Azure will start pulling the changes you have made on GitHub for the very first time and subsequently listen to new commits in the configured GitHub repository.
To see if the changes are getting pulled from GitHub, you can click on the Deployment options on the menu and you will be able to see all the changes/commits that have been made and if they were successfully deployed or not.
```**Note:**``` Do not interfere with the pipeline when it’s building. Interference could be in form of pushing another chunk of changes to GitHub before the previous changes have been pulled to test/staging site.
swapand select the
destination (production)and the changes will appear on the production application without any downtime.
With this set up, it is very easy to make new changes in your code and move to production without any downtime. More importantly, you are able to test your code for any bugs on the staging environment before swapping the code to production. A CI/CD pipeline also facilitates collaboration where you can have multiple developers working on the same project simultaneously without breaking your production code.
In the last blog series, Emmanuel will share highlights on lesson learnt from this experience and how to swiftly overcome some of the challenges that came our way in the migration. He will also be comparing Azure and AWS cloud platforms when doing migrations. If you need help with CI/CD pipelines and DevOps in general do reach out.
To make a comment you have to login