Background
This is the continuation of Continuous Deployment of Multi-Container app in Azure using VSTS and Docker. So far we have covered following topics
- Part 1 – Overview of different tools and technologies we will be using during this series
- Part 2 – Setup VSTS Continuous Integration (CI) build for DotNet Core 2.1 multi-container app
- Part 3 – Integrate DockerHub container registry with VSTS CI build to publish Docker images
- Part 4 – Provision Docker Swarm cluster in Azure using ACS Engine
- Part 5 – Create SSH Endpoint to Docker Swarm running in Azure
- Part 6 – Create Release Pipeline using VSTS for Multi-Container app
- Part 7 – Deploy Multi-Container apps to Swarm cluster in Azure using VSTS
In this post we will be looking at enabling the Continuous Deployment feature of VSTS. In the previous post, we had to manually initiate the deployment step and the release creation step. The idea is to deploy to an environment as soon as an Artifact is published after a successful build. In the process we will also put the complete CI CD pipeline to test.
As part of this post we will be performing following steps
- Enable Continuous Deployment trigger
- Modify source code to trigger CI CD pipeline
- Verify the CD pipeline
Enable Continuous Deployment trigger
Continuous Deployment is an important part of DevOps journey for teams staring to move into full CI CD mode. It allows teams to continuously deploy changes to an environment as and when the development team makes changes to the source code. Lets start with checking the current state of our website. If I browse the public DNS of the agent node, I am presented with the home page
I would like to make a small change to the code and would like to see the changes deployed to the environment automatically. To do that we need to change the way code is currently being deployed. In the last post, we manually triggered the release and then the deploy phases. VSTS provides us the facility to automate this part. Go to the release definition and edit it.
Under the Pipeline section, click on the Continuous Deployment trigger option under the Artifacts section. On the blade which opens up, Enable the flag. We are almost ready to see all our changes continuously deployed to the Swarm cluster. Lets test this feature.
Modify source code to trigger CI CD pipeline
In the MVC project, I have a Carousel control defined inside a div tag in Index.cshtml file. Currently this piece of code is commented. Let me uncomment the whole div and check in the changes. This should trigger a CI build.
Note down the latest build number 66 which is in progress. Once the build is successfully completed, the Artifacts will be published to the drop location. This should trigger the Release process.
Verify the CD pipeline
We can see from the above screenshot that Release-22 is triggered by the continuous deployment trigger based on build number 66. Compare this with Release-17 which was manually triggered by me. Wait for the release to complete. We can verify from the release log that the changes were deployed successfully to Docker Swarm.
Notice the highlighted section. The log clearly indicates that the two services have been updated. If you go back to the pervious post and look at the log, it says creating service. This is a nice feature of docker stack deploy command.
It handles the creation or updating of services for us. Because of this we are able to use the same script for all deployment scenario. For fresh deploy it creates the required services based on the description specified in the docker compose file. Updates are also handled effectively provided the stack name is same between the two deployments. In our case we are using the stack name as webapp.
The last part is to browse the website again and verify that the carousel control is visible.
Sure enough we have achieved the goal. All this process took about 4 minutes to complete right from the time I committed the changes to GitHub. Isn’t that amazing? You can compare that with the amount of time it would take if you were to do each of the steps related to building the docker images, tagging each of the image, pushing them to DockerHub, login to Docker Swarm master node and run the deploy command. I am pretty sure it will be more than 4 minutes.
More than the amount of time it takes, the whole process is made repeatable. Anybody who has access to the VSTS build and Release definitions can understand the flow. It makes life so much easier for developers. By automating these release and deployment steps, we can focus on building the real business functionalities.
Conclusion
As I have been stressing throughout this series, VSTS provides us all the tool required to embark on the journey to DevOps. In this example we saw how making a change to the source code of a containerized app is pushed all the way from developer checking in the code to GitHub repo, CI build publishing the Docker images to DockerHub container registry. The the Continuous Deployment release pipeline picking up the latest artifacts and deploys the latest version of the container to Docker Swarm hosted in Azure using Azure Container Service engine. All this is managed via VSTS build and release pipelines.
This concludes the major part of the things I wanted to cover as part of this series on Continuous Deployment of Multi-Container apps. All the source code is available in the GitHub repository. I feel that this is just the tip of the iceberg and there could be many more things which can be added to the pipelines in bits and pieces.
Two things which come to my mind straight away are integration of automated test and managing the secrets more effectively. I will make those modifications and share it as and when they are ready. Until next time code with passion and strive for excellence.
No comments:
Post a Comment