It’s been more than 3 months since I’ve been out of the role and responsibilities as a DevOps Engineer. As such, I planned to post a few knowledge checks on the next few weeks. A knowledge check about DevOps practices that will greatly beneficial to my journey as Full-stack Web Developer focusing on Microsoft technology stack.
On DevOps, the first thing I learned is an automated build and deployment of an application which commonly known Continuous Integration (CI) and Continuous Deployment (CD).
Looking at the above picture, I depicted a high-level approach for CI/CD implementation. Feel free to give your feedback on it (or violent reaction) and I will gladly appreciate a different perspective.
On that approach, I am simulating a case wherein there are multiple environments involved (Development, Testing, and Production) and hosting the web application in Microsoft Azure App Service. In that simulation, I also looking into perspective that there are dedicated Developers, Solution Manager, and a DevOps Engineer.
Developers are the bottom players primarily involved in the actual development and bug-fixing of the application. Solution Manager is the one responsible for managing the code repository and ensuring developer are following a standard for promoting change to the repository in order to have a better change history on code solution. Both the Developer and Solution Manager can be both performed by an individual or by separate members of the Development Team. And lastly, the DevOps Engineer is the primary responsible implementing CI/CD in order to promote all approved application changes into each environment.
The approach has five (5) important key areas:
- Development Team – An area on the approach where the developer follows a certain standard for promoting code changes into the repository and changes are handled by Solution Managers including code-merge conflicts and promoting changes from one environment to another.
- Repository – An area of the approach wherein selecting the appropriate version control system is a must. The most popular version control system is Git (which I also preferred) and for those familiar with Microsoft tools and services, there is also the Team Foundation Version Control (TFVC) which is part of services under Azure DevOps (formerly known as VSTS). Git version control can be used on your local workstation or you could utilize online providers such as GitHub or Azure DevOps.
- Build Pipeline – An area of the approach where automated application build and testing are implemented using Azure DevOps services. This pipeline can be integrated with the repository which will be triggered whenever changes have been added on the repository. An automated test can also be incorporated such as Unit Test and UI Test utilizing 3rd part applications and integrations. You can learn more about Azure DevOps on the official Microsoft Documentations through this link.
- Release Pipeline – An area where an approach of how to promote changes into a selected environment will be implemented using Azure DevOps services. There are multiple ways or approaches to implementing automated deployment – either one pipeline for all environments or one pipeline per environment depending on the situation. A post-approval or pre-approvals can be also implemented. You can learn more about Azure DevOps on the official Microsoft Documentations through this link.
- App Service – An area where it depicts the destination of the application which is part of Microsoft Azure cloud services. On this area of the above approach, each environment should have corresponding App Service that holds the deployed applications. There are also multiple ways to configure Microsoft Azure services to handle multiple environments depending on the needs and client requirements. You can visit this link to learn more about Microsoft Azure.
The above approach has been simulated based on several small and big projects I worked on. I am still working on expounding this high-level approach with consideration of a specific case of a situation or certain client requirements. What do you think I am missing on the above high-level CI/CD approach?
I am currently working on content with a more detailed implementation of CI/CD using Microsoft tools and services. I will probably be able to share it in the next few weeks and planned to share as an article in my LinkedIn profile.
You can visit my LinkedIn profile when you have time to know more about my professional work experience and skills gained over time.
Thanks and have a nice week ahead!