hey everyone in this video we're going to talk about how you can design a deployment pipeline using get Ops principles so if you're looking into designing a deployment pipeline or just want to learn a little bit more about get Ops this is going to be the video for you now this video takes place after my last video which was how to design a cicd pipeline so if you're not sure how to design a cicd pipeline make sure that you watch my previous video I'll leave a link Down Below in the description now let's go ahead and get get started with the design of our get Ops pipeline all right so here you can see that we have a pretty simple cicd pipeline this pipeline takes our application code stored in our application repository takes it through the source build test and release stage and basically the output is going to be a container image and that container image is stored in our registry so you can see we have our application right here and it's version 1.0 so where where do we go from here this is where we need a continuous deployment pipeline to actually take this application image and bring it over to our different environments so the first thing that we want to do when designing our deployment pipeline is create a second repository to house our configurations so our cicd pipeline is going to checkout code from our application repo but our deployment pipeline is going to use our configuration from our configuration repo so this is a traditional get Ops pipeline so let's create another repo here and then we'll call it config repo and this config repo is going to contain all the configuration files that we need for deploying our application so this could be anything from like Docker compos files to kubernetes manifests so let's go ahead and populate this config repo with some manifest files so I'm going to put uh kubernetes manifest file here here and let's just think about what would be in this manifest so in this manifest we would probably have something like a kubernetes deployment so we'll call it deployment and this deployment probably uses an image and the image it's going to use is going to be the image from our cicd pipeline so we called it my app and we'll just tag it with uh v1.0 now let's just move this out of the way and get an environment for us to deploy to so we have our server here and this could be any type of server we'll just call it our test/ QA environment now your get Ops pipelines can deploy to your environments in two different models the first model is known as the push model so we'll call this push now the push model is really simple it's as simple as just doing something like a cube control apply so we're just going to keep it as that for now and then I'm going to discuss the pull model which is the more modern approach of actually having an operator installed in your environment that pulls down your configurations so let's talk a little bit about how this pipeline gets triggered in the first place so your deployment pipeline should be triggered automatically at the end of your cicd pipeline so let's draw an arrow here from our cicd pipeline CU it's going to trigger our deployment pipe line as soon as it's done completing now every time you run your cicd pipeline it should be turning out a new version of your application so you can see here we have version one of our application and the next time we run our pipeline we're going to get version 1. one now if you have a really well-designed pipeline what you may want your pipeline to do is to actually go into your configuration repository and submit a pull request test or just push a change to it to actually update the image so here I'm going to update the image tag to v1.1 and all my deployment pipeline really needs to do is Rerun Cube control apply and that's going to deploy it to my test and QA environment now once the code is actually running in your environment you should have some observability tools plugged in to monitor your application so at the very least you should should have something like Prometheus to scrape metrics from your applications and then you should have something like grafana so your QA teams can actually visualize the changes and make sure things like the latency hasn't increased and all your key performance indicators are up to Snuff now once your deployment has been running in your test and QA environment for some time what's next is to promote it to your other environments so usually will have something like a staging environment and a production environment so staging environments are usually just environments that are similar to production it's where you send your deployments first and you're basically pretending its production you sort of treat it like production uh but it's not production and then production of course is where your Live code runs this is where the customers are accessing your applications so let's draw some arrows to these environments here and and the way that these environments get pushed to is they can automatically get pushed to by your get Ops pipeline or these can be manually gated by a person so sometimes companies aren't comfortable with having everything automatically trigger to their staging and production environments usually they want an engineer to actually run the pipeline manually so these ones might be manually or automatically triggered let's now talk about the pole model and then I'll get into canary testing which is a common thing that's done in production environments so with the pole model I'm just going to take these arrows and I'm just going to change the direction since they are pulling their configurations and deployments down from our configuration repo so instead of a cicd server doing a cube control apply they would have what's known as an operator installed in them so if this is our kubernetes cluster then we would have something like Argo CD installed into each of our clusters and basically what Argo CD does is it just checks your repository and it checks the state of your clusters and if it notices if the state is different in your clusters then it is in your configuration repo then it tells you it's out of sync now it can automatically sync your environments for you or it can be manually triggered again so you may have your test and QA and even your staging environments do what's known as an auto synchronization through something like Argo CD and then you can have your production environment where someone actually needs to click the button to sync the environment so Argo CD is really simple to set up actually and basically you just point it to your get Ops repository and then it just checks your configurations if anything's out a sync it'll help you sync it I do have a full length video on how to set up and get started with Argo CD so if you're interested in working with Argo CD make sure to check that out I have a link in the description below let's now talk about Canary deployments which is something you should absolutely introduce into any deployment pipeline so let's talk about how our user actually talks to our application so we got some users here and those users usually talk to our application not directly but they talk through what's known as a load bouncer so the load balcer is going to load balce traffic to our application so our application is running under a kubernetes pod so I'll just say this is my app v1.0 and then we'll say my app v1.1 in a traditional Canary deployment what would happen is you would have both of the applications deployed but at the start it would would send 100% of the traffic to your original application so we'll say 100% there and then 0% here and then gradually the traffic will be moved over to the new version of your application so maybe you do it in increments of 10% so you go 90% there 10% there and then eventually you go 80% to 20% and you sort of get the idea basically you're drifting the traffic from the old version to the new version until eventually you have 100% of the traffic going there and you can just cut off all the traffic to version one and remove that from your environment and you just keep doing this for all your new releases now if you're using something like Argo roll outs in kubernetes it would look more like this uh this would be actually your roll out object uh if you're familiar with kubernetes a roll out is basically just a deployment and deployment is something that creates your pods which is basically just your containers so the roll out object would run a certain number of pods for your version one of the application and then a certain number of pods for version 1.1 and then as the roll out progresses it would basically add new pods running the new version version of the application and then remove old pods running the old version until eventually all the pods are gone in version one and they're all running in the new version all right so I hope this video was helpful on getting to know and understand get offs and deployment pipelines if you have any questions please leave them down below I know these deployment pipelines can be a little bit confusing at first especially if you're coming from just designing cicd pipelines which are pretty much the same no matter which organization you work for all the stages are sort of the same but with deployment pipelines it's really going to be customized to your environment and how your company functions so make sure to ask some questions below and check out the other videos Linked In the description below I'll have all my Argo related videos that goes over Argo CD as well as one for Argo rollouts thanks again for watching and I hope to see you all in the next video