DevOps Master Class - Part 4 - CI/CD

hey everyone welcome to part four of our devops master class and this is all about continuous integration and continuous delivery and then maybe leading to continuous deployment as well as you can see in the description we have the playlist with the previous parts of the master class and depending on when this is maybe the future parts and the github repo which has all the artifacts around this and the previous classes so check that out as always a lot of work goes into actually creating these so a like comment subscribe and share really is appreciated and hit that bell icon to get notified of new content so in this session i really just want to focus on that can cicd portion so i want to really talk about what is ci cd why do we do it then actually look at some key features and i'm going to use github now there are many other solutions but i'm really going to focus on github radio has led to github kind of the actions with some of the azure devops history that obviously funneled in to create that github actions so when i think about this again i'm not going to use powerpoint this week so we talked previously about the idea of these cycles the whole point of devops and this agile is we have these cycles of small incremental deliveries that build on each other of the value we have the idea that yeah hey look there's the planning and then based on that planning we have those cycles we have the development now as part of that development there is collaboration between the various teams the people on there we obviously have to do delivery and then on that delivery we then operate the solution that's gathering feedback etc so this is this continuous cycle and with each cycle of this we're adding that incremental value these small pieces that we can then digest we can gather feedback on what's working what isn't what's being used what isn't and we drive that so we keep adding that value now when i talk about one of those key aspects and doing this constant small cycles well that means we're constantly pushing out little code we're constantly putting that into environments we're constantly gathering the feedback if we're constantly delivering bits of code we have to constantly be testing to make sure we're not breaking things so that continuous integration part which is really here that continuous integration we have those different people using for example their git technologies to have that distributed copy of the code in the repository and then we have to bring that back together to make sure we're not breaking things so when i look at the concepts really around these key components obviously we covered git in detail in part two we looked at some of the tooling in part three part one recap with this in detail around boards and all the different methodologies but i want to focus on this cicd portion today so if i think about continuous integration if we take that step back if we just look at this kind of collaboration part remember as part of git we're probably going to have that trunk the trunk is that main kind of branch and in many companies this might be called main it might be called master whatever now as individuals we're creating bits of code but we're probably part of a team we want to constantly be bringing that back together now there's some methodologies where i bring that back together constantly in that main trunk what's also very common is i as my team so there's certain commits those point-in-time views of the code as my team we might create a feature branch and what i want to make sure is really daily everyone is bringing their code back together because we want to find if there are problems we want to find them early and often yes there might be some pain when we bring each other's work back in but we can fix it while it's still a small amount of pain so it doesn't grow and become a much bigger problem to do if we left it to the end of the project it's going to be a huge amount of work so we think maybe eat daily i want to bring everyone's work back together now realize if i had these longing running kind of feature branches so we call this a feature branch now there might be other features going on other changes there might be things happening in maine so then periodically what i may actually do is kind of bring those changes into my kind of feature branch maybe i do a merge maybe i do kind of a rebase that we talked about so that when i eventually bring my feature into main it's not again i don't want collisions at that point and then when my project is ready absolutely i will bring that in to my main branch and that would be kind of where we use a pull request and then we have that kind of merge in but if we consider hey i'm constantly doing these small incremental changes every night we're bringing that together i want to make sure it's not breaking i want to make sure things still work i want to avoid any long cycle of isolation so we constantly bring in these small batches so if there is a problem it's going to have a smaller blast area i'm not going to have to search for where did this thing break if i'm doing these daily continually integrating in everyone in that project's changes together it's going to be a lot easier to actually hunt and find the problem now realize bringing this coding together the quality the testing we're going to do is all about finding the problems reducing the risk of when whatever we've done actually hits the reality of production there's always still some risk it's very hard to eliminate any risk but the better the changes the better the automation the better the testing we can really hone in and get a good confidence that hey we really are doing all of the good cases we're covering all the scenarios we're reducing the risk of when this hits the reality of production something is going to go bang and even when we do hit production we're going to talk about this there are different deployment patterns different deployment strategies on how i roll it out to production to again gain confidence by maybe incrementally growing the amount of the user population that is actually impacted by that so okay i want to do kind of continuous integration so what is kind of that continuous integration what has we kind of talked about the whole point about this is when we do the commit we're bringing people's code in together well if i'm bringing that code in together how do i know i haven't broken something now when i bring in that code and i do that merge i'll see if there's conflicts excuse me git will tell me hey there's a conflict here i'll have to go and fix that but also i may have done something in the code that actually breaks something i've introduced a problem so we have to test now as i'm doing my development me as the developer i'm doing mini tests along the way i know what my code should be doing ideally i actually have test cases i create the test cases first and i develop against passing those test cases that's really kind of a fantastic scenario but i need to as we do bring this code together i need to make sure it works as a whole system we've not broken something now once again at least nightly on the commit maybe a schedule i want to run these tests to make sure nothing has broken so we can think about okay my goal here i want to answer the question does code still work that fundamentally is what i want to do so i have to think about does it still build for one thing yes i may have fixed the merge conflicts but did it actually still compile does it still create what i want it to and then i need to do some tests that i i can do within the scope of kind of my pipeline to get yeah i think this is still performing as it would be expected to so it's all about gaining that confidence that's really what i'm after i think yep we're looking good and then i can actually go and build some kind of artifact now that artifact could be an image it could be a zip file it could be a docker image to then go into containers i'm gonna have something that's the output of this continuous integration so the point is hey i want to build it i want to run some tests that i can perform maybe it's individual unit testings uh maybe.net test maybe an npm whatever that might be and then create some artifact and i'm going to actually push that to some kind of registry that i can then use further on now when i talk about all of these build these tests these create in these artifacts realize there's no magic there's no just hey i'm running in thin air fundamentally whatever i do be it continuous integration continuous delivery continuous deployment there is something running this code now the naming will vary some things will call it an agent some things will call it a runner but it's some kind of compute there's a compute resource somewhere commonly this is going to be a vm that's going to do this work so it's going to be these various kind of steps it's going to perform that does this that sets up the right dependencies i need that does the build that does these maybe minimal code type tests against what i generate that creates the artifact that uploads the artifactor somewhere and when i think about these agents these runners well maybe it's running up in the cloud somewhere so maybe that is like a github hosted maybe it's an azure devops agent microsoft hosted maybe it's running on in some kind of virtual machine the benefit there would be that sitting kind of on your network and i can maybe get to other resources on my network maybe there's things i need to compile that hey it's some special dongle i have to have plugged in to actually make that work it may vary but the point is obviously these have to run on something so when we talk about hey building and testing talk about the cloud there's no magic we always talk about and there is no magic thing here it's running on something so you want to answer these various questions we have this continuous integration does it build and does it still do kind of these basic things that can do some minimal testing around that and then i want to create these various artifacts so we think about we have this pipeline so if we come over here if we actually let's focus on the continuous integration first so if i just think about okay continuous integration and again what are we integrating we're integrating the code from the various people on that project we're bringing it together to make sure it's still good now how does this get kicked off well remember there's going to be kind of this repo so we have the repo for our code so for example our git based repo that various people are making that changes too remember we have the people doing the development work and they push up various commits so making those changes so i can think about something happens on that repository so there's some kind of event now very commonly that event is going to be for example a commit when we talk about continuous integration it could also be a pull request i.e hey look i'm at this stage i want them to do a pull request into main the first thing they're probably going to want to do is hey i want to see that this does build correctly so it might trigger a ci then we can then actually look and check those things before we then agree okay that was successful maybe there's some other tests then we'll actually go and perform that merge so something is going to trigger my pipeline so there's some event that makes this happen that could be manual as well it could be a schedule there were many different things i could do to actually kick this thing off but this is going to then lead to my pipeline so something is going to happen i'll draw this out because i don't know how much space i'm going to take up here so that event we're going to trigger the start of our pipeline now the first thing we're probably going to want to do is obviously we talked about it has to run somewhere it's not running in thin air so both things like all of the different solutions they're going to have the concept of some kind of agent that can actually run these things there'll be things pre-configured on those agents but i might need other things on the agent so i might have to actually do an install of some kind of dependency so this might be using things like npm it might be using nougat might be maven whatever that is i'm pulling things into whatever is actually doing this work so i have to set up the agent so we can do what i want it to do then sure we might actually build whatever our code is using maybe those dependencies that we actually had so i want to make sure it's still built that's obviously kind of a key point around this well now i need to make sure it still works i want to test it and i want those tests to be automated i do not want manual things in as part of this so we think about testing kind of this base does it still function now i could think about hey this could be kind of unit type testing maybe some basic integration bringing things together to make sure they kind of perform as they would expected but the key point i want this automated so there's some upfront work to make those things to create that automated testing but you really need it if i'm going to do these continual integrations i can't have some manual steps to do that test now again this could be really anything i could use things like mpm test there's things like the dot net tests there's all different ways i can have this there are special testing actions we'll can kind of talk about later and the whole point here is if i get a failure well then it's going to go and trigger something now that might go and trigger a work item it goes and creates kind of a work item with the details the nice thing here is this is running as this pipeline it has a certain id this can actually link to this actual execution so i have a link to see hey what was the failure i can mark it as kind of a bug i could assign it based on maybe who did the commit this is running against i can have all of those various things actually happening so i can automate all of that and again the better the testing i have here the stronger my confidence that this is good which is really all what we're focused about actually doing i can have multiple tests running remember i can have these running in parallel so i can get this pretty quick and then if we're happy with that if it passes the tests then the next thing we're actually going to do is probably create some kind of artifact now again that could vary this could be a package it might create a docker image obviously a benefit with docker image is it contains all of the dependencies as well but whatever we create here the ultimate goal of this this artifact this collection of files other things i want to use this same package through the entire rest of any deployment cycles i don't want to be rebuilding this for each environment because then well is my testing valid i'm going to create this artifact and what i'm then actually going to do is upload this so my ultimate end result out of this is i have some registry now if it's a package it might be kind of a package manager it could be just a regular repo if it's a container it could be docker hub or azure container registry again it could vary but what i'm basically doing is i'm uploading either this kind of package or container whatever that might be to my registry and then that will get used for everything else we do that really is kind of a key point for this now potentially depending on which branch we're actually building from so think about this for a second if i was just building from my feature branch it's regular continuous integration what i might then do is go and hey that package go and deploy it to my local dev teams environment that i can now work with but if this was maybe the result of hey it's actually the result of a merge commit on main well maybe this is actually now a release so yes i'm gonna trigger that continuous integration because logically you might say hey well we already did a build of the image of this feature branch but how do i know it should they should have done a merge or rebase i'm probably going to at this point can trigger the continuous integration to make sure i'm building off of the main branch so if this was built off of main well at that point i might actually make this a release so i might actually think about hey at this point i've done the testing i've passed i might optionally make release now when i think about making a release that has various aspects to that in my repo i might actually create a git tag and the whole point is i'll use that semantic versioning most of the time so i can think about hey a major minor maybe a patch level but i can actually go and tag at that point i am in main additionally hey that same idea of the release i might actually go and apply that to whatever that package manager is i may create that maybe a zip file with latest images in it but i have maybe a link to the source code a zip of the source code as well actually go and build that as well so github for example has the concept of release i can say programmatically hey create a new release upload this to the release and now that's this packaged version that people can release when i create one of these it's actually going to go and do the tagging for me everybody show this let's just quickly look at this if i jump over for a second just an example of what this might look like if i actually go and do this for example in github so the whole point of a release we can see here i'm looking at the code so i'm looking at my repo the whole thing is my repo but over here on the right hand side you have hey look i have a release and if i go and look at my releases well we can see i have one release and notice it has kind of this zip file and what it also did automatically it created these kind of compressed versions of the current view of all of the source files within there but i can absolutely create new releases now it also has a tag the tag it created as well based on me creating the release but i can say hey i want to create a new release i can choose a tag so i might say hey this is version 0.2.0 and i can actually tell it to hey look create that new tag so actually go and create that tag in my repo at the current point on my main branch i could give it a title description and here i can actually upload binaries so i could drag and drop for example zip files but obviously i'm not going to probably drag and drop what i would be doing is programmatically from my pipeline so the whole point is in here hey i'll make a release create the artifact make a zip file upload it with and make that package so i can actually create those things there i can do very clever things i might look for hey new releases with the star look for actually new versions of tags and trigger various parts but the key point is in my continuous integration i want to do these things i want to make sure i've got the agent ready remember this is ephemeral for every job it's going to get recreated there's no history if i'm using a cloud-based agent or runner so make sure i've got the things there required to maybe do my builds do my tests build it test it if they all pass hey go and create an artifact if it was off of main maybe i want to go and create a new release and i mark that because i may trigger off of a new release existing to go and do other stuff so that could be a key point here now the other big thing i probably want to do in this pipeline and even before the pipeline is we talk about the idea of security shifting left and what we mean by shifting left is we don't wait until we deploy it to production and then start security scanning i want to do the security as left as possible in the oval process so let's just think for a minute about this commit well the point of commit that's our code so what can i do with just the code if i'm trying to shift security as far left well i can do things like check the code are there security vulnerabilities i've introduced through poor coding github has things like code ql it takes the code it converts it to really data then you can run queries against that to look for various types of bad security practices in your code have i got secrets accidentally in my code and again things like github will actually go and search for secrets i think they've done some tests in a public repo if you have some kind of secret within 15 minutes someone has found it and is trying to use it so we can think about hey as we do the commit can the technology go and look for those secrets i think github today partners with about 35 different types of provider like azure and aws and google cloud it knows what their secrets look like if it finds it can actually go and invalidate them for us to actually give us some protection and also if we think about we all these dependencies i might open source is huge i might be referencing other things in my program so what is the health of my dependencies dependent c's so again github can build a kind of a tendency tree and then it has something called dependable so dependent pot will actually go and say hey you're using this this has a vulnerability it can even create a poor request for me to say hey i have this confidence based on feedback from other people go to this version instead and it will fix that problem so i can think about shifting this left and what's kind of nice is that for a public repository the secrets and again i'm doing github specifically here so all of these are available for free if it's public so the sequence is always running and the check code dependencies is just a very simple go and turn that on doesn't cost me anything for private the depender bot kind of here is part of the enterprise license check code and sequence is part of kind of the advanced security so for private repos i would go and pay for those features also i might have various kind of scans as part of the pipeline absolutely i might do various kind of checks in here and there are actions around doing different types of security checks but obviously i'm creating this artifact now imagine this package i'm creating here is something like a docker container once again if this was a docker i can actually have things security scanning here if you look at defender for container registries for example as part of azure as i upload new images it actually will take that bring it down and using quality scan it for vulnerabilities and obviously vulnerabilities change over time so if it's actually been actively pulled within the last 30 days it will kind of scan it again so it's making sure it's healthy it's not the vulnerabilities and then obviously vulnerabilities change so it keeps kind of doing that scanning but that's the point of our continuous integration bring the code together make sure it still works it does what we want and again we're shifting left that security so we're not just finding the problems all the way at the end that would kind of be a bad day for most of us so that's continuous integration great then i think about continuous delivery so this was about testing the code and creating something at the end of that well then we're going to lead in and we'll say right continuous delivery it looks a bit bigger okay now continuous delivery just like continuous integration is going to trigger off of something so once again i'm going to have kind of a pipeline and what's very common here is off of whatever that we created some artifact and we stored it so i'm going to think about this is going to be the trigger for my next pipeline now that could be hey here look there's a new artifact or it could actually be hey someone created a new release because again we could use that kind of release mechanism so we're going to have something to trigger this thing actually running now let's just think for a second if it was that feature branch for a local team they might have their own little local environment they might have their own little mini cd pipeline that hey we created this artifact that's just kind of local it will put it in their environment and that's kind of it but if it's on this main branch that's obviously got a much bigger far reaching implication of that there's continuous delivery so this pipeline i'm going to kind of draw this out here what we're really focused on is now we want to get better confidence about this new artifact this new version of the code whatever that might be we are not just going to go and put that straight into production we want to build confidence remember really because it's limited there's certain testing we can do here sure but it's very maybe kind of isolated because we're not pushing it to a real environment we can maybe just do some very basic kind of oh what is this doing is it doing these basic things i need to now see as this holistic part of the big solution to make sure it's performing as we expect there's different types of tests so i'm going to run this from different environments to gain confidence so i think about when i have a test environment i might have for example a staging environment or a qa and then i have kind of prod there might be others so i think continuous delivery continuous delivery is this continuous delivery is making sure i have a production ready artifact but it's not actually deploying it to production continuous deployment is taking it to production but obviously continuous deployment essentially requires continuous delivery i can't continually deploy to production unless i have production ready code continuous delivery depends on continuous integration to be creating the artifact i'm actually going to go and push to production so they build on each other and continuous deployment is obviously that automated push now i say automated push there can still be checks actually within there so they all built i have these constant things now we have the separate environments the whole point is one of us do different tests and gain that additional confidence so there are going to be gates and we're going to talk a lot more about these but i'm going to have gates between these these are not just going to go and pass i'm going to do various things to actually check the whole point of this is hey i want these different environments so i if it's wrong here and breaks i've not really affected many things here there might be other teams and other things going on but i've still not affected production this okay that's a sad day if i break things there that's kind of a bad thing so i think about deploying to different places and again remember if it was like a feature branch and i'm testing it would just be to my local app team if it's on the main branch that's when i think about pushing it through all of these different things so now my point is to take the validated code and push it through these environments now the first thing if i think about any of these stages it obviously is an environment so that environment has to be built now it may already exist this could be something in azure or aws it could be on premises i i have to make sure at all of these stages my environment is built now i'm writing build it may not be building it it may be validating it meets my expected configuration now how do i do that how do i build the environment i want to use infrastructure as code the whole point of infrastructure's code is it's declarative i'm telling it what i want the environment to look like because it says code i can use version control for this so whatever technology i use be an azure resource manager or terraform or bicep whatever that is it's code so this same definition that i'm using here will actually go and get committed into my repository so that's a useful thing so if i then change my definition of the infrastructure it will go and trigger things now i might tag it as infrastructure as code if it's infrastructure is code i don't need to do a rebuild here but i would re-kick off the continuous delivery because i'm changing the size the shape of my production environment so i'd want to kind of understand that and a really important thing about all of these all of these different environments i i might have through here all environments production consistent that is critical there is no point in having testing completely different from production it's got debuggers on it and it's got all these other things as does staging is my test still valid i might have missed a dependency but it works in test and staging because they're not like production it's production consistent doesn't have to be the same size the same scale but i want it consistent with production to make sure the tests that i'm doing are valid i could also think about things like databases hey i might have kind of a database so for my databases whatever the schema is configuration again those things would be as code they're checked in they might trigger if i change the database scheme it could go and recreate environments so it's critical that all these environment builds are built off infrastructure as code and became because it's declarative it's item potent what that means is i'm telling it what i want it to look like and i can just apply the template if the environment already matches what i want it to look like nothing happens but if it doesn't it will make it so or minimum i could detect the drift so i could go and do something now that infrastructure's code that declarative technology could also be used inside for example a vm that things like chef and puppet and powershell dsc again i want to make sure everything is configured how i want it everything is version controlled it's as code in the repo we'll actually go and drive through and make sure those things are done the right way if it's kubernetes i have my yaml file maybe it's helm charts to bring multiple yaml files together as a complete set that's declarative i want it to look this way and the key part again here is i want that production consistent and then remember we're then going to think about remember we had that artefact in the registry we are going to go and actually do our deploy the package the code whatever that is and again it's the same version i don't want variation if i rebuild it for prod what validation is that done so i think about this package is same across all environments i'm not rebuilding it once i've created this artifact be it release off of main whatever once i kick off this continual continuous delivery maybe continuous deployment i don't do anything else i have that same package or container from like docker hub whatever that might be but i've got that from the registry i have consistent dependencies dependent i forget how to spell when i write on a whiteboard i think the brain has trouble doing two things at once so these different environments i'm consistent between them there's no variation the application deployment image deployment api deployment i'm using npm nougat maven i can have my own package managers from my company to make sure the version hasn't changed if maybe there's multiple days between this these dependencies they must be same version so i might think about having my own kind of private package manager where i bring in a particular version and that's what i go and build these from so i know how there's not been some variation saying hasn't messed with it which would then invalidate my testing so it's super important to actually go and have that and then well i'm actually going to do the testing now testing here's a little bit off maybe i like smoke testing there might be validation tests and other things going on here but i obviously have to then actually go and test these things that's critical so when i think about these kind of tests all of this testing what am i testing there's multiple things i care about so obviously functionality does it do what it's supposed to do do all the components fit together and again this is all automated and i cannot make really any even gooey interactions i can automate today there's a massive things i can do about all of that there's different methods different platforms but i can really automate all of those things i think about testing my security now again we've shifted left but i still might run various checks at these different environments to make sure i'm not seeing vulnerabilities i can have scanning tools in these environments i can check various things which will bring me to compliance have i broken any compliance now depending on where i'm doing this through for example in azure i could use something like azure policy so that would actually let me go and check hey am i still within the requirements of this environment the guard rails i'm still behaving within those i might check performance now performance is a tricky one because remember these are production consistent not production equal not so much testing does it meet this number if it's not um and it's very hard to get those same kind of metrics but i have a number of what i've seen in the past for my tests i have those benchmarks so what i might look for here is i'm looking for a variance so i'm putting this new version of code maybe a new database schema i've done something and maybe here if i saw a variance of maybe greater than two percent maybe that's a fail so that's a fail so we would stop wherever we are we would go and create kind of that work item idea and we go back to the drawing board to look at what what is going on what has actually caused that to happen so we're having these things the whole point of this pipeline is to gain confidence and the only way we can get true confidence is to make sure it's consistent make sure the environments are consistent they don't have different things installed make sure it's the same package and i want to do really good tests that hit all of those things the functionality the security compliance performance now again at this point here and again when we talk about gates and i'm going to go into more detail here there might be some user there might actually be users do need to come in try it out make sure it does what they expect and then it's allowed to proceed so they might actually be user type things there but i want to try and minimize it as much as possible and then you get to production now i kind of just drew it hey check deploy smoke tests the reality is for most companies when i start to think about this production it's probably pretty unlikely i'm just going to deploy that in one go so i can really think about production rollout and what this is really going to boil down to is i have different deployment patterns um strategies different ways i actually think about pushing these out and i can think about in reality it's probably not just this one kind of blob what i'm more likely to do is have some kind of within prods this is all kind of prod but actually i probably have these kind of mini segments so it's kind of this segment one two three four whatever that might be now the actual makeup of those segments will vary i would say don't over engineer i could go way overboard make it so complex it needs to match and bring value to what i'm trying to do it's all about that confidence and gaining even more confidence because sometimes all the testing in the world really doesn't match production and how it's really used in production now i could think about in place upgrade i.e i'm just deploying this thing now there may be technologies like deployment slots that enable me to kind of warm up the code and then switch it over by ip changes whatever that may help but fundamentally what i get with in-place upgrades is it's super simple i'm basically just putting the new code in production but i may actually have some kind of downtime and it really is kind of this big bang approach everyone's going to get in this at once now if i use things like deployment slots i can roll back i could switch it back if it doesn't work so i get some benefit there but it essentially is just all switching over at the same time and that's kind of a scary concept for most things so then we can think about well there's progressive and when we say progressive what we really kind of mean are rings so i have different segments of the population that's a key point of the rings it's different people or systems are in a certain ring might be like a pilot ring a pilot two ring early adopters general population one general population two general population three so the point is it goes through the different rings that are these specific parts of the population of this software and so i gained more confidence the first slice would be very small second slice a different part of the population maybe use different parts of the functionality but i'm gaining confidence as those specific parts of the population get the code so the benefit here is i have great control fantastic control of this and sometimes it might be feature flags that i'm turning on or off for different parts of the population to see the new functionality again feature flags are something i've not really talked about but they can be really super useful because if you think about maybe i do use trunk based development so i'm constantly actually merging committing to main but my code is not ready so i can use feature flags to basically disable the code but still bringing it together until it's actually ready so when i think about some of these deployment strategies well maybe i enable it for these different segments through turning on those feature flags that can be something i can do so this gives me great control but it can be quite complex and it may take time that may not be a bad thing but obviously as i go through different segments it takes more time to actually deploy those things out the next thing we can actually do is canary now canary actually looks a lot like progressive but this is really just a percentage of the population so hey i get 5 then 15 then 50 then 100 so there's no targeting to it it's just hey i maybe have waiting so like i could have a load balancer for example and that load balance uh initially maybe directs five percent to some area and then 25 to the new code then 50 so i could actually trigger it using no so i'm just exposing it to a gradually bigger portion so now i'm not worrying about specific people it's just hey a certain weighting goes somewhere so it's a pretty good control it's simpler than this but it's not simple and i said that hey it still takes time and there is still an element of the complexity there's still things i have to do there and then we have things like blue green it doesn't have to be blue and green really is the idea i have two environments and when i have the new version i deploy it to the other environment that's not coming in production and again here i might combine this with these things to actually start pulling portions of the population over and then eventually i i kind of flip it and now blue which was prod is now empty and ready for the next staging so this is simpler in a lot of ways the downside is resource use because if you think about it if i have to have a whole separate environment depending on how i'm actually switching these i might have a whole environment not doing very much now in the cloud where it's consumption based maybe that is not a big deal because i can essentially create the alpha environment only when i need it it's not just sitting there idle all the time so that consumption nature of the cloud may absolutely offset that to a certain degree but i'm gonna point is i can not just think about hey prod i may actually break this down into different methodologies to get that confidence i'm gonna keep using the word confidence it's all about getting better confidence that this code i'm putting in is not going to destroy my world which is production so i want to make sure hey i'm feeling pretty good on this now obviously if at any point in all of this if i was hitting points here of failures it stops it rolls back and i restart whatever failed and go back it could be it wasn't code remember i might trigger this pipeline because i had a new infrastructures code on a database schema it would still be a commit triggered this if it doesn't work i roll it back in production if one of these slices maybe starts having a whole bunch of work items because again i can have gates in all of these as well so these can all have gates maybe it's number of work items raised against that particular slice if i've got more than 10 tickets raised let's stop let's work out what's happening and then i'll let this actually go and carry on so any problems hey let's stop let's make sure we fix it before we just ignore it we do these for a reason to gain confidence before we move this on but again where is our pain if something's not hurting us maybe we don't need to actually fix this so let's actually now do this thing let's actually talk about doing this with various tools available i'm going to focus on github but remember github kind of grew from azure devops so i'm going to start with looking at azure devops and then grow this into thinking about what we actually have today with github actions but there are others jenkins for example is super super popular git lab has solutions there are tons of solutions that have the idea of enabling all of this to be a reality i'm just more familiar with kind of the github and the azure devops so that's what i'm going to show i'm not saying that's what you should use it's just that's what i am familiar with so that's what i'm going to demonstrate you use whatever part works best for you and kind of your company and what you're used to realize all of this is really based around you saw it in the pictures there's some event there's some event some event triggers continuous integration or commit pull request some event triggers the pipeline new artifact new release so there's some event that makes stuff happen that's really what this all boils down to so have event do stuff and then everything else is about well how do we do stuff and that's what we're going to focus on first so how does azure devops do stuff and i can think about with azure devops and again you you might be saying oh i don't use azure devops totally get it but it's actually quite useful to understand where it's come from to understand where github actions is today so you have pipelines and that was kind of a major segment of technology and then what you had under pipelines was build pipelines and then you had release pipelines and these were guis so build was obviously continuous integration this was obviously continuous delivery continuous deployment and these are gui based or at least they they were kind of gui based so let's just quickly look at this just a couple of minutes to understand where we're coming from so if i jump back over for a second so let's go back over to here we look at my devops i'm actually going to switch aux for a second to my savor tech devops because i've got an old one laying around so if i go to my pipelines over here now it's called pipelines here it's pipelines pipelines it's because it used to be called builds so it was pipelines builds but they've renamed it to pipelines and we'll see why and then i also have releases iecd so if we look at yi old days and look at my pipelines i'll select this one and we'll edit it it's a gui now i can see it's basically i've got some job i've got an agent job one that runs on an agent so it's running on something again it can't run on thin air and there was just steps and i could add new steps to this there was this set of steps i could take these are actually tasks within step that i could drag over into the things i need to do so i can see hey install bower run bower use net core restore do some tests publish the test results publish publish the artifact so this was the ci and you can see i can i can see the complete ci pattern here hey install the stuff i need to actually do the build do the build do the tests and then publish it create the artifact so that was the idea graphically i could kind of drag and drop these various things then i had a release now remember what's the point of a release one of the releases to get it into environments so i triggered off of an artifact and i could have this automatically this continuous deployment hey an artifacts created run this in this case this was kind of this progressive ring based deployment and what i could actually do is i could have pre-deployment conditions and post deployment conditions so i could say hey for ring one i could turn on approvals and i could also turn on gates so i could think about hey a deployment gate could be check for policy compliance call a function called a rest api etc etc so it was this gui based thing to actually create those so that was kind of the key point so two separate things gooeys the challenge with that is it wasn't code so it wasn't really living in my repo as a way i could easily version control and leverage that so what they've now actually moved to is yaml for pipelines that's why it's been renamed so we don't really call it build anymore i can still do the gui this is still there i can still kind of do the classic kind of the name they always give things they say are not very good everything's classic this is really not very good anymore so for music but now it sees yaml-based pipelines and it supports multi-stage so we have multi-stage now and if you think about multi-stage what does that mean we use stages for cd so i can use this for ci and cd now so it's really kind of the huge shift it's code it's in our repo i can version it it's a bit of a higher learning curve because it's now yaml but it's code it's version controller i can actually use that for various things now there's a whole marketplace around these there's a whole set of starter templates if i go and look at the azure devops marketplace for a second these are a whole bunch of extensions but i can see those things around artifacts boards but pipelines is all these things there's massive numbers of these that can plug into the pipelines these are all like bits of yaml i can leverage and put into my yaml based pipeline and this is all going to start to look more familiar especially when we start looking actually at github actions which again has really grown from here so the point is now if i go back to my pipelines and we'll just go new pipeline by default it's going to use yaml now notice it's asking me where's my code doesn't have to be in azure repos it could be github gap enterprise some other git bitbucket there's still the classic editor down here so if i want to use without yam or i want to use the gui i can use classic editor and it's going to have its own little interface again it can still trigger off different sources and then there's a whole bunch of template libraries i can use but if we just say hey where's my code repos use this repo it's going to give me a whole bunch of starter pipelines it's actually going to go and populate all of those core things i need based on the type of project so it's going to give me this great starting point or i can just have a really really basic one so what i'm i'm going to kind of do is talk through the basic structure so i'm going to change actually my organization again we'll go to our video planning go to our pipelines so i've got this super super basic pipeline and look at this it's my video planning this is my say hello and what we can kind of see here there's a certain structure to this so firstly obviously there's a name so when i create a new one i can specify the name and i can put in a folder so it's under the repo but i i created a folder called pipelines and i put it there so it has a name well it has a trigger so my trigger is off of the main branch so i can think about okay my yaml pipeline i have a name my something somewhere dot yaml i'm gonna have a trigger something that tells this to run now again i could manually run this there are many different types of triggers i can do i can specify a pool so the pool are the agents i'm going to use and i'll talk more about this i can optionally have stages but i don't have to but again if it was continuous deployment continuous delivery i'm going to have stages to use those different things with different controls around that my stages are then going to be made up of jobs and my jobs well they're essentially going to could have their own pool so obviously i had a pool here but these could optionally use a different pool depending on maybe i'm building to something else and then that's made up of steps and those steps call tasks so that's the fundamental structure of what we're doing so again we jump back over to this for a second we can see that here so if we go and look i can see okay well i'm using a certain pool and i'm using a linux pool i can see i have a stage a which has a job it has a name first job is a1 it's made up some steps and this is just echo hello world and i have a display name now also you can see i have a depends on so here you can see halo i've got depends on nothing so normally there's kind of this implicit depends on the previous stage the stages will run in order but here i'm saying hey it doesn't depend on anything so now this stage b will run in parallel with stage a and then it's got its own jobs stage c well here i'm actually saying hey it depends on a and b so a and b which run in parallel have to finish first and then it will run this job and we can see this time is actually using this thing called an environment okay we'll we'll come to that and it has its own steps and then stage d hey it then just runs in another environment and it's doing some stuff so basically just having these various things within here so we've got those things i can actually execute so if i look at that structure for a second there were a few extra things i kind of added into this so optionally we could have kind of this depends on so that was all about these things have to finish in a certain way we also saw well i could actually have this pool in here as well it could use a different paw in there and then we also saw this idea of kind of an environment that i could leverage so these different aspects so stages will run sequentially unless i do something different environments so that was kind of interesting what was the environment all about so if i'm thinking multi-stage remember stages this is what essentially enables this part here this enables continuous delivery continuous deployment i have to be able to have those different stages to be out of function well they probably want to run to different environments qa test uat production so we have this concept of the environment and what an environment actually does for us is a number of different things so environments have the idea of different security who can actually interact with that environment i can think about it can actually have resources it can have like vms and kubernetes clusters but even if it doesn't it's still actually a useful construct i can have approvals i can have various types of gate i.e checks i can also with this have is i can track what's happened to that environment and to use this i need deployment jobs there's different types of job to use an environment i need a deployment job now there's a big shift here if you remember the original release those pre and post approvals were part of the pipeline itself it actually doesn't make that much sense it's better to have the environment having the conditions i'm not relying on the person creating the pipeline to do the right checks so we move the conditions to the environment and this is important because github is going to do the same thing so we have these environments that i can use and then any of these things i set that's going to apply to whatever i can lock down what um for example what branch can deploy to it so if we go back for a second i can actually go over here you can see environments now within that environment i create two qa and test if i look at qa and i go to these called dots at the top over here i can edit but also there's security and there's approvals so on the approvals if i hit add again i'm at the top here this little button or i can add people to approve i can limit it to certain branches i can limit it to hours evaluate the artifact to make sure i'm adhering to certain policies i can put certain locks invoke a function a rest api query azure monitor use it based on a required template has to be in the pipeline huge numbers of checks i can use so then when the pipeline actually wants to use the environment i'm not having to specify any checks here but it will essentially make it so to use test any checks i have on test will have to get passed and also the nice thing is if we just manually run this so if we just run this it's going to kick off the run so notice even though it's yaml notice it still gives me a graphical view of the execution i remember i said these would run in parallel because it depends on was nothing so it's waiting for an agent to be available and then these are going to kind of start in parallel i can expand them out and see the individual jobs then c depended on a and b and then implicitly d is going to depend on c so i can see b has finished already i can actually see it oh it wrote out a script oh there is hell another hello from here i could see hey a is kind of checked out so that had options check out the code it said hello now what will happen is c will start and again each of these stages can run in its own environment so this is running a different environment so i'm going to get kind of a different agent to go and run this who has to get an agent for this they wait for both of those to complete but i get huge great information on all of these different things and in the environments i can see the last change that impacted them so i can see oh okay thanks actually running on qa right now so i can see the last activity so even if i don't have any resources in it from an azure devops perspective it's still really useful for me to see what has happened to these environments i can see the actual jobs that have recently run against them so i can see that is now actually finished so there we go so it ran all of those different things so that's why environments are really super useful i don't have to worry about the checks in the job itself it's actually just gonna kind of use those okay so i kind of mentioned the agents and it's running on the agents so all of these times where i've got the word pool where it's running on an agent so i can actually think about hey all of these things in azure devops language are agents these can be microsoft hosted and if they're microsoft hosted they can be windows linux or mac os again i can still install things but they are ephemeral they're going to get created and they get deleted now things in the same stage can use the files from each other but outside of that i it's deleted it's recreated at the same of every single go i can also have self-hosted so self-hosted is i install the software but now it's running in maybe my environment so the benefit here could be my internal resources maybe i have sank it needs to be able to access maybe it's deploying to sync on-prem that a cloud-hosted agent wouldn't be able to get to it can also be long-lived it doesn't have to be but it it can actually live a long time and have cons maybe caching between it persistent files maybe it's a bit quicker as well there are certain timeouts how long these things can run for but again i can actually set these at kind of a job level if i want to and use different sets of agents so that's where we kind of come from with azure devops and then we've kind of got to that yaml point if you want to play with azure devops it's actually a nice little devops generator you can go to so the devops generate a site i'll just kind of show it quick what it lets you do is basically specify a starter and it will create your entire repository your entire project for you of a whole bunch of pre-can content and it lets you play around with it so here i could i would just kind of sign in and then actually let me go and pick the scenario so the link to that is below in the actual description for the video so github actions let's kind of dive into that now this could be a lot of familiar with the azure devops pipelines the new yaml based one because again the way this kind of came to life was well they kind of took a fork of that code and then i mean they changed a lot of things but there was a lot of familiarity with it so if you understand that well i'm going to talk about github will make a lot of sense so if i think github so that was azure devops it's going to keep the flow going so github i really should use consistent colors so we'll say github and what we're really talking about here is github actions github actions is all built around the idea that there's some event which we're familiar with and that event is going to trigger a workflow so that's going to trigger a workflow now that workflow is going to have some kind of name.yaml and it's going to get stored in the dot github slash workflows yep so it has to live there of your repository so it lives in the repository in github the repository is is kind of everything most things live in the repository so i can call it anything i want it's going to live in that dot github slash workflows folder of my repository so it's going to trigger on something maybe a commit a pull request we're going to talk more about that it's made up of jobs and those jobs run on something so there's kind of a runs on some runner it's called i can optionally use environments which is going to seem very very familiar as i talked about when we when we actually go and talk about kind of azure devops i can think about it might need certain things so needs means some other job ran first so it's how i do kind of dependencies so i can say it needs something else to have run first then i can have it jobs made up of steps and those steps are really made up of actions and those actions typically use something they use a certain github action so this is kind of the structure we have now a key point of this is this event and this is com very very different when i compare this to azure devops this can essentially these events can be anything it is not just cicd it absolutely is cicd as well i can absolutely do things based on a commit on a pull request on a new release or artifact absolutely i can do those things sure i can do it on manual i can manually trigger this thing i could do it on a schedule but i could do it on a new comment a new collaboration i could do it on someone who has joined it i could do it on a new discussion point i can essentially create these workflows to automate anything if i go and look at the documentation i can look at all the events that can trigger workflows and it's huge there are so many different types of things that can actually trigger workflows in here it's not some small little list it's this massive different set of things that i can actually trigger for this so if you kind of think about anything happening in github i might want to have some automated process for i probably can i can automate really anything i want i can't have a web hook to trigger these things so if you think about that structure for a second let's jump over to here so again i just go in my my repo i can go over here to actions and again with actions if i just say i want to create a new workflow it will actually go and look at my repository it will look at the type of code in my repo and say hey why don't you start with this so if i had like for example node.js it would give me things about building a node.js application here it's got options hey i could deploy a node.js if i looked at this quickly what we'll see is my on i.e my trigger is on a release of anything created so there's all these various things available to me now i'm going to start with a basic hello and what we can see here really is very very simple i gave it a name i'm triggering on workflow dispatch i i'm manually running it i have a section of jobs this job is just called build i'm running on ubuntu latest and then i have a set of steps which are really not very interesting now my first step uses actions slash checkout version two so a key point there is okay there might be different versions there's references and i'll talk more about the actions in a second then i've got some that are just using a run i'm just running a script a echo hello world i could also have a multi-line script down here but it's really just made up so this looks super super familiar of what we just did and i could absolutely run that if i select that for a second so i can actually go in view runs rather than manually running it which i actually could um just go to a few runs these are all the things that have kind of triggered notice i could do a run workflow here just run that off of i could select a branch but here are all the runs of this one i can see there's the build step i can see all of those individual steps so there's checking out the code of the repo if i ever want to use the code i have to actually do an action to get the code first into my member this is an agent this is a runner that's ephemeral it's created so if i want to be able to use the code in the repo i have to do a checkout and get the code into that runner and then it's running the various things i can see all the output when it's actually running kind of live jump back for a second it's going to finish by now anyway so there it is but when it's actually running let's actually rerun the job once it's actually running in here you get kind of this live log to see what is actually going on so hey it's setting up the job so i get this live log of everything that's happening actually during that execution says huge date amount detail available to actually go back and troubleshoot and everything else so that's kind of a really simple kind of action there now i mentioned before it has to run on something so when we think about okay this runs on that runs on is essentially the runners for our environment so just like azure devops there's a whole different set of those so i can think okay there's github hosted and once again it's windows linux mac os and once again i can do self-hosted the os's are the same that are supported on that self-hosted model and again i had that same idea hey i can access internal stuff once again i have the idea that they can be um sorry they can be long-lived if i want them don't have to be but they can be long-lived if i want them to be and just in case you're wondering about the actual structure of how does that really work again these are called runners so these are the runners they're not called agents if i'm running that on-premises for example so maybe it's a vm and i install the github runner in there so i think about github is up here i'm not opening up any firewall ports and again ado works exactly the same way if i have my kind of firewall in my environment is actually it makes an outbound connection to github so the connection is that way 443 i'm not opening anything up inbound from the internet that's the connectivity it's actually going to use um for that and again they're ephemeral they're wiped every time if we look at what ones are available to us so this talks about exactly the cloud hosted running so that's the github hosted runners here and we can see the labels we can use so i've got things like hey windows server 2022 windows latest ubuntu latest mac os mac os latest so they're the versions of runners i can actually leverage and exactly like azure devops there's common software installed on them but realize if i need extra software i'd have to install it as part of the pipeline there's other things i need for continuous integration to build i would have to install those now if i actually want to have self-hosted runners it's part of the settings of my repository or i kind of have kind of old ones as well but i would kind of go down here to actions and then we have runners under the actions category and that's where i could go and actually go and add a runner and then i can have secure about who can use them and all those various good fun things there are timing limits so there's certain amount of times execution time so it's up to six hours of execution time um each workflow run is 72 hours there's certain usage policies for these can you get certain amount of free minutes for example for and the public represent even private you get a certain amount of free as well but you can go and look through this again the links in the description below to find out all about the billing aspects and using these various things so we we have all of that available there now i talked about these actions an action is fundamentally some reusable piece of code so where i'm saying these are actions and i'm using these things well what is it you notice there was kind of a weird format it was action slash the name hat whatever so my actions themselves are going to be the owner like the the owner of the repo so john the brick for example or savor tech slash the repo name and then a reference for example it could be the version and these can be javascript so i can write them in javascript or they can actually be a container so there's different types of actions i can use there now i can build my own a huge amount of these available are created by the community and i can leverage those i can publish them to a marketplace now there's a huge amount of these provided by github so there's kind of github provided remember these are units of functionality there are ones available in repositories i cannot use one in someone else's private repo now i can use a private one in the repo of the workflow ie if i have my own actually my private repo in the same republic as the workflow i can use that otherwise i can't also if it's container based i could use it from docker hub again public access you have to basically think the agent is running in the context of the repo it has to be able to get to it and i can't get to anything other than public and essentially i can publish them to the marketplace so we can actually go and kind of look that's optional i don't have to but we can go and look at the marketplace if we go and look there's huge numbers there are currently action so look at actions uh 9737 now one of the things i can do is i can turn on verified creator this is not github verifying the uh actual action itself they are verifying the creator of the act of the the person who created it so for example azure for example so i could go and search for azure so i can see there are 38 verified creators from azure itself so it's even about azure sql deploy azure pipelines and this is how i can go and create things and add them into mine maybe i'm worried about release management so i could search for a release and let me turn off that for a second so i see all these different things that i could do about creating releases people have created actions about this and package management i can go and find something and if i just looked at i don't know and notice there's categories of continuous integration there's one's about deployment there's one's about testing so i can go and look at any of these things i'll just click any of them it shows me a sample of the yaml to use this notice the format so okay it's using the actions kind of owner this one github provided the checkout repo and i'm using the v1 and then if we think about well now this is the owner he created this and then the repo and then it's just the master so that's the reference to it the master branch is kind of that reference there so that's how i can go and use them so i go and search for what i'm trying to do and it's going to give me the yaml that i can then leverage in mine so this is the process i would go and find the various actions now if i was actually going through and let's say let's go to my environment workflow i'm gonna edit so i can actually edit it in here this is just code again remember so i could be edit this in vs code and then synchronize it up notice i can search the marketplace from here i could just do azure aks oh deploy it to kubernetes cluster oh great i could click that and then within this editing it's showing me the code that would actually need to do guy uses okay so the owner is azure okay repo kubernetes deploy and there's the reference v 1.3 so it's very easy to take that and then just cut and paste and put that it's even got an option to copy it to my clipboard you can see there super easy and then paste that and start using that in my code so testing anything i'm using is nothing really more complicated than just actions i'm actually gonna go and use but it's super nicely integrated now one other thing before i move on to the next demo if we think cd this is where github actions was weak it was great for continuous integration it wasn't very good for continuous delivery continuous points it didn't have the concept of stages well it does now we have these concepts of kind of these these jobs that can have needs so we can have relationships to other jobs that have run but now we have this concept of environments and just like the azure devops we can have things now it's not at the same level so it's depending on my functionality requirements it may or may not meet my needs once again what i can have here are reviewers now today it's only one of them has to approve it i can't select multiple people i can have weight timers i can have branch protection so only except code from this branch for example if it was prod maybe i only accept it from main i can have environment level secrets so there's in repo level secrets and environment level secrets and then i can use a certain environment now there are ways to expand that um there's also the ability for example there's an api as an approval api that i could hook into so third parties could expand this i think github are working on adding more things to this let's actually go and take a look at environments so before i go and look at this code if i look at my settings for my repo i have environments now i created three test prod and qa and on prod you can see i've got a couple of reviewers so someone has to review it i don't have a wait timer but i only accept code from the main branch and i've also defined an environmental secret called greeting now that same environment variable i also configured in test see greeting here as well and i defined it as you're going to guess in qa and i have a wait time of one minute for qa and also at the repo itself i have greeting so greeting in four different places so i want to kind of show a couple of different things at once so i have those environments i have an environment workflow that if we look at this what i'm doing is nothing fancy but essentially i have a push or pull request from main will trigger this and i can manually run it as well and then what i have a different jobs so i have job one runs on ubuntu latest in environment test and all i'm doing is writing out a greeting but i'm taking out of secrets greeting now because it's environment test it should be getting the greeting of test now one of the funny things what github does is if i try and output sequence.greeting in the log it will just put three asterisks it will hide it for my own protection and what i did is i actually said it to be test test test in tests qa qa q8 in qa by prod in prod and then reaper reaper repo in the repo so to actually show it to you i'm just doing a quick check on does it equal test test test if it does write out test the only way i can show you the sequels are different based on which environment i'm in but in all of them i'm just accessing sequence.greeting in qa secrets.greeting in no particular environment secrets.greeting and then finally in environment prod sql stock reading but notice i'm checking for prod prod in that one reaper reaper reaper and that one qaqa so they should have different values depending on which environment they're running on so it's kind of the key point of what we actually have here so from this point if i kind of look at my my workflow here this right here um i can actually go and view my runs and i'll just let's actually notice it's got this update it's waiting i'm just gonna um it would have timed out so i'm just going to run the workflow it says run it now on main and what we'll actually get is that same kind of graphical view so here's my workflow and notice hey look it's job one is going to run first then it will run job two then it run job three and job four job four and job three are going to run kind of at the same time now the reason they can run at the same time is if we actually just jump back out for a second if i look at job 4 notice job 4 needs job two job three needs job two so as soon as job two finishes those other ones can actually run job two needs job one so i can define the relationships actually between them so that's how those are running so we're going to view the runs so we can see qa is waiting whenever i had a one minute timer so job one is executed job two is waiting for that one minute timer that i actually defined in there so now the wait is finished so that job will now kick off so job two will execute if we look at job one now is the output it test so the secret equaled test test test it used the environments variable not the general repo one go back to the summary so now job two is finished which is running on qa and output qa job three is also finished no specific environment so it outputted repo job four that's way weird oh it's waiting for review because i had reviewers for the environment and it's even telling me it would have sent me an email requesting your review so i can review deployments i can say either of these two people me or clark i say yep manual tests done looks good approve and deploy so now i approved it that job will actually go ahead and start so that's prod if we look at prod it outputted prod because that environment secret was used not the repo general one so the environments are giving us actually some some nice things there and actually just can i show this let's have a quick look so if i go back if i view the workflow runs to try and show you me trying to test this initially so let's have a look yeah so look i originally just tried to echo out the secret where it protects you from your own stupidity it's like you probably really don't mean to output that secret um to your log file so anytime it sees a secret it will just put three asterisks there for you so it protects you from yourself so that's by design it's like you're being an idiot you probably don't want it in your log file so it will give you some protection from yourself there another nice thing you can do is matrix so imagine i wanted to build across three different versions of node or across three different operating systems instead of having to do unique jobs for each of them what i've done here is you can see i'm creating a strategy of matrix and my matrix is called os and i've put three different values so what i'm now saying is for this job i want it to run on the matrix so even though i only have one job defined here and i just have these very simple steps of say hello and i'm outputting the particular os name of this step it will actually create three jobs so if i go to this so i can see i've run it multiple times if i just look at this and oh no we're messing this up sorry let's do this one more time it goes to my os i'm just going to run it so i can see the execution there but we'll run it just for fun and refresh so there we go what we'll see is zero of three jobs so because of that matrix and though it says message ubuntu latest windows latest mac os latest so it knows hey because of the matrix i'm actually going to do three things so ubuntu latest there windows latest here and mac os latest so it creates three different runners one for each of the operating systems and run it on all of them now you kind of see how quickly um that actually runs and azure devops can do the same matrix thing as well the reason it runs so quickly is although it's an ephemeral vm it it has one sitting there waiting that are blank ready for you so you're not actually waiting for it to go and actually create the vm in whatever that cloud is it has some waiting which is why it's a lot quicker than it would normally take to actually create a new virtual machine so that's really the power of the environments and having those on the environment the reviewers the wait timers the branch protection those environmental secrets are super useful because i might have different um keys different credentials to talk to qa or staging or prod in azure or aws or whatever that might be so that's a really powerful capability hopefully you see the kind of commonality between this evolution of the functionality we have now as i kind of talked about from a billing perspective you get a certain number of minutes if it's a public repo i think it's just free now it's free and unlimited but they are looking if you try and create a a job that's doing crypto mining they're going to see that and kill it off so don't do that you ruin it for everyone um i talked about kind of the packages you create so when we talk about that more in a future class but these kind of registries so azure devops obviously has the concept of artifacts for github you have the concept of packages so if we jumped over for a second in my code we actually have over here on the right hand side packages now today in github packages are really repo specific it's not super easy to kind of share between repos have kind of this enterprise level there are all level packages there is the ability for containers now to have better control on who can see it who can use it and i think that container model they have at the org will kind of flow through to other types of package over time but you can see hey if i do have those different dependencies rather than using some public npm or nougat or maven i would pull it into my package management so i have a specific version i only want those used maybe i've done security checks against them and that's what i could then actually leverage so it helps me kind of have that great control obviously i can push my own things there as well that i then go and use so that was kind of the high level thing and that's the cicd i mean lots of moving parts but it really fundamentally boils down to the idea that hey i have code going into my repo as my team we're constantly bringing our code together i want to make sure it's still good and so continuous integration does the build does some basic testing it creates some artifact and then to get that confidence it's ready for delivery hey we kick off continuous delivery we make sure we consistently build the environment in a production consistent state remember that's infrastructure's code it might be i've changed the environment in which case i might kick off a cd based on a certain type of commit on environment i don't have to rebuild anything because i'm not changing source code but i would rebuild the environment and i want to stage out and test an environmental size change or type of resource i want to test that as well then we have consistent deployment of the same package to all environments we have great testing across all the different areas and then from a technology perspective azure devops has really evolved from this gui with separate build release to just yaml pipelines with multiple stages using environments to github actions multiple jobs that can have dependencies between other jobs so i have that staging environments with different types of reviewers and wait timers there's an api approval that i can use to expand that but i'm using these very well-defined actions at those reusable units of code to use my ci and my cd so that's uh that that's it for this particular part the class as always i hope this was useful as always there's a huge amount of work goes into preparing for these so we do appreciate kind of a like and subscribe but uh yeah all the the samples of this are in the repo in the description and until next time take care you

Channel: John Savill's Technical Training

Views: 41,791

Keywords: microsoft azure, microsoft, cloud, devops, ci/cd, continuous integration, continuous delivery, continuous deployment, github actions, azure devops pipelines, release management

Id: nLRHV2sRTe8

Length: 104min 49sec (6289 seconds)

Published: Tue Aug 31 2021