AZ-400 Lab1: Deploy Azure App with Git Hub Code using Azure Pipeline Build & Release | TechPledge
For Details Visit Us: https://www.techpledgeconsulting.com/
Email: [email protected]
Whats up: +91-7676-7 03-141
======================================================
Software must be written, tested and deployed into a production environment. To do so, in an automated fashion, developers and DevOps build CI/CD pipelines or build/release pipelines.
A pipeline allows developers, DevOps teams and others to produce and deploy reliable code. In the Microsoft realm, the way to build a pipeline is with Azure DevOps with a feature called Azure Pipelines.
========================================================================
In the beginning of the project or product it starts with an idea or some business requirement and after going through multiple steps it takes shape of a usable product.
#1 Customer comes with requirement.
#2 Business analysts/ Product owner analyses the requirement and starts documenting them in the Azure Boards. They starts creating Epic, Feature and user stories.
#3 Engineering team then starts estimating the work and plan those user stories for sprint.
#3.1 In parallel test engineers starts for Test planning in Test Plans based on the acceptance criteria of the user stories.
#4 Once sprint kicked in – developers starts picking user stories from the backlogs created at step 2 and starts implementing them.
#5 Once developers are done with the development they creates a pull request and sends for code review. Upon satisfaction of the code reviewer, developer commits the code in the Azure Repos.
#6 A build gets triggered in the Build Pipeline as soon as the code gets committed in the Azure Repos using continuous integration (CI). A CI build gets the latest code form the repos, builds them in the build agents, restores any private packages from the feed setup in the Azure Artifacts. It runs unit tests, generates code coverage result and finally generates the build output for deployment. If any one of the steps configured in the build pipeline fails then whole commit gets rejected and developers gets a build failure notification. Developer fixes the build and commits one more time and CI build triggers automatically.
#7 Build output needs to be moved to the deployment environment. In a Release Pipeline source of the build artifacts is the output of the CI build of previous step 6, destination will be the servers where these artifacts needs to be deployed. In this example it is deploying the artifacts to the Azure Cloud App Services and Azure SQL databases for a TESTING environment (step 7.1). A gate or approval mechanism can be set before the deployment happens, this gives control to the approvers to pick and choose which build to be deploy.
#8 Now that build is deployed in TESTING environment, test engineers starts testing and verifying the build quality. They run a set of manual, automated and load tests as planned during the planning phase (step 3.1) in Azure Test Plans. If they observe any defects then they log then in Azure Boards backlog and creates a new bug/issue/observation. Developer picks these defects once these are planned and fed back to the sprint, fixes the defects and commits to the Azure Repos which eventually triggers CI/CD in Azure Pipelines.
#9 If test engineers are satisfied with the build quality and functionality delivered, then this build gets promoted to the upper environment (step 9.1). In this example it is UAT environment for business users to test.
#10 Business users now gets a new build in UAT environment with all the features planned for the current sprint. Business user starts verifying the build and functionality in UAT environment.
#11 If business users finds any defects then they log them into the Azure Boards backlogs as bug/observation. Development and build cycle continues once these defects are planned and fed back to the sprint.
#12 If business users are satisfied with the functionality and the build quality then the build gets promoted to the PRODUCTION environment (step 12.1). Once this is released to production, end users starts using the system. If any issue occurs in the production then it again gets logged in the Azure Boards backlog as an Incident/ Bug/ Issue.
======================================================
For Details Visit Us: https://www.techpledgeconsulting.com/
Email: [email protected]
Whats up: +91-7676-7 03-141