Pass Your Microsoft Certified: DevOps Engineer Expert Certification Easy!

Prepare with top-notch Microsoft Certified: DevOps Engineer Expert certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All Microsoft Certified: DevOps Engineer Expert certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

Deployment Mode

1. Lecture - About Deployment Mode

As previously stated, an Arm template can be used in two ways. One is the incremental mode, and another is the complete mode. To discuss this, let us consider a scenario. We have a resource group in Azure with two resources. Say that resource A and resource B exist. Let us imagine that our armoured plate contains infrastructure support for two resources: resource B and resource C. So our resource B is common to both the resource group and the ARM template. Resource A is only available in the resource group and is not present in the template. And Resource C is only available in the Arm template; it is not there in the resource group. So if I deploy this template to Azure in incremental mode, what happens is that the resources in the Arm template will be incrementally added or updated to the resource group. So the resort, which in this case is resource A, which is already there in the resource group, will be retained. Resource B, which is there in the resource group as well as in the Arm template, will be updated depending upon the configurations that we have defined in the Arm template. And Resource C, which is not there in theresource group, will be created to the resource group. To explain it further, So in this case, our resource group already has Resource A in incremental mode. What happens? Azure will check whether the template has resource A or not. If yes, are there any updates to it? If there are updates to it, then it will update the resource group resource, or else it will keep the resource as it is. So in our case, resource group A has Resource A. Templates do not have resources. So Azure will keep the resource A as it is. And then next we have Resource B, and the resource group template also has Resource B. So Azure will check if there are any updates to Resource B. If there are updates, you will update resource B to help keep resource B as it is. Then our resource group does not have resources, but our template has them. So Azure will add resources to the resource loop. So that is what happens when the templates are running in incremental mode. In our scenario, it will result in three A, B, and C) in a resource group. Simply put, in incremental mode, the resultant number of resources will be the sum of the resources in the armoury plus whatever is in the resource group. If there are updates, the resource will be updated. Now consider the same templaterunning in complete mode. In complete mode, Azure will completely neglect the resource group contents. That is irrespective of what we have in the resource group. It will deploy the resources specified in the template. So we have only Resources B and C in the template. The result after deployment in complete mode will be resources B and C only with the specifications given in the template deployed to the resource group. And as resource A is not there in the template, it will be erased or removed completely from the resource group. It's also worth mentioning that the default deployment mode is always incremental. That is, whenever you manually deploy a template from Portal, it always runs in incremental mode. So that's about the difference between these two modes. Let's go ahead and see a demo of how this actually works.

2. Demo - Incremental and Complete Mode

So right now, we have discussed incremental and complete modes, the deployment modes. Now it's time to see a demo of the same. So if you go to the build pipeline, you can see that if you go to the editor options, the deployment mode for the build pipeline is kept as validation only. But there are two more options, incremental and complete. So in the build pipeline, we are never going to change the deployment mode to anything else other than validation only. We are going to keep it as it is. But in release, we are going to implement these two deployment modes because the actual deployment is happening in realize. So go to the release pipeline, click on the keyword deployment task, scroll below, and change the deployment mode. As a result, it is currently only incremental. For now, let us keep it as it is. Let us keep incremental and do a deployment. So if you go to our keyword resource group now, you can see that there is only one keyword resource. DevOps tests QDT and G1, and keeping this in incremental mode, we are going to see what happens if you add a new resource to the resource group. So if you go to the repository, you can see that the keyword name in the parameter file DevOps test UDT and GV." But I'm going to do something else: I'm going to add a new keyword to the same resource group in incremental mode and see what happens. So let me go to the parameter file in my local repository, click on Edit, and add a new keyword name. Replace it with a new keyword name. I'm going to change KV One to KV Two. Let me change that and save my changes. So this time we are going to run an incremental mode so that KV 2 also gets deployed to Azure. Let me go to my command prompt and do a git add, then let me do a commit m to commit it locally. Allow me to test incremental mod with a commit message. So our changes are in local opposite. Now let me do a git push so that the changes will get pushed to Azure DevOps. If you go and see the Azure DevOps repository now, you can see that our keyword name changed to a new name so that we can deploy a new resource to our existing resource group. So the name is KV 2. come to a build pipeline, which is still in validation only. Click on queue and click on run Sothe build pipeline is going to validate ournew Arm templates with the new keyword name. Let us come back once the deployment Once the build pipeline is complete, you can see that it is taking the latest commit message in incremental mode. So I have just fast-forwarded a little bit. You can see that the build pipeline was completed. Now it's time to trigger the release pipeline, and remember that our release pipeline is in incremental mode. So come to release the pipeline click on "create a new list" and click on "create." As you can see, release two has been triggered. Click on that release to go to Stage One, which is currently in queued status. Okay, it's in progress. Now click on that "in progress" icon. You can see the logs associated with this particular list. So the job of getting an initialised artefact is in progress. You can see the keyword deployment task is running. It is going to take approximately 1 minute to complete. So the release pipeline got completed. You can see that the keyword deployment task took around 50 seconds. If you come to the resource group now and reload the resource group, you can see that a new keyword with the new name that we gave got appended to the resource blue. So the existing keyword is still there. KV One new keyword, KV 2, got appended to theresource blue because we are running in incremental mode. So all the contents of the Arm templates were added to the contents of the resource group, as we discussed in the previous lecture. Now what we are going to do next is change this deployment mode in the release pipeline from incremental to complete. So if you go to the build pipeline again, we are not going to change anything in the build pipeline. We are going to keep it as it is. That is, we are going to keep the deployment mode in the build pipeline as validation only. It will always validate the ARM template. But in releases, what we are going to see is we are going to change the deployment mode from incremental to complete. So let us do that. Go to releases, go inside the pipeline, and see the change in deployment mode from incremental to complete. Click on "Save." Now what I'm going to do is add a new keyword resource to the resource group. So now the repository contains KV 2. So because KV one and KV two are already deployed, KV two is the latest one. As a result, Repo contains KV two. Let me go to my local repository and add a new keyword resource. Change the name of the resource to KVThree so that we can deploy KV Three. So I'm going to change this name to KV Three. So let me change it to KV Three. Click on "Save." I'm going to do it from the command prompt. I'm going to push my changes again. Let me do a git; add a "let me do a commit" with a commit message. I'm going to give you the messages tested in complete mode. Let me do a git push so that we have the changes available in the remote repo. So the git push is completed. Now if you go and refresh the Azure DevOps repository, you will be able to see that the keyword name is changed to "DevOps U-E-T" and "GK 3." So we are going to run our built-by plan again. Click Queue, then Run, and our build by plan is underway. As you can see, it took the most recent testing complete mode. Let us come back once the build pipeline is completed. So it's completed now the validationis completed and it is successful. Go to Releases and trigger the release pipeline. Remember that our lease pipeline is still in lease mode and not in incremental mode. It's in complete mode. Click Release, then Create List. Click on Create. It's going to create a release using the complete mode. So you can see Release Three, which is in progress. Click on that. Stage one is in queue and will be in progress soon. Okay, it's in progress. Click on that "in progress" button. So the job is getting initialized. Artifact download is again in progress. Now the keyword deployment app is running right next to the right of the keyboard deployment name. You can see the time that it is taking, which is 7 seconds. 8 seconds now. So it is going to the task because deployment in complete mode will take much longer than incremental deployment. We will discuss why such more time for now. Let us come back once the deployment is completed. The keyword deployment ask is still running. We'll come back once it is done. So the lease pipeline in complete mode has been completed. You can see that the keyword deployment has to come around two minutes and six seconds, which is much better than the 50 seconds for incremental mode. So as of now, we have two resources in the resource group. Refresh the page; you can see that only one new resource is there in the resource group, which is the resource that we just deployed. So what happened? Actually, the resource that exists in the resource group is the same resource that exists in the Arm template. So Azure completely replaced its resource group contents with whatever is there in the Arm template. completely ignoring what was there in the resource group. If this template was running incremental mode, what would have happened? We would have had three resources for DevOps: UDT and GK, ones, two, and three, we would have had.But because we ran it in complete mode, what happens? The Arm template components' contents exactly replace whatever was in the resource group. So that is how the deployment works. In the case of a complete mode of deployment in incremental mode, they will be incrementally attached in complete mode. What happens is that whatever is in the Arm template that will replace rebates and auto is in the resource. That is why the release is taking too much time to complete. because it is doing that delete operation.

3. Demo - Parameter Overriding

Welcome to this lecture on parameter overriding. So if you go inside your Azure repositories now, you can see the parameter file there, and it has values such as name, locations, queue, etcetera. What are the values we're feeding into our Arm template plate? So if I deploy this template, this template is a keyword template. If I deploy this template, the keyword will have the name specified in the parameter file, "DevOps test," UDT, and GKV 3, and the location will be in the north central United States. Q will be standard. But consider the scenario that I want to deploy it using another set of values. So I want to deploy it with a different keyword name in different locations. So what is obvious is changing the parameter file, but parameter overriding discusses how we can change it and how we can deploy it without changing the parameter file. So you need to go inside the build pipeline, scroll down, and you can see an option called override template parameters. So if you click on that browse option, which is right next to override template parameters, you can see that it will list out all the parameters that are given in the parameter file. So this is the place where I can do that override option.I can give some parameter inputs here, and it will override the parameters that I have given in the parameter file. So let me change the name of the keyword to something else. KV three to KV four I am changing, and I'm going to also change the location of the keyword from an all-central US to some other value. So the idea is, we are going to dynamically give parameter inverters to the pipeline without using the parameter file, and keep in mind that I can change the location. Also north central US is thevalue you are in parameter file. I'm changing that value to "east US." Let me click on okay, so the remaining values I'm keeping as they are and I'm clicking on okay. Remember that the build pipeline is still in validation mode. Nothing has changed; we are just changing the parameters, but we are giving them annually. So I'm going to click Save On Queue to run the build pipeline. Save and restart the program. so the build pipeline will be in progress. So by the time the build pipeline gets completed, we can edit the release pipeline with the same set of values. Go inside the build pipeline, go inside one job, one task again, and go inside a key vault deployment task. Scroll down to the bottom and you can see the template parameters there. Before we override the template parameters, let me change the deployment mode from complete to incremental, which was a change that we made for the previous lecture. So, in that override template parameters section, you must also make the same changes in release because we are only violating where the actual deployment occurs in builds. So let me change it to KV-4 and the north central United States. To east of us And keep in mind that these changes are not impacting the parameter file in any way. The parameter and file will still include KV-3 and the north central United States. We are just changing, let us say, the release pipeline. So we are just changing the build and release pipeline. So the dynamic parameter inputs are given. So if you go to the Build Pipeline page now, you can see that the build might have been completed. Yes, it is completed. Now it's time to trigger the release pipeline. So, check out the new releases. Once the build is complete, click on Create Release. Click on Create. The release pipeline will be in progress. So let's wait for the release pipeline to be complete. So, instead of changing my parameter in goods, let's go inside the lease and see what's going on. Stage One is still in progress. Click on that in progress to see the logs. So on the plus side, for this particular override, I do not need to change my parameter file to test out some values. If I want to validate something using the build pipelineor deploy something to the release pipeline without changing myparameter file, I can do it this way. Thereby, my parameter file and the template will remain unchanged, and I can test the values using this approach. So if you go inside Azure Post now and look at the parameter file, it still refers to KV Three and the location is North Central US. However, the actual deployment that we are doing is KV-4 in the East US. Once the deployment is complete, you will be able to see that the keyword created will be in the locations that we gave overriding values. So the release pipeline is completed. If you go inside the let mego ahead and check in Azure portal. Let me go to the resource group to which we have deployed this keyword and click on Refresh. Now the KV Three and KV Four that you can see are, let us say, KV Three and KV. This KV-3 is a previous deployment that was used as a complete mode for the previous lecture. KV Four is the deployment that just happened. So if you see KV Four as the location, right next to that is East US. And if you go to Azureapos, the temporaryparameter file is still referring to KV Threeand location is North Central US. So if this deployment had happened, the actual deployment should have happened in KV Three. However, because we provided an override scenario, the location is East US, and the keyword name is "DevOps test unityng KV4". Now, as I mentioned, you will be able to override the template parameters and test without changing this parameter file. This is especially useful in the validation section of the inbuild pipeline, where we can validate changes such as whether this location is valid or not, whether this name is valid, and whether the changes we make impact the template in any way. Thank you.

Production Deployments

1. Lecture - About CI/CD

This time we have been triggeringour build and release pipelines manually. That is, whenever a code push happens, we will go and trigger the build pipeline first, wait for it to complete, verify that it's successful, and then go and trigger the release pipeline for deployment. But is this approach practical? Not at all. We cannot have a system where, each time a deployment is required, we can go and trigger our build pipelines manually. It's a very repetitive task. So in the real world, we need our build pipelines to get triggered automatically whenever there is a code push to the repo and our release pipelines to get triggered automatically after a successful build. So how we can ensure this? We will use CI/CD. We will enable continuous integration within our build pipeline so that it will continuously integrate or validate the code that we have in our repo. Whenever a new piece of code is pushed to the repository, it will continuously integrate or evaluate the code, and we will enable continuous deployment within our release pipeline so that it will continuously deploy validated Arm templates whenever its artefact source-build pipeline is successfully complete. Thereby, we'll have an end-to-end system where all we need to do is edit our templates and make a code push to the Azure Repository, and Azure DevOps will take care of the rest without any manual intervention. So let's go ahead and see how we can change our pipelines and how we can implement CI-CD in our pipeline.

2. Demo – CICD

In the previous lecture, we discussed the concept of CI CD and how we can implement it to enable manual intervention and make the build-and-release process a smooth and continuous process. So for that, as we told you, we will enable continuous integration within the build and continuous deployment within the release. so that whenever a code push happens to our Azure DevOps repository, the bill will get automatically triggered without any manual intervention. And once the validation from the build is complete, the release will automatically get triggered, causing a continuous deployment to our Azure portal. So go inside and build pipelines to enable continuous integration. But before enabling that, go inside the keyboard task. And for the previous lecture, we have also enabled the overriding template parameters option. So I'm going to clear that part, the override template parameters. I'm going to clear everything in that checkbox because it is going to conflict with what we are going to discuss here. And I've saved my built pipeline after that, and I'm going to go to releases. Click on Edit. Click on one job, one task, and then another. I'm going to do the same here with the override and the parameter change that we made to the pipeline. We are going to clear that part. So clear everything out. Click on "Save." Click on "Okay," so that's it. Now our pipelines are ready to enable CACD. Go to the build pipeline again. Go to the editing options. Right next to task there is an option called variables, and right next to that there are the trigger options. Click on the triggers. You can see that the continuous integration label is displayed. Click on that checkbox, enable continuous integration, and make sure that the master branch is selected. We'll come to that later for other branches. Or we can click on "Save. Save again. and that is how you enable continuous integration for the build. Now go to the releases and click on Edit, and under artefacts there's a small icon for continuous deployment trigger. Click on that and change theswitch to from disabled to enable. So the continuous deployment trigger is also enabled. Click on Save and click on Okay, so we have continuous integration and deployment enabled. Now what we need to do is push our changes to the Azure DevOps report to make a deployment. So for that, I'm going to my local repository where I have stored my keyword templates. I have opened my keyboard parameter file. Then I'm going to add a new keyword to Azure. So let me change the keyword name in the parameter file and make a good push. I'm going to name it KvTest CICD one. Let me save the file control, and once I save the file, let me save this okay and go to the command prompt. Let me do a Git status to check wherethe gift is tracking my changes or not. so it is tracking my changes. You can see it in the color. Once disconnected, I'm going to do a git add to add or change files. Get commit M with a commit message. Commit message. I'm going to give testing CI CD for first time. I'm going to give a commit message and I'm going to click Enter. Now I'm going to do a gift push, get a face push, and it is going to push all my changes to my remote Azure DevOps repository. So go to the Azure DevOps repository and refresh the page. You will be able to see the latest commitment that I have made. That is what is that? testing CICD for the person. So that commitment is there. We have the commit; we had the changes available earlier. What we used to do was go and trigger the build pipeline. So if you go to pipelines now, you can see that with that comment testing CICD for the first time, the build pipeline has already been completed. Why? Because when the code push happened, at that time itself, the build pipeline got triggered because we enabled continuous integration, and because the pipeline accommodates all the seconds, it got completed by the time we verify the repository, commits and all. If you come to the release now, you can even see that the release also got triggered once the build was completed automatically without manual intervention. If you go inside that, you can see that it's in progress. Click on that to see the logs, and you can see that the keyword deployment task is already running. So that's how it works. The corpus triggered the build pipeline automatically, and it triggered the release pipeline. So if you go to the resource group test, as you know, and let us wait for the lease pipeline to complete, we'll see the updated or added new keyword in the IJ portal, so that's how it works.It automatically triggers the build and release pipeline. Billing was automatically triggered after the code push. When the bill was passed, release was also triggered. So let's wait for it to be complete. Okay, it's completed now. The lease pipeline is completed. Now. Go to Azure and refresh the page. That KV test CSV one is visible. The new keyword was created without any intervention from our side. And the world was finished in record time. So this is how it happens in the real world. For a real production environment, this is how you're supposed to do it. enabling CI CD.

ExamCollection provides the complete prep materials in vce files format which include Microsoft Certified: DevOps Engineer Expert certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to Microsoft Certified: DevOps Engineer Expert certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.