Azure DevOps Environments EXPLAINED

as your pipelines is a great tool for doing continuous integration and continuous deployment and thanks to multistage pipelines we finally have built test and release together Express like source code recently they've also introduced the concept of environments which belong to the release process so the question is why should I use an environment for deploying my applications let's discover that together [Music] hello everyone and welcome back to Co today this video is the first in a short series of video regarding environments in Azure DevOps before we start take a moment to subscribe to this channel using the button below and enable the notifications so you will not miss the next video outpost today we're going to have an introduction to edge of the web's environments and why use them in the context of every pipelines environments basically represent a group of resources for every pipe lines and allow you to map your physical or virtual environments like development production QA etc into agile develops and one of the environments are the group of resources the resources themselves represent actual deployment targets for your pipelines at the time of recording this video only two types of resources are available to use in environments kubernetes clusters and virtual machines other kind of resources like databases and Ezer web app are still in development and will come soon so asking that again why should I use environments for my deployments well first of all they unlock a bunch of new capabilities you have traceability of comets and work items you have deployment history down to the single resource you have deeper diagnostics approvals and checks additionally when you target an environment from your pipelines you don't have to specify the service connection for your resources because automatically pipelines consume the service connection defined in that environment so let's see how to create and manage your environments here we are energy devops portal as you can see I'm in pipelines and environments and this is where you manage and create your environment if you see in the central panel I already have two environments let's forget about this for the time being and let's see we have this development so how to create a new environment there is this button here on the right called new environment and if you click it you can specify a name let's call it staging for example you can also set a description and you can select the type of resources that you want to add to your environment since this video is just an introduction let's forget about the resources we will go in-depth into resources in next videos and when you're done just click on create and voila your environment is created with the name and the description you've chosen so let's go back here and now you see we have these two environments that we already have before but we also have the staging environment and of course it says we've never deployed to it so how to actually use an environment let's go back to pipelines and let's see this pipeline which is the one I created for this demo if we take a look at the pipeline we see that we have a CI stage which has a normal job and then we have a continuous deployment stage which instead has a deployment job and as you can see here one of the parameters of the deployment job is actually the environment and in my case I choose development because it's the one I used before but let's go ahead and change these to staging and let's see what happens so let's save and run the pipeline alright the CI stage is completed let's take a look at the city stage alright so also the city stage is completed let's go back to our environments and now we see that the staging environment here actually has a deployment in it as you can see it's very easy creating an environment and using one but what if we go into pipeline and we try to specify an environment which doesn't exist let's change this for example to test let's save and let's go back to environments you see here pipelines automatically created for us an environment with the same name we used so this is pretty handy when you go for development environments or test environments you don't actually go here and all the time and create new environments even though I would say it's kind of preferred but you can delegate your edger pipelines to do that for you you also have to be careful because if you misspell an environment then as your pipelines will create a new environment for you directly and notice that I didn't have to run the pipeline for the environment to be created as soon as I saved the llamo which basically is committing it to our repository the environment has been created one question usually people ask is why should I use an environment if maybe I'm not using any kubernetes or virtual machine because as I said before and as we've sinned for the time being only kubernetes cluster and virtual machine are supported so for example I'm deploying to as your web app why should I use environment well because even though you're not using resources they still enable you to have full traceability and deployment history in fact if I go in development here I can see what is the status of my deployments for this environment in my case I only have one job here which is the deployment job and I deployed twice but the beauty of this is that if I have another pipeline which deploys to the same environment I can see here the list of pipelines the list of changes and everything that has been deployed to this environment also if I go inside to a single deployment I can always take a look not only at the jobs that compose that deployment but also the changes that were included in that deployment down to the single work items and this is what I was saying before that enables you full traceability of comets and work items provided of course you link your work items to your comets into your source control environments are also the way a multi-stage llamó pipelines handle approvals in fact if you're familiar with classic pipelines you know that you can set up pre and post deployment approvals directly in the designer but for multi stage pipelines you are not allowed to specify approvals and check directly in the yellow file and this is for security we don't on anyone to be able to remove or modify those approval and checks when they modify the pipeline let's take a look at this we are back at our development environments and let's say we want to add some approvals and checks to it first thing to do is go into this button here and select approvals and checks and here I have the full list of what is supported at the moment we have approvals which means that someone should actually click on some button to approve the progress of that deployment evaluate artifact which is still in preview and at the moment works only with container images and basically ensure you that the artifacts you're using are here to custom policies use you can specify for example in the case of container images you can specify they have to enter it from a specific base image and something like that at your function or invoke a REST API they are fairly similar they just have a different target as part of your pipeline you can decide to invoke error function to the Sun you know external work or some REST API for example if you want validate your deployment you can also query measure monitor alerts and this is pretty useful because then you can monitor directly you can check if you have any alerts if you have any failure and something like that last but not least and this is one of the new additions you can require all your pipelines to extend one or more llamó templates this is for example useful when you want to be sure that all the deployments in your organization's respect the same kind of structure and parameters you can define one or more templates and your pipeline will not deploy unless it extend one of those templates let's take a look more in depth and the approvals what I can doing here is add some approvers from the users I defined in my a DevOps and let's say I adhere to I can also specify some instruction and some Advanced Options for example which is the minimum number of approvals required I specify two people in this case so I either I can already select all or one meaning that at least one must approve but if I add one more user here and I go back here I can see that now I also have to which is basically the number of approver minus one and you can specify anything from one to all as required also you can require the approvers to approve in sequence and it's based on the order of the names you put in that box and also to allow a pervert to approve their own runs which means that I can approve the pipeline I just requested if you want to be even more secure you can disable this so a user that initiate a pipeline will not be able to approve it and I think this is the behavior you should look for easy right let's now take a look at the invoke REST API you can specify a connection type which can be generic or extra resource manager and this is because you may have passwords you may have secrets and keys that you need to use for invoking your REST API so you're not allowed to put them here you put in study in the service connection so you will also be able to reuse those you can of course change the method all the normal HTTP methods are supported and then you can specify headers body suffix and parameters if you go to the advanced I can also decide what the completion event should be if it's a callback or an API response and I can specify some criteria to define when to consider these records successful if you do not put anything as long as the API response this will be considered success or if you want to check for some specific pattern in your API a response then you specify it here let's talk now for a minute about security user permissions and pipelines permissions with user permissions you can control who can use view create and manage your environments and there are four roles creator reader user and administrator if you create your environments within the llamó files or basically you allow as your pipelines to create the environments for you all the country and administrators in your team project will be granted the administrator for that environment and this is normally used for dev and test environments but if you create your environments within the UI only the Creator user will be granted the administrator so the security is a little bit tighter and is in fact is the recommender approach for production environments permission pipelines instead can be used to authorize all or only selected pipelines to use a specific environment for deployments so let's take a quick look at this we are back at our environment page and we talk about security as you can see here if you hit security at the environment page where all the environments are defined for this particular team projects you only have the user permission tab you can see that you can specify users or groups specific roles and what kind of assignment I can also add a new user or group of course and decide what kind of role I want for that user if instead I go back and I go to a specific environment and again I go to security now I can see that I have both user permission and pipeline's permissions user permissions work exactly the same with the difference that the access type could be a narrative which means that it depends from the macro category or a sign directly from here if we scroll down to the pipeline permission you can see here that this is currently non-restricted which means that every pipeline may use this environment if I want to restrict this to a specific pipeline I will click on restrict permission and now no pipeline is actually permitted which means that I manually need to add a specific pipeline from here to use this for example if I want only the newer pipeline I created the pipeline with environment from UI then an enable it and this and only this pipeline will be able to use this environment of course I can always revert this and open the access and this of course will allow all the pipeline's in this project to use this environment open access and again you can see here there's no restrictions so this is how you secure your environments either at user level or at pipeline level all right I think is enough for today in the next videos I will talk more about specific resources you can use inside your environments like for example kubernetes clusters and the advantages you have using them be sure to enable the notifications using the small Bell button below so you will not miss the next video on this series I really hope you enjoyed this video and if you did please like and subscribe thank you very much for joining me today and see you soon at career day [Music]

Channel: CoderDave

Views: 17,670

Keywords: Azure DevOps, CoderDave, Davide Benvegnu, azure devops environments, azure pipelines, azure devops tutorial, azure devops tip, azure devops tips and tricks, azure pipelines environment, yaml pipelines environment, continuous deployment, azure devops pipelines tutorial, azure pipelines tutorial, azure pipelines yaml release, azure devops environments for beginners, azure devops for beginners, continuous integration, Azure DevOps Environments EXPLAINED, azure devops environment

Id: gN4j65w7wIM

Length: 14min 41sec (881 seconds)

Published: Mon Apr 20 2020