hello and welcome to the broadcast everybody my name is igor dimianov i'm working as a principal developer at proactiv i've been working with the cloud services and the microsoft 365. and today i have my colleague abdel with me who is a an expert in the today's topic expert okay and at least i have some knowledge i'm gonna talk about how to securely deploy to the cloud with asia devops yeah totally hello everyone and welcome to our broadcast here my name is abdul rahman i work as a solution architect who's proactive i'm mainly focused at azure technologies and software development building integration and migration projects with our customers i'm delighted today to speak about the topic that is close to our hearts i guess and we usually work with it that often so it's definitely something that we would like to share today yes so let's jump into the agenda i have some slides here yeah basically we will be speaking about deploying to cloud services using azure devops how do we make sure of our governance and we have like a governance pro process segregation of duties who have access to our prod environments in the cloud um how do we establish this kind of infrastructure to make deployments from uh azure to from azure devops to the cloud and and general discussions about how do we have like an approval and a flow for doing the release so this is basically a discussion we will take and i guess it's one of the first topics we we touch based on with the customers do you agree igor i agree yeah so we're going to cover uh some of the processes uh today which are very important and it's important to consider them from the beginning of the project to define the scope and set some expectations and agree within the team and within the project how to structure those totally i i agree i mean it is one of the first things that we should think about when we start a migration or a new cloud solution because usually there is a process and for deploying on-premise and usually for customers they're familiar with the process they are happy with it they know how to work with it usually you have like a server or an assistant admin who takes over the responsibility of releasing and doing the deployments when in the cloud customers are really sometimes worried about do we keep our same structure do we keep our what kind of skills do we need how do we make sure that we have a secure deployments and we don't just leak or or deploy packages or malicious packages to our environment so yes for that i created this reference diagram which we would be speaking a lot along the presentation today so i try to kind of have a reference diagram to to the to to compare the old uh way of working via cloud and cloud technologies so if we look at the typical on-premise environments usually you would have a server this server would contain all your uh your uh solutions hosted on that server and then you you will have the system admin and i gave him the king figure i like this is the batman he usually have all the control he have full access to the system uh to the server and he knows what he's doing and he have responsibility he's usually he's a go-to guy and he's usually uh uh like the trusted yeah i didn't want to say a bottleneck but at least a trusted advisor um the assisted admin have all access to all the credentials and and and using those credentials he can access the different servers using those secrets so the system admin will take the package use the secrets and credentials to login to the server and deploy to this uh environment this is a typical on-premise this is an old story this is how we used to work worked great for many years right yeah so why the change i agree well it is it is a new era i would say and you don't have to rely on a specific people you can always have the tooling around it and plus i guess the system admin in the old days used to have like a log and a history of all the packages he deployed all that can come for free you have audit logs you have history you have approvals you have packaging systems all that comes for free if you start using azure devops and complementing that with azure services it's a great match they can work very well together and it gives you a lot of powers and of course with those powers there's also governance and security exactly one thing is it's not exactly free it costs a bit yeah yeah you have the subscriptions but yes i would say on-prem servers would cost much more so basically actually what you're saying that we can collect different dots in one place and we can have a full solution to manage all our internal processes for developing application making specification and releasing specification securely to the various environments exactly as you said it's one place that contains it all won't it be nice to have both your code your backlog your release pipelines and your packages and your environments all defined in one place and you have a dashboard to maintain it all yes that's what we well that's what azure devops comes with okay so let's back to the reference diagram if we look into the right side then i'm having i'm trying to map a one-to-one component between what we had on premise to what we have today in the cloud so for the servers that's obviously now azure your your your code and your solutions are utilizing the azure services and your your it's hosted inside azure cloud so this is uh the mapper for the on-premise servers as for the system admins we would still keep the system admins there would still be a person who are is responsible for the cloud but instead he would rely on the toolings and that would be azure devops instead of having his own logs instead of deploying his own packages all that will happen through azure devops as for credentials for someone to log in to be able to login to azure we didn't want to rely on a system account we didn't want to rely on a specific people so for that microsoft have give us what we call spn or a service principle the service prints will act as an it's it's basically an application in active directory that you can create and this application would give you access to the resources you need and of course it's handled and maintained through your admin as a tenant this application not anyone can create its specific people based on your organization policies and configurations specific people would be able to create those credentials or secrets or service principles and give them access to the right resources and then finally your package would be since we're using azure it could be an arm template or a binaries of an azure function and so on so this our reference diagram and what we will do today is that we will go through each of those components and show them as a demo in our portal through azure and azure devops and show how to create them and how to utilize them to guarantee a secure deployment to azure cloud um i think we have uh using the live storm you can ask any questions meanwhile and uh igor would uh be able to say that right yes yes i will be able to see them so if we just sum up about the diagram when we have all this on-prem versus cloud this is normally referred as lift and shift right so you take something that you have on-premises and you would like to move this to the cloud and what you're actually doing with this as well that you are kind of shifting a bit of focus from infrastructure and you actually will have more time on developing your application and not focusing that much on the number of servers how to patch them how to do uh keep them updated and so on yeah yeah well the left of shift of course is a concept that you can take the premise uh environment but you can relate to it yes you can map to it and it's it's a different it's not a typical one-to-one lift and shift but it is it is some kind of uh a mapper yes i agree perfect so let me jump in to taking the first component which is azure devops let me just stop the presentation so my you see my screen so the first thing we will speak about is a service principle which is the credentials in the old days let me go to my azure portal this is where all my services are located and if i go to right now i'm in the process of creating the credentials or the person or the app that will impersonate to connect to our environments so i will go to active directory and then under app registrations you would see that now i have two applications created what i call sod dev spn the service principle for my dev environment and another app which is spn for my production environment basically you can just also create your own application you can just give it a name based on your naming convention just i'll just write the dummy text now i will not create it actually created but basically it's an easy process to what i'm trying to say here is that it's an easy process to create your application once you have created this application if i go back to app registrations once you have created those applications it will have some kind of a client secrets so if i go to the dev environment and go to secrets you can see that okay i will not show it because the value is hidden anyway yes so you can see that will be some secrets that you can utilize those this you can consider this as your password this is where you will be your credentials to the servers but wait a little now with that we have the spn or the app does it have access to the environments how do we give it access to the environments what is the security model that's also part of the governance so if you would like to limit the app access to a specific resources you can still do that so let me take you to my next uh component which is our environments and i can actually add one comment yeah i like that you created two in theory you could just create one and give it access both to production and the dev environment but that's not we want right no you want to ensure that we can securely deploy first to the dev environment maybe to the test well and in this case into the production but we don't want to give people access to both environments with just one key we would like to separate dev environment with the dev app production environment with the production very good point exactly exactly we don't want our developers to have a tunnel on the two environments it's only separation it's only for for dev that's a very good point yeah okay so let me show you my environments actually uh right now i have other resource groups but those ones that we are concerned about is uh those two i have two resource groups that will contain all my services and as it is today i have a dev resource group and a production resource group this is just for demoing purposes but typically you would actually have three or four dev test pile one prod but as for demoing now it's just devamp prod so if i go to this service group which in again in our mapper diagram i can show it here we you can consider it as a server the resource group now you can consider it as a server this resource group if i go to access control then i will get an overview of all the users who have access to this resource group so basically i am of course a tenant admin so i have ownership permissions but i also gave the app that we just created the spn related to dev a contributor rights so anyone who is impersonating this app would be able to deploy uh add resources as a contributor and i can always add manage role assignments through different so let's say if i would like a redraw a reader maybe i could give a production espn and read write to dev just in case as an example i will not do that but just as an example then i can just go and say sud search for my production app and then you can see that now i have it this this application so so now we will actually will see resources but will be not able to create new resources exactly exactly so now we are kind of creating and making the wiring of our infrastructure just in the cloud so we created the user we gave the user the permission to the server kind of in the cloud this is all the wiring we are trying to do and and it's very important as we said in the in the beginning it's very important when you start a new project to think ahead of this kind of establishment it's i i would say devops should be something that's running in the dna of of of running the project and not come as a later phase so it's important to establish those uh wiring and infrastructure first in place and have them in place and test them along the process while you're developing so so you're saying that we should create our environments we should create our service connections we should ensure that we can deploy so the dev environment to the production environment just a small part of our application maybe and then we are when we assure that it works then we can start developing and adding more features to it exactly the first thing i ask about when i am assigned a new solution what is the environment do we have do we have a production what kind of platform what is the credentials and and all that you don't need to think about it of course you need to think about it but it should comes with small efforts in the cloud you should just create resource groups you create sbns and you don't need to think about credentials anymore in environments you will have them established for you and it's just simple clicks to do it and doesn't take much to time to to establish yes so great yeah perfect so if i go back to the reference diagram now we have created the spn our app we gave it access to our resources what's missing is the system admin who will actually execute it and the packages so that will make me jump ahead to azure devops let's let's go and talk about azure devops so just as an explanation what we are trying to do is that we are trying to establish the bridge between the two tools we have azure the cloud portal as a cloud provider and then we have azure devops again terms are very important because it could be very confusing naming naming naming azure devops is where it contains all our packages and source control we're trying to create establish a bridge between those two tools so we can push the package from azure devops to azure so this bridge would utilize the spn we just created it will impersonate the context of the spn we just created how do we do that it happens through what we called a service connection service connection is basically something in the settings of your tenant or your project if you have enough permissions you would be able to see it if you go to service connections then you would be able to create i already have two established we'll go through them but let me take you first through the experience of creating a new service connection when you press this button you would get a lot of options so basically azure devops here is trying to tell you well you're trying to establish a bridge to another tool or another environment is it azure is it a docker host vodka is it github there is a lot of integration with other services what we are concerned about today is azure classic is is actually establishing the azure connection to our azure providers so if i press next then it will actually um let me just go back to the resource yeah exactly azure resource manager because as we said our resources are basically resource groups so so i'll choose the azure resource manager if i click next then i will get two couple of options automatic basically if i choose the service principle to be automatic it will go ahead and create the app for me and hook it up to this service connection hook it up to azure devops the reason why i didn't do it automatically is that i like to keep my tenant neat in when it comes to naming convention and that's why i went manually to the active directory and created the app myself give it the right names give it the right access and then i will manually edit here so i'll choose the manual option if i have the app created yes and i think the automatic version it also requires that you already linked your a asia active directory tenant with your agent devops tenant yes otherwise how should it know where to create exactly exactly you need to have the right access you need to have the right permissions to run this wizard and to create it automatically of course it doesn't there is some security trend to it as well okay so if we take the service principle manual then it will ask me about my subscription id which is my azure subscription basically it will ask me about the name of the subscription and then the service principle id so if i go back here and go to the active directory again let's go to the app to the apps we just created or created previously so let's take the dev spn you would see that when it loads you'd see that the application have an object id this is the spn this is a service principal id this is the id of the user the service connection or the bridge will impersonate and then it will ask you for the service principle key which again is the secret of the app so this is azure devops asking me for the username and password kind of what is the idea of the user what is his secrets so now that i would configure all this then i would actually establish the bridge so let's let's take one of those already created today for the demo we we're running out of time so let's let me just show you that i already created the established establish the connection with the azure cloud i provided it with my subscription id which is this this name and then i gave it the service principle id if i go back it is uh application application id sorry it's not the object id it is application id here and then i provided it with a secret that now now i have a bridge those two are considered like a bridge to the two resource groups to my two dev and prod environments we have in azure so every time i'm doing a deployment i don't need to go to a specific person ask him to log into the resource group using his credentials to have using his access to deploy the package i can easily utilize those two bridges to push packages so this in all days we could refer to it as a service account yes to some extent exactly yeah yeah yeah and and now basically it's important to know to say that everybody who has access to this service connection within this uh project can utilize it exactly that's a very good point that's our next that's our next uh topic here because wait a little this this event is this this broadcast is about segregation of duties it's about governance now you're telling me you are you have established up two bridges to our product production and everyone in develop azure devops can start using it as it is today yes you can but as it is in the current state yes you can but later on on the event i will show you how to govern and secure your your service principle it's important to note a mental note here is that this bridge is your bottleneck basically you don't have any access to your environment except through this gate this service connection we have so if you are able to govern the service connection if you are able to apply special security on this service connection then you are kind of also gating and securing your environments because you'll know that this bridge or this credential no one can use except he has the right permissions but first let's test our connections first so let me go to our resource groups uh dev and prod you see that we have a storage account here created previously i'll just delete it quickly yes cleaning up cleaning up and meanwhile i actually have a code so back to the point everything is in one place my code is here um i'm basically have created a source code that will quickly create a storage account which is a storage service in azure and and i also have a pipeline that's utilizing this repo this pipeline consists of three steps building my code deploying it to dev and then deploying it to production but does how does it do the connection to service to to azure if i go to the code here you would see that in my yaml file i'm using i'm referencing the names of the two service connections we just created so now i'm actually telling that my pipeline my release pipeline to utilize those two service connections since they are open to anyone at the moment we'll get back to that to deploy to uh azure devops so let's go ahead and run this pipeline basically even while it's running even if you have a yeah when you have some developers they can already start utilizing it they don't need the secret because somebody else already authorized this connection yes they verified it it's there it's ready to use exactly exactly all the wiring is happening for for the developers you don't have to worry about it and again this shows the powers of utilizing the cloud tools in the back back in the days you had to have a server remote connect to that server get your package copied to that server and install it now it's just a matter of clicking the different tools if the wiring and the setup is done correctly so yeah this will take around two minutes to build and deploy um but do we have any questions in the meantime we don't have any questions but um we can just talk about it yeah and i'm thinking that that comes actually to the now we said that we are we are setting up the service connections we are creating a tunnel between the asia devops and the asia environment uh and we would like to actually push the packages now so now our developers they can start developing application and it comes to the kind of base of the devops principles and hence the name asia devops so now we have actually created an environment for our developers who can start developing applications exactly exactly yeah of course you will limit them at some point so they don't push packages to the production environment but it should be open towards the dev environment we don't need additional button bottlenecks no invented in our pipelines so once we are sure that our things are building and eventually tested then we can just ship them to the development that's also one of the points here is like that's the whole concept of continuous integration we this this this event here is not about continuous integration but we are partially touching based on it because once as a developer once i have done my code i have no limitation i can just push it straight away to them and using the right establishment and so on yes um so this is working and there's some one more thing while we're waiting i would like to show when we started the topic we talked also about auditing and history here you can see in this dashboard all the runs and who have executed those runs in which environments so this is also very obvious you you have a clear understanding on what you're deploying and where so yeah now you can see that the div environment has successfully worked so if i refresh my resource group you would see that now azure devops have compiled my code created a package using the service connection or the bridge impersonating the app we just created had access to this resource group and actually deployed the storage account so although flow and all the warnings now is in place however there is something that's terrifying now that once we have successfully pushed dev it went straight away to production what we need to somehow restrict this yes so how do we think this through how do we enable security so uh during our talk we talked about that the service connection is actually um our bottleneck our our backlog our our bridge to the environments so now if i can secure the usage of the production service connection i'm sure that no one can can go deploy again to our production environment how do we do that so let's go ahead again to our service connection and go click those three buttons now a very interesting two options show on the service connection configuration there is a security and there is approval and checks so let's go ahead and figure out what this is about let's go first to approval and checks so here i'm presented with let me zoom out a little maybe yeah here i'm presented with a different options so basically this is azure devops telling me okay we can give you a gate or checks so before you push anything or any packages through this service connection you need to pass those gates and the gates could be approvals it could be that this code is coming from a specific branch it could be that we are deploying within a specific service window so we don't take the environments down while everyone is working on it so there is a lot of gates that you can apply on your bridge to production so i will go ahead and say the typical and the easy flow is we see at our customers is that there is somebody who is concerned or responsible for the production environment and we need his signature or approval on going to production so i will add an approval method here and then i will uh choose my friend igor do you know him yeah yeah but it's very dangerous that you give him access to production no you you you're fine you will take responsibility for for that you have the powers and here comes a very interesting option as well i'm actually disallowing you if i uncheck this checkbox i'm actually disallowing you from approving your own changes so even though you have access to approve releases to production you don't have access to approve malicious packages that you develop yourself so everything that i develop will never come to production unless someone else approve it unless i i'm i'm approving your changes and this one of the concepts here we are defining segregation of duties we we are ensuring that at least four eyes have looked the code have looked the packages and approved each other before going to releases this is actually very important i mean no matter how good you are at whatever you're doing we all are humans we all do mistakes and it's always a good idea to have somebody else to look at is it your code or something else so you should not in theory if you're at least if you're on a bigger project and you have the option to have a colleague to look at your uh exactly they go through it and eventually approve so actually we can establish this as a team there is there's multiple setups we can establish this as a team on test environment so as a developers all if we are a team of developers we can say that we don't approve any changes to test the environment unless someone else have looked at it that's one way to look at it but if it is production then we don't even give access for developers to approve it it needs to be a release a system admin or someone who is responsible for production that would be added to the approvals the gate approvals on that bridge so you can utilize it in different ways depends on the environment you have so now i'm adding you igor as assisted admin to production um this allowing you to approve your own changes thank you and i will do that i'll create this one so that's the first step then i would like to make sure that once we have set the approvals no one go through the back door because they have enough permissions to the service connection and change the configuration of the approvals exactly or override the policies that's also possible so that comes to the part of a governance there is a lot of governance going on uh so if i go to the security part here you can see that by default out of the box the service connections have two groups added contributors and in-point administrators and they are they have administrative rights on the service connection what does administrative right means that anyone who is part of those two groups can go in add approvals remove approvals modify gates and that's not what we want in production we want to secure it and and keep it locked on a specific people so we can also change the permissions i guess and change the permissions yeah exactly so we have created the segregation of duties now we are speaking about governance security so i will go ahead and remove all the contributors i don't want the contributors to be able to change that and i'm already tenant admin so i'm here by default and then i will lock it down only on the endpoint administrator endpoint administrators are typically in an organization are typically the azure devops tenant admins they are the ones who have access to all the bridges and they can manage it they are the ones who are giving the right security so i would keep the endpoint administrators here and then remove all the contributors no one can go in and change you as an approval or remove you or add himself as an approval now when i do that so let's restrict the permissions now and save okay and it sounds like there are small things but these things are very important and it's important to take the decision from the beginning actually who will have access to change this yes so you suddenly don't push something to production that should actually not be in production yeah exactly so that's that comes to defining roles within the teams who who is the system admin who is the one who is signing this release is good enough to go to production and responsible for it so yeah definitely okay now that we have secured our bridge let's try again and rerun our pipeline and see if it will go to production that's going to be interesting so let's run a new pipeline oh not create a new pipeline sorry just go to my pipeline and run a new execution and this time i'm hoping that it will build and go to dev and hopefully someone needs to approve releasing to production first so let's let's go ahead now um and i will show you in my resource groups i'll go to production this storage account was created yesterday i was just deleted for now so before we could deploy actually to the dev and to the production and now we expect that it will stop at the production and wait for my approval yes exactly it's it's expecting um that actually while this is running i would like to show you more some more options which is are quite interesting so if i go to the service connection um we talked about governance and security but there is a lot of other configuration you can also do so if i go to security now that you have choose i was in the dev let's go to production service connection here and go security now we have limited who have access you can also limit this bridge or service connection to be used by a specific pipelines so this no specific source code or a specific code base that are able to access this bridge and utilize it so let's say if you have a case where you have a lot different teams working with different environments working in the same azure devops team you can actually still segregate the permissions across those teams so you can specifically say that this bridge or service connection is only available to the pipeline releasing my storage account so it's also adding additional security yes more more governance and uh yes so i will i'll actually go ahead now and and and do that i would restrict the permission and right now i only have one pipeline for demoing purposes but if i had more then i would have seen more but right now i'm saying that this service connection can only be used by this pipeline yes let's go back to our run okay now we can see we have built and we did deploy to dev but it didn't go to production but why i'm a developer i would like to push it to production what's going on i see that we need someone called igor to approve my going live to production if i go to production if i'm developer and i have access i would doubt that but if i did had access to production as a developer read writes you can see that my storage account is not there i will call igor and ask him to approve this even though you are the project admin here and you can basically do everything in asia devops you are the organization admin as well but that's not even enough because now you decided that i should yes approve the pipeline exactly so i'll do that please please so what igor now is going in and through his laptop is is actually exiting my portal and as his changes he just approved it and you can see that it's now instant that you see that my my pipeline now have been approved and it says okay checked past or the gate that we have configured is now passed and now it will hopefully soon push it to production and we can have a storage account live and this way we have again the traceability right who allow this and the what's been pushed so we can always go back in time and see what has been released to production who approved it why and if needed then we can also go back yes totally good point i can actually now go and see who have approved going live it's you do you trust me enough to push this package i can see that okay perfect so yes back to your point you can actually see the history and track what kind of signatures are are applied to this package to go to production which is again very good and secure way let's see if our storage account is here still working on it i guess on the way it's taking some time okay we have nine minutes left so meanwhile this one is deploying to production i can show one last feature i would like to show to to tell you about if if i go back and go to my approvals and checks which is basically our gates you can see that now we have added the approval gates but i also said that we can add other kind of approvals um you can say that i needed to come from a specific branch or it it it should invoke an azure function this is one of the nice features if you are actually trying to deploy to an api but before deploying it you need to make sure that the environment is healthy and running for example so you can easily ping your environment and see if there is or not but talking about branches i can check the branch and then i i can't remember the exact sentence to be honest but i will try it so if it doesn't work don't blame me that feature i can go to my yaml file here and uh sorry do this one and say i think it was origin um i would like to something like masters something that is no it's not like that uh once again yeah ref heads release yes i got now uh so i would like to only restrict it to deploy to production if it is coming from the master branch and what now and now i think it's called main main yeah i think in your case you had main yeah yes so i will just now restrict production to only deploy code from main let's uh jump back to our pipeline and then see uh what we just as against the new gate we applied okay now production is successfully done and now igor have approved my storage account to production you can see it is here perfect let's let's move into the new gate we just applied branch and control this is all live i'm trying it now so if it does work but i know it will work hopefully so let's go to my yeah my repo i think i'm ready now to merge to main so let's see if that will work we can try running well i don't think we have time but we could it could be interesting to run it again and in theory it should not go even though i approve it that's a good point let's let's let's try to deploy again to production from a branch that's not the main let's go to deploy directly from my feature branch i believe this will fail according to our configuration here it will fail because production is only having a gate that it should come from the main branch so this would be very interesting to see once the build is done and this is kind of you can you can manage it in different ways you can manage it on the level that we have just done you can also do it through the definition in the yaml file basically so there can be many ways to achieve it but in general we don't actually want people to deploy something to the environment from their feature branches because we are not sure that the code is stable there yeah so we need to go through the build phase test phase and packaging phase and once this is done then we actually would like to move to the dev and and and edge devops comes with a lot of tooling we are only touching based on a specific area in azure devops but there is also branching policies there is also packaging policies and other kind of stuff and they all complement each other so back to your point we can easily utilize azure devops to apply branching policies so that you cannot merge to main unless someone have code reviewed your changes so i'm as a developer i'm working in my feature branch i'm fine i'm deploying to dev environment but in order for me to push it and release it to production i need to merge to main and before i can do that the azure devops will enforce someone else to look into my code so we have two types of approvals now we have some a developer who is looking into the code reviewing the code and then once it's have been merged to main then we have another guy who's a system admin approving the package to go to the dev environment so now if you look into my pipeline it is expected failure yay you can see that now it's telling me yes you're trying to push but one of the gates have failed let's have a look what did i do branch and control failed so this is basically saying azure devops saying now you're trying to push a package from a feature branch it needs to come from devops just to wrap it up quickly we talked about on-premise old way forking we talked about one to one mapper between the cloud and how we established the wiring once we have established the wiring bottlenecks and bridges we talked about how do we add more gates and easily establish an approval process and we also talked about how do we limit it on a specific people who can securely manage it and and and and specific pipelines so yeah i hope i have four four minutes left so i don't know if there's any more to should we move it to the main branch now and just to show that actually it will pass the check um let's do that i don't know if we have enough time but let's see that's a good point let's see that's a good point there are some questions actually i think we can answer the question while doing a put request quickly um ola asks is it possible to share your gamo file would like to yeah they would like to have some experience with staged pipelines if it is possible to use yaml part lines no no if it would be possible to share your yaml pipeline was across across different triples or different teams no no with the with the person asking a question oh yeah sure i can definitely let's uh if i can get your if you send us your email i will provide you with a source code for the entire setup absolutely no problem yes yeah yeah so now i'm i'm quickly creating a new go live uh pull request and there's an advertisement i have on github account with all the because i am the yammers and the movie stage and documentation so send us an email and we will send you a link yeah perfect so now i'm completing my merge to main i do squash emerge i don't want to delete my feature branch and again based on policies i could have enforced somebody to review me i couldn't have completed this pull request before somebody to review me my code but having said that now time constraints and the demo purpose we skip some of the practices exactly but but you can see now that the code is in the main branch it has been merged exactly i agree we are running out of time so i would quickly that automatically speaking of continuous integration automatically triggered a new deployment and that would do the build and what i'm expecting now that the first gate would be successful because we are running in the main and then it will ask you again to approve it so let's wait a little uh let's wait yeah so we have your own github prep with all the yaml oh yes nice nice it's a bit uh not outdated but it's been a while since i set it up but it should still work yeah yeah are there any other questions maybe yeah if you're a developer you're used to waiting for build pipelines i guess if you have any questions regarding the multi-stage pipelines and if there is any interest we would love to share our knowledge i guess we can arrange a new a new session actually based on that on the if please send us other areas in azure devops that you would like to touch base on or even azure uh azure solutions we i'm actually planning to speak about uh different sessions in relation to azure so we have coming up session about azure v-net but more will be published later yes if i go now to this pipeline you would see that it have actually passed the branch control and now waiting so now it's only me is approving it and uh we are uh good to go so i think refreshing will run now and two checks passed and our changes would go live i think this wraps it up it's uh it's a big topic we tried to uh just explain it quickly and easy in a 45 minutes but of course we would be happy more than happy if i have more questions or any anything we can help with uh we would love that um yeah you can uh drop us an email i guess asia devops asia ci cd pipelines we are big fans of that and uh and love to help it's a it's a pleasure it's a pleasure to work with this tool every day i i would say it's it's one of my passions so it's perfect yes thank you for joining today have a nice evening thank you bye