Migrating Classic Azure DevOps Pipelines to YAML with Manual Approvals

hi everyone I'm Jason speck land a cloud solution architect at Microsoft and this is today's Asher dev tip in today's tip we're going to be migrating an azure DevOps pipeline from a classic pipeline to pipeline as code with the brand new manual approvals for llamó pipelines now in general availability so let's take a look at our existing classic pipeline so that pipeline is gonna be divided into two stages it's gonna have my build and my release so let me look at my build we're just building an asp.net core web application on Windows 2019 and here's our release pipeline now this one is actually also pretty standard what we're doing is we're getting that artifact there we go that artifact from our build pipeline we're first deploying it to our dev environment and then we're deploying it to our production environment and if we dig in here we'll just see that we're deploying to Azure app service again nothing particularly exciting but the thing that we want to talk about the point of this whole exercise is right here so this pre deployment approval in our production pipeline and another thing to take a look at will need to worry about when we make this a llamó pipeline we have these variables and these variables vary between our dev environment and our production environment so let me go to pipelines and take another look at that build stage and if we click right here an agent job one will see this little view yamo button which looks like exactly what we need so let's click on that and what pops up is this really ugly already highlighted thing filled with errors it looks really intimidating I am NOT a fan of this message but we can actually fix all the things that are in here pretty quickly let me paste that code that we just copied into here and here we have again all these error messages here but first off we can see that there kind of twice we have this your build pipeline reference is an undefined variable named parameter stop restore build objects so we see that that is referred to in these projects inputs to these yeah mol tasks and as it turns out we don't actually need this value here at all the project's input is for when we have several different projects but we only want to build one or some of them with a path selector so we can actually take that or right out and don't have to worry about it anymore cool we are halfway there next thing is our pipeline references to build configuration variable so we do need to set that so let's create variables here for our pipeline and I do want one called build configuration and the one I want is called release because I do want a release build not a dev build because this is actually going to go through our pipeline and eventually end up in production so I don't want a debug build inside there so that actually takes care of all that we need cool except this pool name as your pipelines not quite what I want I do want to specify the deployment pool that I want to use so I want to use the VM image and I want to use just what I was using before in my pipeline windows 2019 okay and one more thing that I want to do just like in my original build pipeline I do want to make sure that this is triggered every time someone commits to the master branch so let's do that trigger and we will say - master and there we go our code has been synced to master so let us go back to Azure dev ops and take a look at these pipelines here and we don't actually have a new pipeline running and that makes sense we haven't set up this Azure - pipelines dot you we'll file to run inside of a short DevOps yet we actually need to tell that to happen but the way we can do that's pretty easy we just go to new pipeline and it's gonna ask us where our code is and in our particular instance I've put my code in github so it's easy for you to see when this video is done and yeah here's how our DevOps pipeline approval demo and what it's actually gonna do it's gonna look at the code and if there wasn't already a Yama file there what it would do is to kind of suggest a bootstrap yamo file to use but there already is the yama file the M will file we just created so it's gonna say hey do you want to use this and I say yes I do want to use that that is exactly what I wanted so I'm going to say run so let's take a look at how this is coming along all right running our job that looks good now thanks to the magic of video time has gone by really quickly for you not at all quickly for me but we can now take a look at what the results of that build was so if we go to our recently runs pipelines it shows our old one it shows our new one let's take a look at our new one we can you look at how it ran we can see all the the commits that are associated with it we can click on the job get more information on the job cool we've got our build pipeline converted to Yama now on to the release part of the pipeline so looking at our release pipeline right here let's first look at our dev stage we'll worry about prod in a minute let's select our app service deploy task and right here once again we have that view Yama button so let's click on that and once again we get something that looks kind of messy and error filled but don't panic we can still work with this so I'm gonna copy to the clipboard and I'm gonna stick that at the end of my Yama file now you see once again we have steps and a task and what we could do is just take this task and stick it on the end of our current build pipeline and that would work but we might have an issue where if we have a problem with deployment then that will fail our build and that's not quite what we want what we actually want to do is create different stages a multi stage pipeline so the first stage can be our build and the second our deployment so let's set that up the first thing I'm going to do is here this top level I'm going to say I'm gonna have some stages and I'm gonna say my first stage and I'm gonna call it build and every stage has one or more jobs and my first job is going to be this build job and every job has one or more steps so I already have those so that's perfect let me just indent those a little bit and then we are good to go so now we have our build stage ready so what we need to do is we need to convert this into our deploy stage so we're gonna have another stage and this is going to be called deploy and every stage once again has one or more jobs and now I'm actually rather than using a job I'm going to use a special kind of job called a deployment job so let me put that in deployment okay now one of the important things about these deployment jobs is that they can have environments and the environments as we'll see in a little bit is what's going to enable us to do that manual approval later but for now let me just put environment and I'm gonna call it death now I can put variables into my jobs I can scope them there and this is curious we got this yeah mph from our dev stage but it gave us the environment variables from production not quite what we want but something that is easily fixed so let me copy that into here and that's gonna be at this level and I don't want this to be production I want this to be development and I want this to be my dev value there we go all right so let's take a look at what's missing over here so I'm gonna need the connected service name okay that's the service connection that connects to my Asscher account and since we already had a working pipeline we already have a service connection we can use so let's take a look right here and really just this name right here is all we need so I am going to copy that and I am going to paste it into a variable I could put this variable up here so we can use it in a bunch of different stages now I'm going to say service connection and just gonna pop that right in there and now we can use the service connection variable done excellent all right so the next thing we need is app type okay now for that one we're actually gonna have to take a look at the documentation to see what we can put in there and here we see the app type we have a bunch of things we can deploy function apps web apps and containers mobile apps API apps all kinds of stuff but the thing we actually want is a web app on Windows so just simply web app cool that's that's easy so make that web app excellent the web app name that actually comes from the name of our application and no need to open a different window that's actually right here in our pipeline so pipelines approval demo - dev what an appropriate name I gave it let's just plug in there alright so now we've filled in all the blanks for these steps we need to put these steps into this job into this deployment job now deployment jobs don't just have steps they have what's called a strategy so let us put in our deployment strategy all right so I'm gonna say strategy I'll put that in there and the strategy I'm going to use is run once now there are a couple of different choices I have for strategies but they don't actually pertain to webapps which is I'm what I'm using for this example another strategy I could use this for example a canary strategy and that would work in a kubernetes cluster but again not relevant to web apps all right so I'm gonna say deploy now I actually under the run once I can plug in two different events here so I can do a pre-deployment event and do some stuff before I deploy or post deployment and I can do things either on success or on failure but I'm gonna keep this simple we're just going to deploy and after deploy we just need steps and we have steps that's exactly what we got so let me copy that there and let me paste it in place and I don't have to everything's gonna get indented in because of yeah ball okay there we go good to go okay so one more thing we're actually going to have to do we're almost there we're almost there now the eagle-eyed among you who kind of already know how this works might have said oh wait a minute you have this publish build artifacts tasks great but you don't have any download artifacts tasks how are you gonna deal with the artifact here well actually when we use this deployment job it's automatically going to download all of our artifacts for us how convenient is that but we do need to kind of tell this where it's going to put those because it doesn't put those in the default place so let we need to say package because that's the package we want to deploy and we're going to look in the pipeline dot workspace because that is where the automatic download is going to download stuff to so we're gonna look in the pipeline works place works place workspace star star star dot zip okay there we go eldest on our deploy is done we can see it split nicely into two stages right here we can take a look at our pipeline see our recent pipeline run see that it was deployed to two separate stages and now we can even take a look at either of those stages so now we've got the dev part done it's time to go to production but before we do that let's take a look at the environments tab right here in Azure DevOps now we can see that a dev environment was created for us that happened automatically because we specified an environment called dev in our Yama file but before we do that in production I think I want to do that manually so we can set up those approvals that we were talking about earlier so let me create a new environment I'm gonna call it fraud and there's resources that you can add for kubernetes or virtual machines so you can kind of see the state of the resource and as your DevOps and that's really neat except this is just an ordinary web app so we can't do any of that here but what we can do is we can add approvals and checks so I'm going to add an approval and it's gonna be me there we go and instructions please approve this won't you sounds good to me and now we have an approval on that environment so before anything gets deployed to that environment that approval must happen so let's go back to our Yama file and we should just be able to copy and paste this deployment and just chant change the dev values to prod value so let's try that now all right let's properly indent that because I've got us before all right do do I think that's okay all right so we probably need to scooch that over a touch let's see yeah there we go oh no one more that's more like it oh great so deployment deploy web app there we go to prod there we go to production the environment is going to be the environment name that I just created that's prod my variable is going to be prod value my environment name is going to be production you know more of the same or the same by web app name will be pipelines approval demo - prod all right and let's see then the rest should all be good to go here's my pipeline Oh Oh era right away let's see what my error was deploy job has an invalid name Oh aha okay so names have to be valid you can't have spaces in names but you can't have them in display names okay easily fixed and how we doing any mistakes nope running all good okay so here comes the build part and that's gonna take a little while here you see my the display names of that deploy jobs there we go all right here we go okay so our build is done and that's great but it appears that our deployment job is pending and it says one approval needs your review before this run can continue to deploy and that's kind of what I wanted but not really see it's asking for my review before it even deployed to dev so that's actually not what I want I mean the approval looks like it's working fine please approve this won't you accept it's happening before my dev deployment so what's happening is the entire stage depends upon that approval in production so what I need to do next is make the deployment to production its own deployment stage so the approvals work on the stage level let's see if we can do that let us open up our Yama file once again and what we need is a new stage so I'm gonna call this stage dev deploy and the display name is going to be deploy to dev environment okay and this is going to be to call this deployment deploy web app and I will call it dev and deploy web application to to death is what I wanted to display okay so we take all that and we want to actually have all those stage II things up here so let's come back here and paste that atop here and there we go let's eliminate our white space here and I'm gonna call this prod the poured deploy no prod deploy and this is deploying to the production environment and there we go everything else should be fine deploy web application to production prod okay so by queue by creating another stage we have made this so that the approvals will only apply to this stage let's see if that worked and we committed and let's see if that's running okay our pipeline is running and we click on it all we can see three bubbles indicating that there are three stages to this pipeline rather than two so that looks good here we have that display name that we want to deploy to death and here we have deploy to production that looks excellent now we just have to wait for the build to go to see if it deploys to dev automatically but waits for approval upon production and there we have it our deployment to dev happened automatically which is exactly what we wanted and our deployment to production is waiting for our review so I'm going to review it and I'm gonna say yes because I think I'm a pretty great developer and so my deployment will now go to production and that is how you migrate a classic pipeline to a new yamo pipeline with manual approvals I hope you've enjoyed today's Asscher dev tip thank you so much and happy coding

Channel: Microsoft DevRadio

Views: 15,989

Keywords:

Id: mddbdvcZkYw

Length: 21min 0sec (1260 seconds)

Published: Wed May 20 2020