Creating Your First CICD Pipeline With Azure DevOps

1. Introduction: Hello and welcome to this short tutorial on how to create your first agile friendly CRC de pipeline using as your DevOps. My name is when nice and I've been lucky to work with a number of technology companies as well as government agencies throughout the years. On the side, I'd like to share my own experience and knowledge through lectures, blog posts, and even YouTube channels. But enough of that. Here are the skills we're gong to be focused in on with this course. We are going to get familiar with as your DevOps and his licensing schemes. We are going to be using as your get ripples with Visual Studio code. We're going to be secure in their gets master branch or main branch from a direct push by enforced import requests, then we're going to be Lincoln these polar requests with as your boards. So we enforce collaboration between your team member channels of plan stage of the cycle. Then we're going to deploy a web app to host a website with two deployment slots, one life and one deaf, using as your PowerShell and an ARM templates, we are then going to be creating a continuous integration build pipeline to test your web app before deployment, which handles the create and verify. We're going to be Lincoln as Build Pipeline where they release continuous delivery pipeline to deploy to the depth slot, stopped for manual approval, and then deploy to live once approved, which handles the package and release stages of the cycle. Basically after this, I believe you'll not only have the skill secretes you're on pipeline, but also manage a full development in if you want to write to fully benefit from this course, you will need the following. Need to be familiar with as your cloud and development concepts. So for example, need to know your IS from your pass. You need to know how to work with Git repositories. You need to have an active as your subscription. And this can be either pay-as-you-go enterprise agreements or even a free trial using your credits. Debits are prepaid card, and that will give you $200.170 Euros credits. You need to have Visual Studio Code installed or any IDE capable of working with kit-based source control. You also need to have, as your PowerShell modules installed. And this can work with Windows or Linux. Yes, it works. However, if you're not comfortable with that, you can use it as your CloudShell. Last but not least, Take It Easy. Feel free to skip ahead and follow what interests you. However, we might miss out on a few tips and tricks. If you don't follow the course has intended to. Don't feel intimidated if you have any problems, if you get stuck anywhere, please don't hesitate to get in touch with me and I'll do my best to answer you. Let's get to work and I look forward to what you come up with. 2. Create Your Azure DevOps Project: Alright, so the first and I needed to do is to sign up with their zeal DevOps. Now we can either use your normal Microsoft accounts or you can log in with your GitHub account. So I've got to start free and create a new Microsoft account. So now we can choose the region in which we're going to start our DevOps account. We can give a name to the organization and also we can choose as your datacenter and which we will be hosting our project, which is very important because there's no point in working in Western Europe and having your repo in Brazil, for example. Now we can create a project to get started. And the thing to note here is that we can have multiple projects under one organization, and each project can have its own permissions and repositories. All right, so here you can choose if you want it to be a private projects or a public one. So have you intend on working on this rapport with the team and you don't intend on publishing anything, you may as well just choose a private. So I'm going to use a private option for now, going to give it a project name DevOps course, and click on create project. So on the summary page, we can add a description about the project. We can just add a description over here. Or we can link it to Read Me file or wiki on the repository. We also have the project stats, which gives us an overview of the items created where tritons completed on the boards. We also get a view on the overall requests opened, the commits, and when we start having pipelines will also get statuses on the pipelines that have successfully completed, failed, and so on. It also got a list of the members over here. And at the top here we can invite new members. We add them by email. And more basically is going to happen is that they're going to get an email invitation to join this as your DevOps group. We also have the dashboard section which will make more sense as we get more content on this project are the idea is that we add widgets that'll be tied with work items, deployment statuses, lead time. We can also add custom webpages, markdown pages, pull requests. We release, release pipeline or reviews and so on, go and down here we have the wiki page for me personally, I love document everything because you never know when you might change departments or you might go somewhere else and someone will have to take over what you've been managing. Or if you have a new team member who needs to get up to speed with everything. So using the wiki over here is a good way to allow all the team members to collaborate. We have the ability to create a main project wiki and then link it with multiple sub wikis. As you can see over here, we'll click on create project wiki. We got the title and then we can have like a mini word kind of text editor that will translate into Markdown. Now we're going to look at the organization settings and then move on to the project sentence. 3. Organization Settings & Licensing: All right, so first of all, we're gonna go back to the organisation. And here we're gonna go down to the bottom left corner of the screen and click on organizations seconds. Here we have the ability to change the name of the organization. Either privacy URL, add a description, change the time zone, change the owner, and deletes the whole organization. Under that we got projects. We can add projects, we can modify projects, you can add new projects. We can rename or delete projects, and now we reach the user section. And this section is very important because this is where the SEO DevOps license restrictions come into play. So if I click on the summary here, we'll find we have two types of users. We have the basic user and the stakeholder. Now the stakeholder has access to a limited number of features. So for example, the stakeholder can administer the organization. He can access to agile boards. You can access agile portfolio management. And he can use a standard features which includes working across projects, Bu dashboards view wikis, managed personal notifications due to test summary view work items, as well as view releases and manage approvals. So as you can see, the stakeholder would be more like your manager or someone who needs to approve things rather than actually getting involved with the nitty-gritty technical stuff. And this can be assigned to a limited uses. Now the basic user allows you to use all of the features on Azure DevOps, with every organization you only get five free users. The rest you will have to pay for. However, the cool thing to note here is that if you have MST and subscribers or Visual Studio enterprise subscribers, you can use them in place of a basic license. So don't need to buy any licenses for those kinds of uses. So keep that in mind. Now if we click on the Buy, it will take us immediately to the Benin section. We can start sets an ability. So you can say Berlin has not been set up as organization axis will be available up to the free tier limits. So the free tier limits are, and we have five BCE accusers. The rest we have to pay for. We have 1800 minutes for Microsoft hosted CIC D pipelines, which we'll get into in a minute. And we have one free self hosted see ICD pipeline with the freedom is we get 0 paid parallel jobs. And that means we cannot have more than one pipeline and run them at the same time, go and down to artifacts. We have free two gigabytes of artifacts used, less than one gigabyte usage emit up to two gigabytes free cloud-based load tests in which we can use, we have up to 20 thousand viewers. For more information, you can click on the free tier limits. And you'll get Frequently Asked Questions on the free tier. Moving on, we have the auditing section. So this basically gives us a log of every single activity that happens on the projects, which is quite useful. We have global notifications. So these allow us to manage all of the notifications related to the projects. Here we get a log of the usage of applications and extensions per user. We have extensions if you want to add extensions that gets used in a pipelines, for example, we can also secure them so we don't allow people to install extensions as well. Here, if we click on browse marketplace, we can add different extents. You can add them from the organization settings or from the pipeline itself going down to as your Active Directory. So this section allows us to link, there's your DevOps organization with our Azure Active Directory tenant. So there's your Active Directory tenant would have all of the Active Directory users be ITS hybrid users or as your cloud users. And you can add them individually onto Azure DevOps. So rather than inviting them with emails, you would use in their Active Directory accounts security policies. We can choose to allow third-party application access using OAuth. So we would allow the developers to use the API Vizio DevOps to do exactly the same things that they do on the portal, we can choose to enable or disable SSH authentication. We can choose the disabled public projects altogether, and we can choose whether or not to invite Github users or down to Permissions. These are the global permissions that would apply to the organization. And any permission depth you would add here would be inherited on the projects below it we have now and the board's allows us to choose different processes for the as you are bought at geometry using the basic. But we can also choose specifically agile, scrum or CWR. My moving down to pipelines, we have agent pools and basically pipelines around with as your DevOps Asians. And these agents could be run in on VMs or containers. Now, as you or give you a pool of agents that you can use for running your pipelines. But you could also create your own self hosted pool. And that would be useful if you want to have automation pipelines running within your private network. So let's say you have a pipeline that would interact with an internal service behind your corporate firewall. And for that you can use a private agents can have settings, we can disable anonymous Paxos, limit variables are can be set to q time. We'll get into that. You have deployment pools, parallel jobs. Now of course, given that we're using a free tier, we don't have access to parallel jobs, but we do have the ability to purchase parallel jobs, as you can see below, if we're going to be used in a private projects were allowed one parallel job, but that parallel job has to be within a self hosted all. If we're going to be used in a Microsoft hosted Asians pool, we have no parallel drops if the project is going to be published with a Microsoft hosted Asian pool, we are allowed ten parallel jobs if we're going to be using as self hosted patient warm, using our own VMs or other own containers, we would have unlimited parallel jobs. So it's worth thinking about. Here we have both configurations which allow us to use service principles or application accounts from other sources like cloud GitHub or GitHub Enterprise server. We have the repositories where we can choose to enable or disable gravity images, we can change the default branch name for new repository. So at the moment by default, anytime you create a new repo, you would get the main branch. We have artifacts. We can setup the storage for artifacts. And the artifacts are the files that you will be publishing on your release pipeline. At the moment, we have 0 whew that was very long Wasn't it was very important to know these seems especially if you want to use as your DevOps in production, we will now move on to the project settings. 4. Project Settings & Connecting with Azure: Alright, now we've come back to our project, will go down to the bottom left corner of the screen and click on Project Settings. Here we have the ability to rename the project itself, the description. We can change the visibility of the project dependent whether or not we have the option enabled on the organization settings. If you remember that one, we can have project administrators and we can enable or disable features. Here we can delete the project as well, going to the teams. Now by default, we get one team created with the project. And this team would be a group. So you can create another team as well. And in this team you can add members and administrators. And you can use this to assign permissions to a whole group. So if you go to Permissions, we have the default groups. In addition to the DevOps costing that is down here, you can either choose to use a default groups or you can create your own groups with granular permissions. I personally like having granular permissions. So I can employ at least privileged policies. So we can have a project administrator just on the boards. This could be the team leader. The only needs to look at the work items is Scrum Sprints and so on. Here we have the views of the groups and the users. So all the users would be showing up here. If we click on the user, we would see their permissions as they are inherited. We can also see the groups that they are a member of. So for example, textured CSU is part of the project administrators group, DevOps course team and to the organization project collection administrators, and even auto notifications. Now by default, this will be sent in every single event as an email to DevOps course team. You can choose to keep it like this. But believe me, once you start working with the ripples and published in pipelines and all that, you'll start to get very spammy emails. So you could either choose to disable some of them or create a new subscription with specific events of service hooks is like Notifications plot. It sends a notification outside of SEO DevOps. So if I click on Create subscription, we can send events to a number of services like the app center as your app servers. So supported events called pushed supported actions deploy a web app, the Service Bus storage. We can send it the Jenkins as well. So when they build is completed, we can trigger a build on Jenkins. We don't have to use as your DevOps, for example, we can send something into Office 365 for example. So say you have a team's group, and when someone creates a work item that will send a notification to the team score, we can also use web hooks. So if we have our own API, we can send events to this API and process it accordingly. So with dashboards, we can control who can create, edit entity, them. Moving down to boards, we had the project configuration. We can set high iterations. We can set data, we can add areas which we can also do from the Board section itself. We have the team configuration where we can set the navigation levels. We can also set the working days so the team would be officially working on weekdays only. We can go to iterations. We can go to areas where we can create different areas. So here we can set templates when someone wants to publish an issue, any peak or a task. Here we have GitHub connections. This is where we would be Lincoln the project with a GitHub account. Here we have the Asian pools, which is exactly like the Asian pools on the organization settings, we have the parallel jobs, which again is like the organization settings. We have the pipeline settings which will allow us to set retention policies for the artifacts or conferences pipeline. We have the test management section which allows us to manage flaky test detection. We have the release retention, which will give us information on the retention policy for the releases. And here's a very important section which is the service connections. Since we are going to be using as your for this course to deploy a web app and update the webpage, we have to create a service connection. So this create one now, so I'll click on Query service connection. And here as you can see, we can link with a number of services. So we can link it with as your classic Azure Resource Manager Bitbucket Chef, Docker host, I am going to choose as your resource manager. Now the easiest option would be to use Service Principal automatic, which would link your current as your DevOps account with the Azure cloud accounts when you select it as your DevOps will attempt to you as you're currently logged in credentials defined if they are linked with any as your Cloud credentials. Now since this account is not linked with a 0, we will have to do things manually. So I'll go back service principle manual and I'm going to link it with as your cloud. And I'm going to use a subscription ID that I have with another account. So I'm going to add the subscription name. I'm going to add the name of my subscription, which is from my sister YouTube channel. And now I'm going to use a service principle id. So I'm gonna go back to my as your accounts. And I'm going to go to Azure Active Directory, app registrations. And I'm going to create a new registration and I'm going to call it develops episode. I'm going to use a single tenant. Water can use number of options. Pointer register this account. Ok, so now I have a client ID and a tenant ID. So I'm going to use a client ID. Service principal IT service principle key is going to be the password or the secret. So they've got to go back here and I'm going to create a secret. Now, ideally with secrets, you would generate them on the app registration and then store them in an Azure Key Vault, for example, because wood there as your key volt, you can dynamically crab the secrets and when the secret expires and it's time to be changed, you don't need to go back to your applications and changed a manual that you can just change them from the keyboard because all your applications connect to the key vault was a testing expires in one year. We not bothered. Right. So now I have the value. I can just take that reports the service principal key. And we go back and we get our tenant ID, which is Azure AD domain. That's done. We give it a name. Okay, so we're good to go. I can click on Verify. So now when I click on Verify tells me I'm forbidden from Lincoln important things when you create a service principle that you give it access on the subscription or the resource group that you want to work with. So I have to go back to my subscription, go to Access Control, alter role assignments for all the assignments. And I'm gonna give it contributor. Oops, episode. And safe. I should give it a contributor access on the subscription which will apply on all the resource groups. Blow it. All right, so I can go and verify again. Everything looks good. So now we've established a connection with the as your cloud. This connection will allow us to create web apps, create VMs, entering data heart desires on the subscription. We have XHTML build services. If you want to have a connection, we have the ripples. So here we have the settings of the repositories. We can add new repositories, or we can browse, rename, delete existing ones. We can change the settings so the default branch name, for example, we can enforce a maximum file size and maximum path length reserved names, for example. And we have permissions, we can set permissions on the repositories themselves. Have permission to create branch, Create repository, Great tag. According to the groups, we have the artifact storage as well, and we have the test retentions so we can keep the automated tests are ions results in attachments for 30 days and for manual test runs, we can keep them for one year. That's it. So now, I promise you, we're going to start getting into the good stuff. 5. Configuring the GIT Repo: Okay, so finally we are going to get to do some work. So first of all, we're going to check the reports. We're going to go to files and we find that our repositories and he's got a Read Me file and it has a main branch. Now, I cannot emphasize this enough. You do not want to work directly with domain or master branch. If you work with a team or you join a company and you start messing around with the main branch, you will not last very long. So what are we going to do? We are going to protect the main branch by enforcing polar requests. And those pull requests will be linked with the board's. So first of all, we got to branches, we got two more and we got to branch policies. And here is where we enforce pull requests. For the sake of this course, I'm going to take allow requesters to improve their own changes are usually wouldn't allow that. The next option I'm going to enable this check for linked work items and I'm going to set it as required. So what we've done, we've protected the main branch from being directly pushed to why enforcing pull requests. And we've also enforced collaboration with the team. So that's a polar requests will not be approved unless it's linked with a work item. So now if I'm going to publish code, I will have to branch out, published a cold on the branch, submit a pull request that has to be tied to the work item and then merge. So first of all, I'm going to go to boards work items, and I'm going to add a new work item, a task that says deploy websites. I will assign it to myself and I'll add that to-do list. Now, the work item, we can tie it to a specific reason, a specific area which we can define in the settings of the project. And we can also assign it to a specific sprint. We can link it with certain branches on the ripple as well as other work items. And as soon as we have a release linked with a pull request, it would start showing up here. Furthermore, under this work item, we can add a description which I encourage people to add. So here we will talk about this new feature that he had been added, this new bug fix and so on. You can also have a discussion where other team members can add comments. You can see the statecraft and his three. You could link it with other items. And you can also add attachments. So for now I'm going to save and we have task number seven now to push this code who go to firstly, clone this report to our Visual Studio code IDE. And the quickest way to do that is to use the clone button and click on Visual Studio code. And what this essentially does is that it creates a personal access token, which you can find here, personal access tokens. It will create a personal access token in the background that would allow your Visual Studio Code to login to Azure DevOps. And you have to be careful with this because every time you click this button, you will be creating a new personal access token. So for now I'm going to open Visual Studio Code. And we are going to use this button. And now an extension to open CRI, open now was going to ask us where we want to store our new REPL. So let's give it a new folder. Devops episodes. And let us dump within here. Now are clone in your Git repository. Would you like to open a clone? The repository we would say Open, and now we are connected with our repository on Azure DevOps. So at this stage, what I would like you to do is to Brown shouts. So we go to source control, click on the three buttons and got to checkout too. We would say first draft. Okay. And now I would like you to download the zip file for this course, extract the files, and dump them in this folder, right? So now we have the zip file extracted into the folder, which is using the first draft branch. And what this basically is is a simple Node.js web app us. We also have an a 0 deployed or adjacent file, which is an as your resource manager template, ARM template. What this does, it will deploy a server farm with a web app that has two deployment slots, alive in a deaf. And each of these deployment slots will have their own URL. In addition to that, if you want to look into it, we have enters your pipelines YAML file. And for this course we will be using the classic GUI so he can get used to deploy these pipelines. However, bear in mind that you can use these files and store them on your code repository for version control. So now you've got to push it to our first draft branch. We've done the gates commits, now we're going to push it. No upstream branch, Yes, understood. Click OK. And that's done. Now, let us try messing around with the main branch. So if I go to the main and I try adding something to the readme file. Okay, so that's a new change. If I go to the source control, had to git commit message testing, Control Enter. And I try to push this change. What's going to happen with this error? If we open the git log, we will see pushes through this branch are not permitted. You must use a pull request to update this branch. So as you can see, we've stopped people from playing around with the main branch. Now imagine the main branch would be your actual live website. You don't want people to be messing around with them. Now let's go to Azure DevOps. And if I refresh, we will get this message that says you updated first draft two minutes ago. We can also go to pull requests and create a new poll request and we'll get the same message here as well. So if I click on new polar requests, we can choose a branch. So first draft into main. And here we can add a title and a description for the pull request. So I'll say first drafts, a description of this new poll request or this new feature, this new bug fix and the reviewers. So I'll add one. Here. We have to add a work item. So we will add the deploy websites. And now we have a pull request that will stay like that until someone approves it. As you can see here, we have the overview. It tells us that older quite Shek succeeded. So what will happen here? First of all, I want to check if there's a work item linked with it. Second of all, it's going to check if there's a merge conflict. So if you have any merge conflicts and we will know well in advance of that happening. And of course we'll have to fix it. And at this stage, if you add any more changes to their first draft, it will automatically show up with a pull request if it hasn't been approved as 50 to file, we'll see all the files that are we are adding or changing the updates and it commits. So now since I am take widgets one, I can approve and this is done. So now we can click on the Complete button and a complete bottle will merge it with domain. It can also complete the associated work item after merging. So here you have the choice to either completed or leave it uncompleted. Just in the cases work item is tied with multiple requests. We can click on that. We will also delete the first draft after merging. Here can also add a custom merge commit message. So I will complete the merge. That's done the resource project. So now if I go to files and it got to me and we'll find that we have our new web app. If I go to my Visual Studio code to the main branch and click on pull. We should start getting all of the files, as you can see here. So now what we've done, we've linked our repo with Visual Studio code on our own laptop. We've basically created a personal access token that would allow visuals to decode, to login to Azure DevOps, or we have enabled pull requests so we can protect the main branch from someone directly push into it. And we have tied pull request with boards, so we have enforced collaboration with the team. Next, we're going to focus on creating our web app using the Azure deploy dot JSON file. And then we're gonna move on to create an hour build and release pipelines. 6. Deploy the WebApp using ARM: Now we're gonna do some magic. What I would like you to do is run PowerShell as admin and type Install module a Zen. And this is going to download the Azure PowerShell modules, say yes to all, and continue with the installation. Okay, once that is done, close this terminal session and open another one. And now we're going to type connect a's account. We're going to login using our credentials for a 0, and that's it. So the first thing we're going to do is select our subscription. So we're gonna do select ASR subscription and give it the name. That's done. To deploy this web app, we need to have a resource group. So I'm going to type new A's at the resource group. Name would be DevOps, episode location would be and West Europe. And that's done. So now we can type view A's at resource group deployments. You give the deployment and aim DevOps episode. We give it the template file name. So we write template or template file and we say, as you're diploid or JSON. Now since we have two parameters defined in the file, we can use them as PowerShell parameters. So site, host name would call it take good Sue, App, App, Service plan name. We would call it take Egypt soon. App, SBC p, k. Resource group name would be DevOps episode. Let's do verbose. There we go. Template is valid, so we had any problem to template, it would stop then under check and deployment status. And so what we can do, we can go to 0 and we can find out that our deployment failed. Why? So tell us that the host name texture to underscore app is invalid, obviously because it's going to use it for a URL. So let's go back to our deployments, which failed as well, failed as we can see here. And we are going to use hyphens template as valid as go again, refresh. Now it's saying deploying this, check it out. So we have a server farm and that's done. We check Visual Studio Code, succeeded. So if we go to the resource group, we will find two app service plans and one app servers. If we check our app servers and go to deployment slots, we will find two deployment slots. One which is called taking shit. So App for production and take jujitsu dash app, dash dev for development. To now the idea is we're going to deploy to development first. We're going to test the website is if it looks okay. And then we're going to swap deployment slots to production. So let's go to overview and check the URL. And as you can see, we have the Node JS placeholder for Microsoft or 0. Now we can start working on our Build Pipeline. 7. Continuous Integration Build Pipeline: Alright, back to our DevOps products. We are going to go to pipelines and we're going to create a pipeline. Whereas your code, so we have a number of options here where we can use a zoo ripples, Bitbucket, gets hub, and so on. So we're going to choose as your repos gets, we don't choose our repository and this automatically picks up the Azure pipelines YAML file button instead of that. So we're gonna go back and use the classic editor. And here we have the same options with the team projects and repositories. We can choose the main branch and click on continue. Now we can choose a template if we want to, we have a number of templates. For now I'm going to choose an empty job. And here we have our first build pipeline. We're going to give it a name here. We're going to choose the Asian pool. And like I told you, the pipelines run on Asian Southeast Asia's would be on VMs or containers. These agents can also be as your pipeline agents or there can be private Asians within your own VMs. So we are going to use that as your pipelines pull. And from that pool we can choose a number of specifications. So I'm going to choose for B12 18 when he got to the get Sources option, no steps. You have the ability to change branches. So if you want to test this pipeline on another branch, you can easily change it here if it's available. Moving on, we go to Asian job one. So here's where we start head into tasks for the pipeline. So click on the plus button here and we have a number of tasks that we can add. So the first task we're going to add is to test the web app and we're going to install npm. Here. We're looking for the work and folder that contains package.json, which is this file over here. We're going to add an NPM test, which we don't have over here. So what we're going to do, we're going to use Command Line, which allows us to use either command-line on Windows or bash on Linux. We add that here. And we can say, yeah. And he went on to write npm tests. Can also go to Advanced and make sure we are using the right working directory. Should be to DevOps course obviously. So, alright, so now we're going to add archive. So we're going to archive all of the website files. I'm going to choose a root folder. So we're going to use the variable system default working directory. We will remove prepends root folder, and we want to archive as zip. And we're gonna use Arafat's upgrades built, artefact station directory builds ID. Now we're going to publish this archived web app so we could add another task, published pipeline artifacts. And so what's going to happen here is first of all, we're going to run NPM install. Then we're going to test the web app. If the test succeeds, we will archive and publish the web app. For some reason the test fails. The pipeline, the Build Pipeline will stop then Ender, and of course you'll be notified about it. Now before we continue, we're going to take the Build ID zip file and add it to the published pipeline artifact. So we only publish the zip file. So this basically is the build pipeline. So how can we make it a continuous integration pipeline? We would go to triggers and tick on, Enable Continuous Integration and we will link it with the main branch. Note here that we can also add path filters. So that's We can monitor a folder within the main branch rather than the whole thing. So that's done and click on save. Now before we continue, I want to show you something very interesting, and that is the pipeline Variables section. Here, we can add variables that would apply to the pipeline. These variables can be default variables or settable IQ type. So he could say computer name or VM name. When the pipeline runs, this variable will become an environment variable within this pipeline. And what I want to use it, I can call it like so. And I will get the value of that variable if I wanted to use it in PowerShell, I would use ENV variable one. If I wanted to use it in Python, I will do import OS and OS dot environ. Since it is a dictionary, we would say variable, and that would give us the value of that variable to be used within the script. So these variables can be either basic texts secure as well. So you can use passwords or also you can add a task before the whole thing runs. She used a key vault. We would link with our connection and subscription. We would get the specific key vault secret name. And that's becomes a pipeline variable as well, which you can then use. Accordingly. We would write the secret names of the secret name was secrets password. You would add secret password here and use it within the pipeline. So you don't have to hard code sensitive passwords anywhere. You can just connect to the Key Vault, populate the variable, and use it. Quite cool. Now, let's clean this up. Alright, so let us test our Build Pipeline. Now since we have everything locked up, we have to go to boards, work items has created a new work item, testing, Build, Pipeline, and assign it to myself. Frequent save. That looks good. We go to our Visual Studio code and we're going to branch out first feature. Right? Going to, going to views Index. And I'm going to add some text. And say table. That's not text as a table actually, but yeah, we add a row, had a self. And then under that and another row. That yes, yes, yes. Okay. Cve, right? Added table. And let's push that to the first feature. Lovely job Lee. Alright, let me go to files. Alright. Create a pull request at a table link. It's to test and build pipeline IMD approver. Okay, I approve. It. Looks Goode's complete. Did ETF now that's merged. Let's check our pipeline. As you can see, it started working. So it's installing NPM test to web app. The test succeeded it archives and then it publishes. And next we're going to work on the release pipeline. 8. Continuous Deployment Release Pipeline: So now we would create a release pipeline for a template I am going to choose as your app service deployment would slot, Click on Apply, give it a stage name. Deploy to dev, go to jobs and tasks. And here we see we've got two tasks. Deploy App, Service to slot, Manage App Service, slot swap. Now since we want to deploy to dev, have a form of manual approval and then deploy to life. We're going to remove the slot swap for the stage now will go to go to deploy to death. We're going to select the Azure subscription, which we have defined with our servers connection. We're going to select Web app on Linux. We're going to select the app service name that we have already textured. So we're gonna select the Resource group and the slot, which is going to be deaf. Very good, safe. Now will go to go back to the pipeline and look at the artifacts. You're going to click on ads. We want to choose our Build Pipeline, build and test. And for the version we're going to choose the latest version. So every time the latest version of the Build Pipeline artifact is released, we will use it. Now. We're going to click on this lightening icon to enable continuous deployment. So we will handle the CI and the CD pot for content. And we have two options. Either we enable continuous deployments or we link it to the pull request. So I'm going to use a CD trigger and I'm going to add a branch filter. Mean that's done. Okay, the next step I'm going to run clone. And I'm going to say to life. And before this triggers we're going to use a pre-deployment condition. And what this does, it allows us to use pre-deployment approval. We will add an approver and we can add a time out. So we can say your time out of 24 hours for example. So what will happen here is that it will finish with deploying to deaf and then stop or manual approval for 24 hours that people who are going to be added to approvers will be getting emails, asking them to assess and approve. This stage, we go to the Life and rather than using deploy App Service to slot, we're going to swap slops. And to use App Service manage swaps lots. Choose our subscription, our App Service, our resource group, and our source slot. And here we're going to tick swap with production and we click on safe. And with that, ladies and gentlemen, we have finished a CI CD pipeline. Let's pull the latest changes from Maine because we added pipelines, so we have to pull those changes, right? Checkout to publish live Jose, you life, okay. And another row. Published life. Next push this feature. Publish alive. We push no upstream branch, yes, good. You got to pull requests. You update it, new life. Okay. That's tied with a work item. Let's tie it with a reviewer. Know, merge conflicts. Warner view must approve, approve, completes, and away we go. What's going to happen now? Emerging pull requests. And now we're going to build and test the website. Let's see. Alright, so the artifact is published, finalize and job done. Now if we go to release, refresh it again, we'll see have released one is check this out. Here we go, Qd, si deploy to dev agent who's ready for the job and this wait for it in progress. Now it's going to deploy to the development slot or right at that succeeded that see what you did. Deployment using zip deploy initiated deploy logs can be viewed. That's done. So it's been deployed to tech jiu-jitsu dash app. So let's take that URL and open it here. As you can see, we have our development website. We've got the picture of the counts. We got the table over here. Looks good. Who We Are. Gets in touch. As you can see. Looks good. Go and back to the release. We see that deploy to life is pending approval. Now this should send me an email. Let me check my email. As we can see here, we have utrification asking for approval. Once you're happy with that change, you can click on View approval. Click on approve, give the comments. Or you can defer it to later. And that will automatically trigger the other stage of the release pipeline. And this stage is going to swap the development with the life deployment and progress. Swapped over life, done. Let's check the log that's done. So now if I go back to the website and remove the deaf suffix. Our website is life. And with that, ladies and gentlemen, we have deployed our first continuous integration, continuous deployment pipeline using as your DevOps, I hope you enjoyed this course. I am very excited to see how you progress with it. If you have any questions, any comments at all, please don't hesitate to get in touch with me and I'll do my best to help you out all the best. Thank you very much. Goodbye. 9. End: Thank you for following the course. I hope you found it very informative and useful. You will find all the course materials in the course description below. And again, if you have any problems, if you get stuck anywhere, please don't hesitate to get in touch with me and I'll do my best to help you out. Thank you.