| Â | Â |
|---|---|
| Objective | - To implement an automated development workflow using Azure DevOps for .NET Core application - To create build and release pipelines in Azure DevOps |
| Approach | - Created a web app in both Visual Studio and the Azure portal using Azure App service. - Set up source control for the app using Azure DevOps and GitHub |
| Impact | - Effectively kept up with the demands to field a constant flow of requests for new features, updates, and bug fixes by implementing an automated development workflow - Set up proper source control for web app and configure a fully automated continuous integration and continuous delivery (CI/CD) pipeline in Azure |
Primary Azure Technology: Azure DevOps, Azure App Services
Other Technology: GitHub, Visual Studio
One of the benefits of working with Azure is it provides a vast library of pre-built resources. We'll use one of the pre-built packages to create a Web App in the Azure portal.
STEPS
Step-1: Click on Create a resource.
Step-2: Click on Web App under Popular Azure Services section.
Step-3: Create a new resource group by clicking Create new.
Step-4: For the Publish mode select Code, if it isn't already.
Step-5: Select .NET 7 (STS) option in Runtime stack. Select Windows option in Operating System.
Step-6: Click on Create to create a Web App.
Hence, the web app is created.
Step-7: Click on App Services in the left navigation bar.
Step-8: Click on the created app.
You'll be brought to the Overview page for your App Service. Click on the Browse button to the left of the search field. You should see your App Service is up and running template page from Azure.
One common way to begin developing applications is by creating one through Visual Studio.
STEPS
Step-1: Click on the Create a new project button under the Get Started section.
Step-2: This brings up the selection window where you can search for templates of many popular project types. Select the ASP.NET Core Web App Template, then click Next.
Step-3: You're prompted to fill in some basic details about your app like the project name and your save location. Fill out these details as they make sense for your setup. Since we are creating a single project within the solution, also ensure that the place solution and project in the same directory check box is checked. Then, click Next.
Step-4: The final screen in this wizard asks you to select the type of application you want to create. Find the web app application type and select it. Then click Create.
After a short wait, your app is created. And that's how to create your web app in Visual Studio.
Publishing your application to an Azure App Service allows others to access and engage with it.
STEPS
Step-1: On the right hand side, look for the solution explorer and right click on the name of your project. From there, a context menu opens. Select the Publish option in the menu. If you previous published an app you may already have some configured publishing profiles.
Step-2: Select Azure in the Target option.
Step-3: Select Azure App Service(Windows) in the Specific target.
Step-4: Fill the fields of subscription name, view and search in the App Service option. If you're signed in to your Azure account, you'll have most of the options prepopulated.
Step-5: After confirming these details, click Create.
That's it, Visual Studio deploys your app to the newly created Azure App Service.
Most applications go through several iterations, either with bug fixes or new feature editions. To keep track of all these changes and to properly version your app, let's set up a new repo using Azure DevOps.
STEPS
Step-1: In the main search field of your Azure portal located towards the top center of the screen, search for Azure DevOps. Select the Azure DevOps organizations search result under Services.
Step-2: This will take you to the Azure DevOps overview. Find the link, My Azure DevOps Organizations, towards the bottom left and click on it.
Step-3: This will open a new page that shows your connected organizations.
Step-4: Before we can create a repo, we'll need to first create an organization. Since you don't have any organizations yet, click on Create new organization button.
Step-5: You'll start the Azure DevOps organization wizard. Click Continue to agree to the terms of service, privacy statement and code of conduct.
Step-6: Give your organization a unique name and then click Continue.
Step-7: Now we'll create our first project within our organization. A project is the top-level container that can hold one or more repos. Click Create project.
Step-8: Click on Repos on the right navigation menu.
Step-9: Once you're in the repos section, find the plus button next to your project name. This should be towards the left hand navigation menu. Click on the plus button. A selection menu will appear, prompting you to select a new item to create. Click on New repository.
Step-10: This will bring you to a "Create new repository" window. Be sure that the type selected is Git as that's the version control system we are using. In the repository name field, enter a name for your Git repo.
That's it. Your new repo is now initialized and you'll be brought to the overview of your files, which include the fresh README and the gitignore files that we just set up.
GitHub is a popular web-based hosting service developers use for their source code management. Let's set up a new repo in GitHub.
STEPS
Step-1: Navigate to github.com and log in to your account. You are brought to your dashboard. Next to your profile photo or on the left hand side, click on the Create a repository link. The Create a new repository page comes up. Here, you'll be asked to fill out a few details about your new repo.
Step-2: First, give your repo a name. Next, fill in a quick sentence or two about your application in the Description field. Though optional, a well-configured repo usually contains a meaningful description. Next, check the Initialize this repository with a README checkbox.
Step-3: Finally, click Create repository.
That's it! Your new repo is now initialized and you'll be brought to the overview of your files. It also includes the fresh README and gitignore files we just set up.
If you have a legacy app or existing application that needs to be properly versioned, then connecting an existing app to a repository will let you start keeping track of your apps iterations.
STEPS
Step-1: In visual Studio, open your application.
Step-2: Click on the File menu, and then click Add to Source Control. Visual Studio will now create a local repository for your application.
Step-3: Click on Create and push button.
That's it. You just created a repo for your existing app and connected it to source control.
If you have an existing app that you'd like to start managing in GitHub, then you can use few commands to set up a GitHub repo for your existing application.
STEPS
Step-1: First, we need to create a new repository on GitHub without the readme or gitignore files. Navigate to github.com and log in to your account. Next to your profile photo, click the plus button towards the top right, and then click New repository. The Create a new repository page comes up.
Step-2: Use the same name for your repo as the existing application that you're trying to connect.
Step-3: Finally, click Create repository.
Step-4: Your new repo is now initialized, but before we leave, make sure to copy this link right here, we'll need it later when we have to push our local repository to this new remote that we've just created.
Step-5: Now, open the terminal of your choice and navigate to your existing application's home directory using the cd command. Once there, initialize a new local Git repository by using the git init command, then press Enter. You'll see we now initialized an empty Git repository on our local machine. To connect to our local repository, we first need to add a reference to the new remote repository we just created using command git remote add origin https://github.com/itsAditiSaraswat/another-Coffee-critique.git command. Type git add . to add all of your existing application's files to your local repository, and stage them to be committed.
Step-6: Then, add a commit message to denote your initial setup by typing git commit -m, followed by the commit message in quotes. Since this is our first commit setting up our existing application, we will do "Initial commit, setting up version control for old application", then press Enter.
Step-7: Type the command git push -u origin master.
That's it, your existing application now has a local repository and is connected to your newly created remote repository in GitHub. Now, anytime a change is made on your local repository, or a team member merges some changes into the remote repository, you have an easy way to track and integrate these changes both ways.
Once code changes are ready to be integrated into higher level environments, having a build pipeline configured saves a lot of time, and is a reliable way to integrate such changes into your application.
STEPS
Step-1: Navigate to your Azure DevOps project page by going to dev.azure.com/your-organization-name. On the left-hand navigation menu, find the Pipelines option and click on it to go to the pipeline section of your project.
Step-2: To create a new build, click on the Create pipeline button in the center of the screen.
Step-3: You are brought to the build pipeline wizard where it will configure the initial settings for a build. Click the link underneath that says, "Use the classic editor".
Step-4: Choose the source repository that will be used for this build pipeline. We'll use Azure Repos Git for our source. If you already have a repository connected to this project, you'll see that the team project and repository dropdowns are already populated. Click Continue.
Step-5: Now you're given the chance to select from many build templates based on the type of application you are building. Select the ASP.NET Core (.NET framework) listed under the other's category, as that's what we're building. Then click Apply.
Step-6: Now, click on the arrow and then click the save option. A saved build pipeline window will then appear. You can leave the select folder at the root. And if you'd like, you can leave a comment about this build pipeline. Then, just click Save.
And that's it, you've just created build pipeline for your .NET Core application.
Configuring our build means adapting the provided build templates to perform the actual steps we need to build our project. Let's see how to do that with a .NET core build template including the addition of a brand new step.
STEPS
Step-1: On the left-hand Navigation menu in Azure DevOps project overview, click pipelines icon to go to your builds. You should see a list of all your build pipelines and the history of the current one that's selected. Select the build pipeline you'd like to configure.
Step-2: Towards the top-right of the screen, click on Edit button.
Step-3: You'll be brought to the build's overview page. To add a task, click on the Plus button located on the Agent Job One header.
Step-4: We will need to add NPM install command to download our front-end dependencies. To quickly search for it, use the search box towards the top-right and enter NPM. The top matching results should display. Click on the task NPM to select it and then add the task by clicking the Add button towards the right.
Step-5: You'll see the NPM task added to the bottom of our phase group. We'll need to move it to the appropriate spot towards the top. To do this, click and drag the right edge of the NPM step to the right position. The last step is to provide the correct path to our package.json file in the working folder that contains package.json field. Make sure to select the parent folder of the package.json file and not the file itself.
Step-6: Finally, click on the dropdown menu and click Save to save your changes. You can add a comment to describe the changes you have made to this pipeline and then click Save.
And that's it. Your build is now configured to run the steps outlined in your pipeline.
One of the most powerful parts of an automated pipeline is the ability to kickstart processes upon some new code changes being pushed to a repo.
STEPS
Step-1: Go to the Azure DevOps Project overview page for our project. On the left-hand navigation menu, click on the blue rocket icon to go to your builds. You should see a list of all your build pipelines and the history of the current one that's selected. Select the build pipeline you'd like to set up a build trigger for. Towards the top-right of the screen, you'll click on Edit button.
Step-2: You'll be brought to the builds overview page. Towards the top-left, find the Triggers tab and select it. Here, you'll see many trigger options. For now, we'll focus on the continuous integration trigger. In order for build triggers to work, ensure that the Enable Continuous Integration checkbox is selected. When you do, you'll see some more options appear below it. One of those is another checkbox option to batch changes while a build is in progress. This option tries to combine as many changes that belong to the same build into one, including new changes that are pushed to a repo while a build is running. This means you won't have multiple builds running one after the other.
Step-3: Go to the dropdown and click Save. Then click Save on the Save Build Pipeline window.
And that's it. You'll see your build kickoff the next time you push a code change to your remote master branch.
A great part about Azure DevOps is that requeuing builds is an easy process. Let's see how to do that if we ever need to requeue a failed or non-kickstarted build.
STEPS
Step-1: Go to Azure DevOps project overview. On the left hand navigation menu, find the blue rocket icon and click on it to go to your builds. You should see a list of all your build pipelines and the history of the current one that's selected. Select the build pipeline you'd like to requeue.Towards the top right of the screen, you'll click on queue button.
Step-2: A queue build prompt for your selected build pipeline will appear. This prompt is incredibly helpful if you need to rerun a specific build down to the branch, or tags or commits. For now, we'll leave the agent pool to the default of Hosted VS2017, as that's what our build requires for our .NET core application. Finally, leave the default variables and demands options. Since we are requeuing a previous build, these options don't need to be changed. However, they're there for your use should you need to requeue a very specific build. Lastly, click the Run button towards the bottom right of the prompt.
That's it. Your build will be requeued, and start when the next agent is available to run your build.
After building your app, release pipelines take care of deploying your app to the environments and specifications you designate. Let's set up a release pipeline in Azure DevOps.
STEPS
Step-1: Go to Azure DevOps project overview page. On the left-hand navigation menu, click blue rocket icon, and then select the Releases option.
Step-2: You are brought to the releases area. Here, you'll see your list of releases and their statuses in history, if you have any. To create a new release, click on the New pipeline button on the center of the screen.
Step-3: You are brought to the release pipeline editor where we'll configure the initial settings for our release. A prompt will ask you to select a release template from the many that are available. We'll be using the Azure App Service deployment template, which is the first option. Select it. And then click Apply. This will apply a preconfigured task into your first stage,
Step-4: Another prompt will ask you for a stage name. For this stage, we will call it development. You'll see the stage on our release editor, automatically update with the development name. Right under the name, you'll also see the previously added task denoted by the one job, one task link. Click on this link to open the stage configuration editor.
Step-5: Here, you'll see your list of release pipeline tasks on the left hand side, and the details of a selected task on the right. The first setting we need to configure is the Azure subscription we want this release to belong to. Click the dropdown and find the subscription you want to use. Then click the authorized button. After authorization is complete on your subscription, the app service name dropdown should populate with your available app services. Select your app service name. All that's left is to give your release pipeline a name.
Step-6: Click Save. And then click OK.
That's it, you just created a release pipeline for your .NET Core application.
Release pipelines deploy our applications to the environments we specify, but it won't know what to deploy if we don't provide it with a source. Just as the build pipelines require a source repo to kickstart its processes, a release pipeline needs a source artifact to start its own. Let's set up our release pipeline to use a build artifact.
STEPS
Step-1: Go to the Azure DevOps Project overview page. On the left-hand navigation menu, hover over the little blue rocket icon and select the Releases option.
Step-2: You are brought to the releases area. Click on the release pipeline you want to set with a build artifact. For me, that's coffee-critique-release. Then towards the top-right of the screen, click on the Edit button.
Step-3: You are brought to the release pipeline editor. Click the Add an Artifact action located within the Artifacts section. The Add an Artifact panel will slide out. Choose the build source type. Next, select your main project and source build pipeline. After selecting a build pipeline, you'll see a few more options appear. Leave the default version option of latest. This will deploy the latest version of our build artifact whenever a new release is created. Alternatively, you can get even more granular control over which versions to release by using options like latest from a specific branch with tags or a specific version.Finally, click the Add button.
Step-4: Save your changes before leaving the page. And then hitting OK.
That's it. You've set up a build artifact for your release pipeline to use.
Releases can be automatically triggered, just like builds. Let us work on release trigger.
STEPS
Step-1: Go to the Azure DevOps project overview page. On the left-hand navigation menu, hover over the little blue rocket icon, then select the Releases option.
Step-2: You are brought to the releases area. Click on the release pipeline you want to enable triggers on. Then towards the top-right of the screen, click the Edit button.
Step-3: You're brought to the release pipeline editor. Within the artifact section, you should see your artifact. On the top-right corner of your artifact, is a little lightning bolt icon. Click on it.
Step-4: The continuous deployment trigger panel will slide out. To enable the continuous deployment trigger, click on the toggle. It should now say enabled, and a few more options will appear. While we want our release pipeline to automatically trigger, we only want to kickstart it on the builds and branches that make sense. Otherwise, we'll have a whole bunch of releases queued that we may not want. Since this is our dev release, let's filter our trigger to only respond to the dev branch. Click on the add button to add a branch filter. Ensure that the type is set to include. For the build branch, select the dev branch. This tells the release to keep track of our dev branch and watch for new builds that come from it. That's it. Exit out of this panel by clicking the X icon at the top-right.
Step-5: Save your changes. You can also leave a comment that says what we've added and then click OK.
That's it. You have now enabled a continuous deployment trigger on your release pipeline.
Releases usually follow a pattern. First, deployment to a dev environment, then to a QA testing environment, and finally production. No matter how many stages you have I'll show you how to configure multiple stages for all of your environments.
STEPS
Step-1: Go to the Azure DevOps project overview page. On the left-hand navigation menu, hover over the little blue rocket icon, then select the Releases option. You are brought to the Releases area. Click on the release pipeline you want to configure stages on. For me, that's coffee-critique-release. Then towards the top right of the screen, click the Edit button.
Step-2: You are brought to the release pipeline editor where we will first add a QA stage for our pipeline. For our QA stage, we can clone our development stage as it will require the same steps. To do this, select the Development stage, then click the add button next to the stage's label. Then, click the Clone stage option. A copy of that stage will be created next to your development stage. Let's change the stage name to QA.
Step-3: Next, click on the 1 job, 1 task link under the QA stage. As expected, the same configuration has been copied over from our development stage.
Step-4: We need to change this to point to our QA resources, however. Under the App service name dropdown, select the appropriate app service that our QA instance needs to be deployed to.
Step-5: Then, go back to the pipeline view by clicking the Pipeline tab. To the left of the QA stage, you'll see a set of icons which denote the pre-deployment conditions, click on it. A Pre-deployment conditions panel slides out. Here, you can configure specific conditions to be met before your next stage is deployed. Conveniently, Azure DevOps has selected the correct default of After stage as well as the Development stage. This means the release to the QA stage won't start until the release to the development stage is complete. That's it, our QA stage is configured.
Step-6: Now, let's add our production stage. Exit out of the Pre-deployment conditions panel. Then, select your QA stage if not already selected. Close the QA panel that automatically appears so you can see what you're doing.
Step-7: Clone your QA stage by clicking Add next to the Stages label, then Clone stage. This configuration will be the same with the exception of the environment
Step-8: Update the stage name to Production and then click on the 1 job, 1 task link under the Production stage and make sure to update the app service name to your production instance.
Step-9: All that's left is to save your changes. Then, add a comment so we can keep a good history of the changes to our release pipeline. And then, click OK.
That's it, you added and configured a QA and production stage to your release pipeline.
When code goes into production we want to be sure that it is deployed intentionally and with any necessary approvals. Let us see an example of how to use pre-deployment and post-deployment conditions to fulfill release and compliance requirements.
STEPS
Step-1: Go to the Azure DevOps project overview page. On the left hand navigation menu, hover over the blue rocket icon, then click on the Releases option. Click on the release pipeline you want to configure pre-deployment and post-deployment conditions on. Then towards the top right of the screen, click the Edit button.
Step-2: You are brought to the release pipeline editor. One common post-deployment condition is to have a QA approval. To set this up, click on single user icon to the right of the QA stage.
Step-3: A post-deployment conditions panel will slide open. Click on the toggle to enable post-deployment approvals. A few more options will appear. In the approvers' field, search for a member of your QA team or a user who will act as a QA approver and add them to the list. If you have groups, say a QA approvers' group, you can add that too. Note that when you add a group, only one person from that group has to approve, not the entire group. So if you need multiple approvers, you need to add them separately. That's all for post-deployment conditions. We have set it up so that a release to production cannot be kick started unless a QA approver has approved to the QA release first. Exit out of the post-deployment conditions panel.
Step-4: On the production stage, click on the set of icons to its left. This opens the pre-deployment conditions panel.
Step-5: For production, let's not only enable another set of approvals, but ensure that the user requesting the release is not the same as the approver. This prevents a single developer from forcefully deploying code without review. This is also a common policy set up to meet compliance requirements. Scrolling towards the bottom, find the pre-deployment approvals and toggle it so that it becomes enabled. Some options will appear. Search for users to be your pre-deployment approvers to production. This is usually a product manager or a release manager. If anything, try to make sure that these are different users than your QA post-deployment approvers. Lastly, under approval policies, check the user requesting a release or deployment should not approve it option.
Step-6: Vave your changes. Be sure to add a comment about the pre-deployment and post-deployment conditions we have added. Then click OK.
That's it. You've now added valuable pre-deployment and post-deployment conditions to fulfill depending on the environment that's being deployed to, not to mention, you're probably also fulfilling some compliance requirements.
Sometimes releases can fail or get stuck. Other times we need to create a specific release to be redeployed.
STEPS
Step-1: Go to the Azure DevOps project overview page. On the left-hand navigation menu, hover over the little blue rocket icon, then select the Releases option. You are brought to the Releases area. Select the release pipeline you'd like to re-queue.
Step-2: Towards the center of the screen, click on Create Release button.
Step-3: A create a new release prompt for your selected release will appear. Select the stage you wish to trigger manually. Add a release description. Lastly, click the Create button towards the bottom.
That's it. Your release will be re-queued and start when the next agent is available to run your release.
