DevOps Master Class - Part 1 - Foundation

hey everyone so welcome to part one of my devops masterclass i put out a poll on my channel a little while ago saying hey what should i work on next is kind of a big project and a devops master class was kind of the most popular by far topic so that's what we're doing um this does kind of go i have other master classes on my channel like the powershell masterclass and the azure masterclass this will follow the same format i want it to be kind of relaxed there's a playlist where i'll have all the videos i'll try and add one a week sometimes there might be a bigger gap if i have another topic i will kind of want to put in the middle there's a github repo for the slides and the whiteboard the code that goes with it but i'm really just trying to transfer the knowledge over there's a lot of work that goes into these so please if it is useful give it a like subscribe comment and share and hit the bell icon so you'll be notified when i add new kind of lessons to this when i maybe add supplementary or i change something so my goal for this now the structure i have some powerpoint but it will vary week by week like i'll do a lot of whiteboarding mainly but when i'm talking about maybe a certain technology like next week i'm going to cover really a master git that's really going to be all demo so it won't be much whiteboarding it i think be no powerpoint it will just be demoing for the entire time so it's going to vary but what i want to really focus on is these key topics for devops now obviously this is a recording but i do kind of check the comments of my youtube channel i do not look at linkedin i do not look at twitter none of those things will work if you tag me comment in the applicable video so we're going to really focus on sort of devops foundation so that's this lesson it's going to go kind of quickly over a lot of different areas we're going to spend a bit more time on kind of some of the frameworks around the project management side because there's not other lessons on those but really just introduce the all up concepts really the goal behind devops and then preliminary plans next week will be mastering git so huge amounts of detail on becoming a master of git this applies to everyone and that's devops in general this is not just developers it's not just operations it's not just architects everyone should kind of understand devops it is this universal thing right now and then i actually want to look at some of the tooling azure devops github how they differ where they're going what parts we might want to use think about continuous integration continuous delivery continuous deployment how pipelines play into that why it's important so i want to dive into those concepts thinking about handling secrets is actually a really important thing we also don't have secrets in your code don't put them anywhere so where do we put them how do we handle secrets we're going to dive into that thinking about infrastructure as code another really critical element to everything we're going to do key to the pipelines this declarative this is what i want it to be let's make sure it really is looking at containers kubernetes images image builder repositories registries all of those types of things monitoring monitoring is huge to devops not just that traditional monitoring we think of for how busy is our server monitoring what are the interactions with our service monitoring what's the user behavior what path do they take what is their experience and then git ops and then security all of these important topics and this is just my preliminary thinking as i start to plan this out i may absolutely add other things in here i might move things around as i'm going to talk about the playlist is really the source of truth so technology changes i will update modules over time i might completely replace them i might add ones in i might add supplementary videos so i will reference a link to deeper dives in certain areas like i might have a whole video just on keyboard while we'll go and reference that so make sure to subscribe hit the notification you'll see those things use the playlist now that's in the description as is the github repo right now it's going to be empty but the playlist will have all of the key videos for the devops masterclass and the github will have the whiteboard the powerpoint the code links to the videos links to the additional learning so they're going to be your sources of truth now the question always comes up whenever i do the kind of any video or class is this specific to some kind of certification the answer is no i'm not geared towards any particular cert my focus is just to transfer the knowledge make you digest the knowledge however it's definitely going to help with the azure devops engineer i obviously do come from an azure background those that know my content so i'm going to focus more on the microsoft side of the house so when i demo deployments it will be to azure now the same concepts would apply to google cloud or aws or on-premises i'm going to show github but the same thing would work if i'm using a different git repository but certainly it will help with that devops engineer and so what i'll end each module with is kind of questions go ask in the comments below but with that i want to get to the first lesson foundation and the whole goal is really well what is devops what are some of the key concepts we think about and how at the end of this session you can start to get ready thinking about things you could do now that will set you in good stead for the future lessons key part here devops is not a product now it's confusing because yes there is a product you can buy called azure devops but it's really much more than that devops is a tool yes it will help i can use as much or as little as it as i want to i don't have to use any of it devops is more than just a single product and i think it's summed up very well by donovan brown he's kind of one of the lead evangelists around devops at microsoft and he kind of come up with this idea of what it is so it's the union of people process and products to enable continuous delivery of value to our end users now the keyword value everything we're going to do around the devops is about delivering value for the business to our customers and saying that really sets the whole idea of devops apart from maybe other methodologies we've used in the past is this idea of continuous delivery it's not these huge six months or one year product projects it's these continual smaller increments of value that build on the previous increment that's really what's going to kind of set this apart okay so we know it's not a product why are we worrying why are we thinking about what is devops what does it do so before devops we had the business now our company is really focused around it's performing a certain business and about what that business is we want to deliver value to our customers it doesn't matter what that type of business is fundamentally we want to get value to our customers that's how a company differentiates itself from its competitors what is the value we can bring now those customers could actually be employees it might be an internal service it could be external people could be partners but it's all about the value so if i think about this for a second there's some important things that really kind of gel together now i can think about two other teams we have kind of a business owner product owner we have developers developers want to create new stuff that's really how they're gold how they're paid how much new stuff can you get out there and then we have iot operations they are given the code by the developer to put into production and their goal is to keep things running to keep things stable to ensure that continue availability of the value so i think about that for one second let's just compare those things so i can think about okay what i have at the top is the idea of well yeah it's it's the business so i can go okay so i have the business whose key focus their guiding star is to deliver value perfect then we have the idea that okay well now we have over here the developers and their shining star their goal is to really introduce change that's probably how they're gold how they're rewarded okay over here we have kind of operations and their kind of guiding star is stability i.e no change and you can start to see a problem kind of straight away you have these conflicting goals that generally just going to put them in conflict straight away developers want to put in change hey we're gold on how many new things we can do operations your gold on keeping things running making sure it's stable they don't like each other with operation doesn't like developers you keep trying to change stuff developers are impeding our ability to change and do fantastic new things now additionally when i think about this the motivations were very different because the developers are rewarded on change operations are motivated on keeping the lights on also the developers for the most part we can think about well they just create the code and pass it over if it gets into production and doesn't run very well they they don't really have that bigger deal yes they have to fix it at some point but they're not really on the hook additionally we can think about those projects we have over here the projects actually tend to be very long so if i think about the business kind of have some set of kind of requirements that maybe change over time but they have the requirements are kind of gathered at the start and then we have this huge long-running project this is a long time and at the end of that long time they actually get a delivery and i don't really interact at any point in between so hey we get the requirements from the business okay and then there's this huge long project it could take six months if the customer's requirements changed at some point there's no provision for that i can't go back and get that and if at the end what's delivered is wrong tough there's really not a lot we can do the other thing about traditionally our projects we think about this very monolithic application it's very tightly coupled together if i try and change one piece i have to make sure i go and i test all the other pieces as well i can't really just change easily some item because it's very tight coupling calling i need to know what the schema is that it's using internally because i'm accessing that as well so if you change that i need to know and i need to change it really prohibits the ability to change so it slows everything down if i change one thing it'd be this huge cascading set of changes i'd have to make to a whole bunch of other things so it really wasn't a great place to be okay so the goal what we're trying to get to as the name devops implies it's really about trying to bring the people together we want to try and get the operations get the developers to better collaborate together now obviously you're still going to have individual teams there's still going to be for example a network specialist team a security team but for the general kind of workings what we want to try and do is really unite we want to kind of bring things together so the developers are invested in the quality of the code they're on the hook for that as well when we think about this new cadence of hey we're going to deliver things quicker it doesn't work if we've got these very isolated teams who still have these very conflicting goals we want a shared success criteria we want to deliver the value we understand what the value is the developers are involved in the complete flow even security yes we're going to have a security team you'll often hear about this thing called shifting left the idea that instead of waiting for something goes into production live and then we look at how secure it is by doing pen penetration testing or whatever we introduce security much much earlier hey as soon as we do that commit into some repository there's some scans going on as soon as we build a container image there's scans going on what are its dependencies maybe we run that thing we issue pull requests to say hey look we know that you're using this dependency there's issues with that we recommend you take a dependency on this instead where that is fixed so this whole idea of really building things in unifying it early on earlier additionally we can really think about there's going to be this idea around more self-deployment if we're going to do this more frequent delivery it really doesn't work where hey okay i've written this thing okay now go and deploy this to this small test environment let's check it still works there's going to be this self serve automated deployments but when we do that we still have requirements as a company i still have requirements there might be regulatory requirements where i can deploy what sort of replication i need um what backups i have so we have a governance who can do what how much are you spending budgets there's still all those things that need to be there when i think about the teams what we really want to think about as much as possible is they are vertically structured around a certain skill set a certain discipline that's going to help scale i.e a team around each element of the solution maybe it's the shopping cart team um maybe there's some other element but you want to align them as opposed to just a team of skilled data people of writing java people that makes it harder to collaborate we're still going to have individual skills but as a team we want to be really focused on being able to deliver kind of that set of value okay so when we think about bringing all these different things together well it's going to require some new processes now that is going to mean i require proper tooling like we're probably not going to be able to use the same tooling we've used in the past because hey we're doing things in a new way and i think about okay well i want this new continuous cycle i want to ensure this continued delivery of value it's going to do a lot of different things for us one of the biggest ones there's not going to be this huge gap anymore between the customer either the app owner the product owner and seeing a result so there's this huge gulf between where they can provide input instead we want this continuous delivery so i can think about well to that great big horrible long project i can instead think about a cycle now the exact steps may differ but i can think about well we're going to plan and track so obviously at this point here requirements can come in then obviously we have to develop so we're going to create something it doesn't have to even be code it could be new templates to deploy infrastructure maybe it's a resizing exercise then maybe there's something i need to build hey some maybe final template do something there i'm definitely going to want to always do testing kind of coming into whatever we're doing i'll have some kind of release so i've tested now i'm going to build a release maybe it's a container image um maybe it's a new configuration file it's get ops but there's some kind of release then i'm going to deploy that thing once it's deployed well it's enough is going to be operated so it still has to have operation tasks running and then what i need to do is kind of monitor and learn that's a huge piece and then that learning that monitoring goes back in to the planning and the tracking for the next cycle so what you kind of get in here is this idea of continuous improvement i'm continually improving i'm continually learning i've got this cycle so each cycle is giving me small incremental value this is huge that idea that i'm just constantly iterating and adding in value but in what a fairly small steps so i can think about this whole loop this whole loop so i think about a loop time i want this fairly short because this kind of equals my speed to react because kind of once i've started a loop i'm kind of invested in what i'm doing if some new requirements came in it's very hard to adjust in the loop so i don't want these loops to take huge amounts of time so we typically think kind of a few weeks it should take to get through a loop because then if hey some new requirements comes in it's not the end of the world the loop only takes a couple of weeks then we can get back in we can get new things actually coming so it's a continuous cycle to actually ensure that continued delivery of value but we say value what do you work on that word value can mean different things and what i really care about is what is valuable to the end user i.e the the final customer of whatever this solution is maybe it's what is causing the most pain that is the most value and if we think about that and all those different things how do we know those things well it's that monitoring and learning when we say monitor it's not just monitoring the cpu usage or the iops of a system we still do that we see to make sure we're sized correctly it's monitoring the user behavior what paths are they taking what are they clicking where do they give up i get that piece of information that telemetry that helps me adjust and create the right solution and know where i am focusing on also the human interactions i might want to get feedback from the customer what do you like what do you don't like there's a whole set of extra tooling so when i think about this plan and track what i'm really focusing on where is most value that's the key part i'm going to have a whole list of things that i want to do i'm going to product backlog i'm gonna talk about this but the way i decide what's next to work on now what my methodology is generally gonna be what's gonna give me the most value i'm business i wanna differentiate myself i wanna win on me better than my competition i need to make sure that i'm focusing on the right things we're not focusing on the right things then really what's the point in that so we want to make sure we're really understanding what is the most value so we need good information coming in to make sure we we know what is the right thing now there's going to be a shift in application architecture and hosting most likely as well so remember before we have that big monolithic application well that doesn't lend itself well to this continual improvement that we really want to do i don't really like this that is very hard for me to continually be improving on that that's hard to focus it's hard to how to change a small thing to bring some small incremental value and not break a hundred other things so what i think about moving to is what we want to get to is the idea of kind of these micro services and the idea we have this loose coupling so instead of this big block i have different services that sure there's going to be requirements and they're going to be communicating but you'll hear things about like rest communicating over urls using common get and put very very common ways to communicate i can expose those it's a standard way for different components to talk but they don't need to know anything about internal structures or schemas i can completely change the internals of this part none of these need to know they're interacting via a loose coupling it doesn't matter i can now do what i want in here and as long as that kind of fairly loose way of calling remains consistent nothing else needs to know so i don't want different components to care about the structures and internals of what other things are using now also most likely there's going to be shifts as i start going to things like microservices over here i probably focused a lot on maybe virtual machines that's super common over here i'm going to start focusing on things like containers and then i have an orchestrator like kubernetes the benefit of containers i can spin them up and down super super quickly i can create a container sub second does its job it can go away i can respond to changes super super quickly i'm not wasting resources by having all of these virtual machines maybe not doing that much there's less os for me to manage and that's another key part i'm trying to get away from things that don't bring value i'm going to keep seeing the word over and over again value value we want to do stuff that brings value to our company patching an operating system worrying about antivirus and its firewall and its config is not bringing any value to our company making changes to our products and giving new functionality brings value so the less management and the sort of ownership of things that i can give up that don't bring value the better i want to focus on my app and my code so things like containers things like serverless hey with serverless there's some code i have it's triggered by something maybe it's an event maybe it's a schedule maybe it's a web hook whatever that might be it just gets triggered so i'm really shifting the responsibility to just the stuff i care about and that that is another kind of motion we're seeing more and more things now are kind of shifting to the cloud one of the big reasons for that what is the availability of these types of services if i think about the cloud we have all these different very rich services on premise you probably have vms maybe you have some containers maybe you have a database farm in the cloud there's kubernetes services there's managed database services products open source solutions as machine learning services there's serverless because then i only pay for the stuff i use so that consumption basis is very attractive to companies because i'm only paying for what i use which goes back to the idea hey microservices and auto scale here i'm busy at this moment i need this many i am more quiet i need this many that's huge because now i can save money so i super super care about those things so we see these kind of shifts happening in the environments okay so that that's kind of the goal see the shift in the architecture shifting the hosting let's make it a little bit more real waterfalls and kind of being agile the whole process um the project manager the project management we use is a huge piece of the continuous cycle now i'm going to spend more time on this than any other section because i'm not really going to go into this in other lessons in the course all the other parts we're going to have entire parts about so waterfall used to be very popular we had these large very dependent faces phases of the project i can think about this as okay let's get my board back come on what's going on it's refusing to there we go so if i think about let's go over here for a second so let's think what is waterfall so this was kind of the the standard way and we'll see why it's called waterfall we have the customer we always have the customer this could be the product owner business owner whatever that is they're the people that really know what they want so that the customer always has requirements now we do our best to understand those requirements as well as we can super important to get those so we get the requirements and from those requirements we do a design so that's the user's interaction that customer's interaction feeds into that and then they're done because once the design is complete we have to have design complete first then we can develop once the development is done then we can test once the testing is done well we can deliver it and as you can kind of guess what's called waterfall is well it it flows like a waterfall each of these kind of has to be complete before we can move to the next one and if you think about the customer their next interaction is here okay the requirements off this went and this is a long time six months maybe longer depends what this is maybe the customer's happy at the end of this time maybe not maybe there was a misunderstanding maybe the customer's requirements have changed hey six months a year is a long time especially in modern business that's a really long time maybe they had some new requirements well if you think about hey they have this new requirement if i'm here can i easily incorporate that no so it's very rigid and so what we end up with typically is a fairly unhappy customer because of that lack of interaction it's very rigid i maybe can work out things like costs fairly well and timeline fairly well but it is a super rigid structure it takes a very long time so generally we're not going to end up with a super happy customer so what can we do so the idea here is yes that used to be very popular with these large dependent phases today we're really thinking about moving to an agile mindset now this whole agile mindset is built on kind of four key values these are primary for everything we do with agile it's really about these iterative delivery of small increments we're constantly going to build additional value and because we get these much much smaller cycles we can get feedback far more often so if i think back so if that was kind of waterfall if i move over and now we think of agile so a core component of agile are these small loops and then another loop but it's building on the previous one so each time the total solution is getting bigger because we're building on the previous work so it's this constant incremental value now each of these loops still has those same core phases hey we do a design we do a develop we do a test hopefully most of the time and we do a deliver but they're all smaller and a key part here is that that customer still exists obviously we still have the customer but the customers interactions now are constant there's this constant interaction with what we're doing and so i can think about the core tenant of agile is kind of focused on the individuals and interaction we want that constant communication within the team i want it with the customer it's about focusing on providing working software over for example comprehensive documentation now you're going to see these things like individuals and interaction over process and tools we want to make sure we get those good interactions it doesn't mean the other things aren't important they're just not as important working software over comprehensive documentation i can think of customer collaboration over contracts it's more important to collaborate with them over you still need contracts but that collaboration is more important than a contract negotiation and we think about responding to change over some fixed following a plan now there are other things if i jump over for a second in addition to those kind of four key principles and again the link to this let's jump over for a second we'll actually be in kind of the github i have the links for this but you can see it's hey these individuals and interactions over processes and tools you can kind of see that right here we can see the working software over comprehensive documentation customer collaboration over contract negotiation responding stage overfollowing a plan and then also beyond that what we can actually see as well is there are these 12 principles you can go and go and click on those but if you go to the 12 principles it's all about customer satisfaction welcoming changing requirements deliver working software frequently business and developers working together build projects around motivated in individuals efficient and effective ways of working working software primary measure and again you may be kind of looking at this going like why are we spending so much time on this because this is really the fundamental about devops yes there's tooling yes there's git yes there's ci cd and images and all that other stuff but if you don't understand the why we're doing these things it's really not super useful so it's critical we understand these things to understand why we're doing all of this in the first place so i want to make sure we really understand those key components now within agile there's actually different methodologies now there's a lot of different frameworks um i'm going to focus on two because i think they're kind of the main ones you're commonly going to see so i'm going to just focus on those so let's think about this for a second so we have agile and again there's two kind of i think flavors is the right word of this but we're going to think about scrum and we're going to think about kanban now kanban is actually a few different things which can confuse things but i'll explain that as kind of we go along now both of these things actually start with some things in common we have the idea that we have this product backlog and you can really think about these are items we want to do and obviously those come from essentially well we have those customers who feed in requirements so those things we have in common let's kind of draw a dotted line as well separate where those things differ now a key part of both of those big list of features that the product owner wants and they're both going to have stages we go through and think in common with all of these is we pull we have a certain kind of capacity and we pull items from the previous stage we never push our items into the next stage hey i have capacity i'm going to go and get something that is available to me now when i think about scrum what really you'll nearly always hear about with scrum is the idea that i have a sprint now a sprint is a duration of work it's typically one to four weeks i think two weeks is fairly typical and the way we really think about this working is the team that is part of this they can do a certain amount of work maybe they can do 10 points of work so what happens is the items in the product backlog they they kind of assign points to based on how much work it's going to take hey this one is two points this one is three points that one is one point etc so at the start of the sprint so we think okay we have this sprint they have a meeting so we meet and the whole team the goal here is they agree they pick the higher priority items things that are going to provide the most value again that's the key point that's what's the priority that they believe they can do in that sprint sprint as that defined time they assign a point of work they can do they look at the items and they're going to bring those items in so they pull things in into in this case a sprint backlog so they take items from the product backlog and bring them in based on hey i can handle up to 10 points of work whatever that might be now might be these are kind of big user stories and we might break those into smaller tasks we don't too small so it just clogs everything up but we're going to break those out now within the sprint there are then phases just like we have we have a build phase maybe a test phase and that would say build develop a test phase a deploy phase and the whole goal is hey we pull things into here because hey i've done that piece of work i have i have capacity i can use okay the testing person is finished okay so they pull something that's finished from the build so they can start testing the deploy person hey we pull something in that's been tested that we can do so this takes place over that period of time and then at the end of it they kind of go and have another meeting at the end so we have another kind of sprint meeting what did we learn what worked what didn't work uh where were there backlogs and this is always a pull motion whenever pushing things in that's really kind of a key point to the whole sprint thing so we have this idea we have that framework we're pulling things in constantly so they move through we have those constant learnings that's kind of really a key point now also there are other things you may see as part of this process for example um it's very common actually across both of these but you might hear about kind of a daily stand-up meeting and the reason it's called a daily stand-up meeting is everyone has to stand up why do you have to stand up because it's 15 minutes max by making people stand up they're not going to want to talk for that long if people are sitting down and they're comfy and they're having a doughnut and a drink they'll waffle on and chat for as long as they feel like it they're standing up and they're kind of uncomfortable and they're like oh god i just want to sit down they're going to get to the point so everything stand up meeting to just quickly sync on where we are if there's any challenges then we kind of get back to that work and then again at the end of the sprint they meet they realign they shift they can do that and that's one of the benefits here because it's a fixed duration at the end of the sprint they're kind of starting fresh again they could completely realign they could completely change anything they're doing now one of the things you you'll hear about sometimes i think again this could be in kind of common is you you have this notion i've heard this called two pizza teams now i think that's very very subjective i will eat a whole pizza on my own as we'll talk about in a second i'm assuming these are really really large pizzas will be a team of two but you don't want teams bigger than i can feed with two pizzas again you want that close collaboration and the bigger it gets the more unwieldy that kind of gets and it's really harder to get what we're trying to do the key point scrum i have sprints fixed duration at the start i pull in an amount of work that i believe i can do based on pointing it still moves through phases and i'm still going to track this i still might have a board which we're going to come to in a second where i move these bits i go and look at what's available i'm a tester i've finished my testing okay i need to go and pull something that's finished in build these might absolutely be divided up into kind of doing and done you might see that very commonly so i'm always i'm always pulling something from the previous stage developer is never pushing it to test that's the key point of this whole motion okay so that's scrum sprints all good kanban kanban is different instead of a fixed duration continuous so it is just a continuous stream of work now you could argue if i think about well it's just continuous then it's harder to completely realign because there is no end window if i decide i want to completely change what i'm doing that's actually a bit harder with kanban because there's always things in motion there isn't a point where everyone has stopped that can also be a benefit but we still need to make sure we're not getting some huge accumulation in any one portion of our stream so what we have is we have this work in progress limit or whip that's critical to this working because what we're going to now do is it's actually going to look very very similar it's that methodology of how we arrange the work i still have kind of a build phase i still have a test phase i still have a deploy phase but the way we protect it is we have a work in progress limit the maximum number of items that can be in any one stage so for build maybe we say i can only ever have three things in build any one time in testing maybe i say i can never have more than two so these kind of slots we're allowed to fill maybe deployment i so that's three as well so once again hey if i'm at build and i only have two items i can pull something from here so now i've got three things filled up hey if i'm in tests and i've completed testing and it's now deployed pulled it out i've got a spare slot or maybe i've got my doing and done again so maybe i have an extra slot how i arrange this can vary i would pull something from build deploy would pull something that's completed out of test so if those same ideas we pull when have space that's the key point really for all of these i'm always it's with a poor motion from the previous phase when i'm ready and that work in progress makes sure i don't have 50 items sitting in test because i still want to make sure things can move through fairly rapidly what i don't want because it's about agility and how to respond is i have 50 things just waiting in tests and then hey i have some new requirement come in well maybe bills can take it then it's going to sit behind 50 other items for nine weeks i don't want that i still want this total time of this cycle from something coming in to exiting to be a couple of weeks so i do really think about sort of time entry to exit i want it to be weeks not longer than that and that whip ensures that it makes sure i don't have some huge bottleneck at some point that everything will just get cued behind so it's super important that i have that as part of that overall solution so when i when i think about okay that whip limit there's no time box it's just this ongoing thing people pick up capacity as we go through i mentioned kanban was multiple things so kanban is actually really old i think it started in toyota factories as a method to make the manufacturing more efficient so it's a very lean process that's kind of a key point and kanban is actually a japanese word for i think it's visual signal or cyan board but it's all about that visualization so we think about kanban is all about that way to visualize the work having kanban cards an item from that product backlog which again i could break up into different um tasks if need be if it was too big that's going to move between the stages and as a team i could have an actual physical board where i like maybe post-it notes and i move them between it could be a tool now an example of that and i just kind of threw this together for a bit of fun this could be a kanban board that i might use for my video creation now this is azure devops github has a similar idea it's not quite as rich today and you can see i've kind of got my product backlog on the the left over here you can see i've got kind of my researching so i and again the columns themselves could be different i name them what makes sense so if we have to go and research the topics so we say okay yeah i'm researching windows 365 overview and devops masterclass 2 i've drafted actually i finished drafting so i say 8. my recording i can have one thing so no it's these numbers in the top i'm allowed to have these are my work in progress limits i'm allowed to have three things researching two things drafting i'm gonna add one thing recording well my recording has i'm available so i can actually pull this over because i'm actually recording this class as we speak so i can actually move this to recording at this point now i can customize kind of what all these different things mean so i can rename them i can configure different things so i can see hey recording actually my user story is not resolved so i can change what does it mean it's still active so i can save and close that so now my recording oh i'm kind of messed up a little bit but now that's actually gone back over to somewhere and it did warm me but now so that's if i actually change it as backlog there's my master class one so it's gone to resolved but i can actually go and look at that this is obviously not my focus for this particular thing but i could change that back to active save and there it is again i'll move this back into recording so it's still active but you can see hey i'm pulling things over and now drafting has spaces maybe if i'm ready and there was kind of a done i could pull one of these over because sometimes someone's not ready to pull it straight away but i want to be able to signal to them while i am finished so on all of these different things i could actually notice here there's a split column into doing and done so if i save that now my drafting it's the same shed whip limit but if i finish drafting saying i could move it to dance that signals to the person doing the recording hey i could pull from that dumb column when i have capacity so that's something i can do so this is a kanban board now notice this board i might absolutely use with scrum as well this side of the board would absolutely maybe make sense but this idea of the work in progress limit is absolutely critical that's what stops me overloading and here's where i can go and say hey my work in progress limit this is what's going to make this process work without the whip it could just have a huge mass of things just bottlenecking at a certain point which makes it very hard for me to then actually get things through as my requirements change i'm actually going to change that drafting back to knock split just so it looks better for what i'm doing but you get the idea so that that is a kanban board and you could see hey i could absolutely use that on scrum as well that same thing would absolutely apply now kanban has a whole number of principles and i guess we should kind of write these out so if i think about for a second what matters to kanban so a key part here is start how you work don't have to do some massive change initially start with how you work and do incremental evolutionary change rome wasn't built in a day nor does my shift to this respect roles every role has a place understand what that role does leadership from all likewise accept input from everyone on the team i want to think about that visualization this is the key point it's a visual system of things moving over that board limit the whip the work in progress is critical again without the work in progress time from entry to exit could be huge and it becomes worthless because i might get some new high priority item added well that's fine i can re-privatize and i'll grab it on the next available build slot but if then it gets stuck somewhere it's going to take months to move through i don't want that i want to limit the amount of work that's in progress so people aren't just sitting there wondering what to do and nothing constructive gets done we want meaningful work to be happening on any item that's part of our kanban board that's actually in progress it might be meaningful not just stuck behind a whole bunch of different stuff always pull we don't push something to testing testing have an empty space they finish testing something maybe it's in there done they have an empty slot they will pull something that i've developed the code for i don't tell them how you go and test so we're managing the flow i want good definitions everyone has to be in agreement of what those different stages those columns are so we are working collaboratively because we want to improve that collaboration that really is kind of a key point to everything we're going to do so use and focus on the principles just using a board doesn't mean you're doing kanban it means i'm doing a kanban board and i've got notes but if i'm like oh i finished building i'm moving it to test that's not the point they have to be pulling those things want to collaborate understand what they mean together to understand the core principles if i have bandwidth and i'm working in a particular stage i pull something that's available that i can now work on those teams might be cross-skilled so if i find now i really have nothing to do maybe i can help out and i can help maybe on another stage so we can keep the things running now still with these we're still probably going to have meetings periodically we might start those stand-up meetings we're still going to have meetings where we discuss what's working what's not working we'll be able to see where there's bottlenecks because when we have those communications if tests are saying for example i'm just sitting here i've got nothing to do well building now realistically building is going to take typically the most amount of time but maybe hey we need more development resources um or if we find things just sitting in test deploy is taking too long we need more deployment resources so we can use these things to understand so we always pull kind of highlight that when we have space and we can help actually go and see when there are actual things we can do etcetera and again kanban boards could absolutely be used by scrum they still moving items and we actually saw in azure devops devops will actually let you specify am i using scrum um each of these items actually i've got points i did that just for fun but i can assign points to the different user stories that i have if a user story is too big like my master class for example well that's actually made up of multiple classes so if i look at as a backlog so you can see hey these are all my user stories but i also have work items and i have a devops masterclass epic so this is a big all-encompassing bigger initiative that you can see down the bottom here has child items as you can see it has child items master class one and two and actually it should also have a link to it has another child master class three so i can actually create these bigger narrative these bigger things i'm trying to do as an organization for my product but it doesn't make sense to try and do all of that as one item of work so i break it down into individual user stories that i can have those digestible kind of bites out of and actually make progress with so that's kind of a key thing that we want to be able to actually go and leverage okay so those are really kind of the key difference we want those key things we can buy you can mix them together you'll see people that are scrubbed that are moving to kanban i think there's actually a scrum ban where it's a mixture of scrum and kanban whatever works the key point of this you don't have to be super rigid necessarily what works for your team and how you deliver but as long as you all agree on that and it works so be it change is never easy start small look for pain points look for teams that are willing and want change introduce the change with them start with something small enough that i can actually make some real progress in a relatively short amount of time i want to win i want a hero win i can then demonstrate the value of this to the rest of my company then build on that success again you're not going to change overnight people always hate change get the showcase when show the value and then kind of build from there now all of this kanban and scrum can kind of be a little bit confusing so i want to talk about pizza that'd be the second time i've mentioned pizza in this i love pizza pizza i think it's my favorite food and i was actually planning this out the drafting and it was friday night every friday night for me and my household is grimaldi's night fantastic pizza brick carbon pizza awesome as i was thinking about it i was ordering the pizza it occurred to me it's actually a fantastic example of kanban so i actually went and picked up the pizza i take it home and i took a picture it was kind of awkward they were kind of looking at me like what are you doing why are you taking a picture of us but it's a great great example so i think about it i phone up okay i phone up and i place my order now i actually took the ticket it's actually my kids pizza 12 inch cheese half pepperoni no basil like cook okay so this essentially if i think about kanban is a kanban card it's it's a it's an item of work and this requirement from a customer would actually go to their product backlog so that wheel that they have there of all the pieces to be made would sit on there you can see they kind of got those tickets it would get added to that so if i for a second take that let's go back okay so that was kanban now let's think about saying closer to my heart something that i really care about i can get behind so i am now going to think about pizza kanban i'll be more enthusiastic so i have still a product backlog remember that little circular thing with the tickets please on there now remember a key point of this this ticket also has the requirements so this ticket has the requirements on it so it's kind of a 12 inch cheese no basil yuck anything green etc and those come from the customer me and they're sending in their requirements and it really is me there's no hair on that picture now in terms of the restaurant let's think about it so we have the product backlog that big wheel but this is a phenomenal idea behind it so someone actually took the order customer and added it to the product backlog now the people actually cooking the pizzas have stations they maybe have four slots that they can actually make pizzas at so if i think about the flow of this well i have the ability to make pizza actually construct them they have a finite amount of space actually on their table so maybe there's this is where they can make pizzas maybe there's four spaces so what that gives them there actually is a whip limit a work in progress limit of four they can only be making four pizzas now maybe that's a doing and they also have a done maybe they have a little done space over here as well maybe they can store two pizzas maybe they have a whip limit of two for done so the total whip limit would be six so whenever they have a space what do they do they pull they pull a ticket that it's a next priority item so imagine as a customer i got the wrong pizza it had basil on it um that would be a high priority they would pull that off the product backlog and make that pizza next now back to the picture okay so they've made it the oven is next the oven has a finite amount of space in it so i can think okay well then they have to cook the pizza so then we have cook and once again the oven the fire it has a finite number of spaces in the oven maybe it has a whip limit of let's say nine and maybe once again there's kind of a spare done of a single space they can put a pizza there's a whip whip limit there so maybe it's a 10 is the total whip limit when they're done well someone has to actually go and check the pizzas and cut it and box it and maybe there's just two stations there's two people so that has a whip limit of two and then from there it either goes to the table where people are sitting to eat or maybe it's been picked up so it's kind of a warm up but essentially it's been delivered so always it's a pull action the person who's doing the oven pulls from the done the people making the pizza never throw it at the person who's putting the pizzas in the check-in box people take it from kind of that down it's always a pull that way and then the the waiters the waitresses take it from the done that are boxed up it's always pulled between those various sections and that's kind of a really really important point when we think about that so i actually think it's a really nice idea so those whip limits really do control the pizza kitchen because again what i wouldn't want is to have no limits and they just start stacking up pizzas here that are cooked they're getting cold or they're stacking up here and they're just going bad because they need to be put in the oven also if there was just a huge number of pizzas stuck at one stage if there was a reel to come in a high priority it would take ages to move through so by having these work in progress limits it makes sure if there is a priority order come in it can still move through in maybe a 10 minute time window it's never going to get stuck behind because there's so much cued up so i think a pizza restaurant actually does a really good job of really showing the idea of a kanban ball they are a kanban board this ticket my ticket moves through the station it follows they take the order it goes on the board they tuck it under the bit of wood as they're making the pizza i don't quite understand how they put it in the oven but somehow it still follows through it goes in the box and it gets delivered to me so the pizza moves through all of the stages i take the pizza i deliver it and then there's me eating my tasty tasty pizza every friday without fail so you can see the kind of importance of those various things now i guess you could what you could argue actually okay john so that was kanban how would this look if it was scrum so you could say well that the stages would actually be the same so if i now went to a scrum idea of the pizza you still have the same product backlog with all the tickets on it i would still have the same kind of make i would still have the same kind of cook i would have the same check and box the difference would be i would have a sprint and i would have maybe a 30-minute sprint i'm going to make pizzas in a 30-minute block of time so the difference would now be what i would do is i would have that kind of sprint backlog and i might say in 30 minutes we can make 60 points of pizza now depending on the pizza order like an extra large everything on it might be five points a small cheese might be one point medium pizza two points they would take tickets that they're going to make in that next sprint that's the priority so kanban you're prioritizing every time kanban every time they have a space they're looking at the product backlog and taking the next priority item the manager can move things around and give things higher priorities it's the next one taken that process in the sprint in the scrum model can only take place at the start they're pulling all of the tickets they're going to do in that next 30 minutes and then it would look the same they're gonna oh okay we'll take these and make them then we'll pull they're still it's all still a pull motion there to the customer at the end of the 30 minutes they would say what went well okay well okay we bit slow doing this part we need someone else cooking it's harder to react mid-sprint i really can't like an urgent order came in i have to wait till the end of the sprint so i can really do something but i know i'm going to get this many pizzas made in that sprint it's easy to plan out if i look at sort of scrum because we have these saturation sprints because we have these units of work i can do i can actually plan out further in advance i can absolutely say hey okay i know i'm going to make this many pizzas in this sprint i know this many it's going to take me an hour and a half to clear this complete order i can plan well out in advance whereas with the kanban because it's continuous it can be a little bit harder for long long term things to plan out work out exactly when they're happening but i can definitely react faster because it is continuous at any point i can kind of hey there's a gap i'll take the new requirement that's come in i will start processing that one so that made sense i really just wanted to be able to talk about pizza um but i think that's kind of a really good analogy actually for kanban i think it relates well when i actually think about doing those things so i spent a bit more time on that than other things we'll talk about today but it was kind of an important point so we want to make sure we did actually focus on that so now let's think about for a second i've lost my remote i already have lost my remote the next slide oh it's under my ticket so just quickly get continuous integration continuous delivery continuous deployment if i'm going to have this constant incremental value it probably means i need new ways of working new ways of testing new ways of delivering now again i'm going to cover all of this next week is going to be probably a really long lesson all about git i want to do a master git next week but i'm going to have people working on the same potential areas of code they need to be able to bring that together constantly without locking each other out in a traditional version control i need version control i need to be able to see what changed who changed it why and traditionally we would check out a file no one else could change that file and that's not gonna work well in these types of things so i need to be able to track what changed i'm gonna maybe have the same file change for different regions reasons i have a bug i need to fix i have a new feature i have a new release same file might be changed in different ways how do we handle that so a git based solution is actually perfect for that we use this get for source version control that enables that concurrent development so i think about let's actually scroll back out for a second we'll go back over go back over to here so i want to think is let's zoom in there we go so we have a git i have an idea of a repository so we have this get repo now the common kind of symbol for forget is kind of this and it's really showing the idea of branches hey the code goes in different directions but we can bring them back together now an important part get does not mean get hub git is a standard it's a tool set that i can use to version control i can use it just entirely locally on my machine but i have this repository and i can store different things in there i can store text files i can store images i can store artifacts there's different things i can do with that but a key point it is a distributed system so i think about git repository has a whole bunch of code in it well if i'm a developer over here if i'm an i.t operator over here we all have a full copy of that repo on our machine completely full all of the files the same size and what we do is we commonly we're going to sync it to that common shared copy so a big deal with this it is distributed i have a complete copy of the entire repository on my local machine now when we talk about this next week i'll talk about how hashes are used to make sure no one can change anything so i can track everything that changed we can still be assured of all of that but essentially is it fully distributed i can change any file i want and then through very powerful mechanisms even if someone change the same file i can merge them back together i can find conflicts i can resolve them very easily now what i do want is this central copy if i'm collaborating i want that central copy this is where you will hear about things like github obviously azure devops is a big solution um bit bucket and there's a whole number of solutions there's not a right or wrong use what works for you and your company but i'm going to demo mostly github but again there's azure devops repos there's there's lots and lots of those kind of essential git repositories so everyone has their own copy fantastic the challenge with that is if everyone's got their own copy i'm syncing them it's really important there's not big long gaps between syncing them and bringing the code back together to make sure someone's not introduced a bug or an incompatibility now we're using loose coupling we're doing these good things but if more people are changing the same files still problems could occur so we need to make sure that it doesn't happen so you want to integrate each person's changes in very very frequently maybe nightly and we do that through kind of they commit the changes they've made so far to a certain branch and we need to basically bring those in build the solution run some tests and make sure the result is kind of what we expect maybe we come and create some output so we have the idea this continuous integration so from here yeah i've got this git repository and what kind of happens is people will make commits a commit is hey there's some unit of work that i have done and so that will then build into this idea of continuous integration c i so that commit will likely trigger now it doesn't have to be a commit it could be some kind of schedule but what we're going to have is a pipeline that's supposed to be a pipeline and the whole point of this is this is automated now again we think shift left ideally there's going to be some kind of security straight away oh we've checked in this code let's go and check some things there's no secrets that have been put in the republic i'll talk more about that in a second um i don't have something i shouldn't have i'm not using a bad dependency and then it does a build this is all automated then maybe there's some automated tests it can perform i can have some automated tests maybe there's some manual ones maybe then it goes and creates an image of some kind once it passes the test and then maybe it uploads that image to some kind of registry so this is just all happening automatically and if there was a problem we can even have this go and create a work item say hey this test failed or this check failed or this security thing hey it's going to create a pull request and say you should have this dependency instead so i can have those capabilities but it's continuously integrating everyone's code yes i'm working on my own distributed copy but and this is again processed people need to make sure they check these things in if someone doesn't do a commit for three months and then commits one thousand changes that's going to be a bad day so again part of the people process tools process make sure you're frequently committing and then we're going to have this continuous integration we're constantly bringing everyone's changes together to make sure it's still behaving as we need it to okay so that's checking everything is still good awesome then i need to think about well i want to continually bring that value maybe it's creating some xc or an image docker image maybe it's a image for a scale set maybe it's a package maver an npm whatever that might be i create something then i need to deploy and actually get used by something so how do i then actually think about doing that once again i want the idea of continuous delivery and maybe even continuous deployment now obviously i have to deploy this to something so this is maybe created something maybe i've loaded to a registry and i could i could kind of think about that maybe hey okay so this pipeline went and did it to some registry somewhere created something so now i want to think about okay i want this continuous delivery says another pipeline now again this pipeline the trigger could be hey look something new has been put in that registry a new image has shown up okay we need to go and test it that could be the trigger maybe it's an artifact a new xc has shown up whatever that is now remember i have to deploy to something so maybe this is actually build or verify infrastructure do i have my kubernetes environment there and ready then maybe i actually go and okay deploy whatever the thing is deploy i'll say artifact could be an image it could be an xc don't know what that is then i i have a test at this point i probably have a gate now a gate can be many different things a gate could be maybe a number of work items raised i.e bugs it could be an approval maybe it's combined with a time window there's some delay and then maybe it goes and repeats kind of these things maybe now it's a uat infrastructure deploy or validate then it's deploy the solution to uat and then maybe it's again there's some other thing but all of this is kind of my continuous delivery all the way through deploy uat test uat and again this could be a manual proof maybe there's a test plan that humans have to go and do various things so that's delivering the all up solution and then what i can also have at this point is actually continuous deployment actually now getting it to production so continuous delivery is about getting it ready and all it's good i think about having a really big gate here but then the pipeline could actually kind of continue to kind of prod infrared make sure it's good prod deploy and also they'll be on a prod test we still would do those kind of validation tests so all those different kind of things going through so the continuous deployment actually goes through and into production now when i think about production i'm not just going to deploy this like when i'm here these types of things are all going to be about different types of deployment pattern very rarely would i just stick all of that in production maybe i have the idea you might have heard of blue green the idea that i basically have two environments and so i would deploy the new code to the green environment and then switch to make green production if something goes wrong i can switch them back very very simply i might hear about things like canary so with canary i deploy it to a very small sampling of my users to see if any of them have a bad experience and complain if i don't i can expand it out so maybe it's kind of five percent and then i deploy it to 15 then 50 percent then like 100 and i'm waiting for people to complain maybe it's rings rings will be very similar i said i'm not so much waiting for a certain portion to complain i just have these rings of deployment i follow there's many other there's a whole ways to think about that deployment for continuous deployment i'm actually driving that value through so if you look at the entire pattern it's like wow the code comes in it's continually integrated to make sure something's not broken i want to find the problems early find them early and often i don't want to wait a month someone did saying it broke something who cares i found it that day i'm going to fix it before it becomes a big issue move on but we're going to find it through continuous integration hi hey when we pass a certain gate we've created an image it got through all of these things i can actually get those delivered out so i can have the artifact ready to go to a production and maybe i actually do continuous deployment to actually get it to production in automated fashion again gates to validate things and use different patterns to get it out there there's all different things i can do but i can absolutely do those things so i have the idea i have to think about secret handling as well so all those pipelines there's tools to do that um definitely good to do i can check for secrets i can look for some credential but this really does come down to that kind of people process thing in a huge way i'm going to stress this here never put secrets in your repos in your code in your config files no secrets no private keys not hard-coded in configuration files here never ever ever what i do is i have a vault now in azure this would be azure key vault these are good at storing secrets a secret is something i can read and write back it could be like a shadow that says signature i store my keys a key is something i can't extract back out but i can do cryptographic operations in the vault so i can send it hey do this cryptographic operation create me this signature validate this thing uh maybe certificates kind of life cycle management that's where those things go now i can bring those in to my pipelines all of these pipelines run as a certain credential so i can use role-based access control to control which secrets which keys can be used by dev uat i can control all of those things there so it's really kind of an important point around that so i'm never putting sequence in my repo i'm always using a vault okay importance of monitoring and i can kind of just monitoring is always important i want to make sure my production systems are running they have enough resource i may be doing scaling intelligently yes always important there but for devops almost more important is monitoring of the interactions and that user behavior i've talked about that already we want to drive value and we have to make sure the value we drive is the priority value where it's gonna have the biggest bang for the buck what's gonna mean the most for my solution that differentiates me from my competitor so i have to know what matters to the end user so what features are they using in the app through the service what's getting called when do they give up this bit must be super painful what features get used the most are there poor user experiences very long delays if i just look at the counters on a server cpu and iops and network i'm not going to see those things the only way i can see those things is to actually get feedback from the user so i potentially need new tools new telemetry to actually be able to get that so i think about hey my my overall solution all of this here yes there would be things tracking through those things but at the end of the day there is some end user here like the customer what is their experience that's really what i care about so i need feedback now that feedback could be in the terms of especially in testing surveys hey what did you like what didn't what didn't you like but also there's going to be maybe some device they're using could be a phone whatever i kind of want to be able to track telemetry of what paths they took on the application what functions are being called i want to be able to know those things to see what they like what they don't like on azure things like app insights i can hook into my application code i can hook into the end user device mobile platforms to see what they're using to actually go and get that feedback i have to have that and additionally when i think about monitoring we're going to have a whole unit on this they're probably our key performance indicators pki definitions that i need to have to work out am i working on the right things i'm picking from that product backlog what i believe is driving value is it driving value i need to know that i might have kpis how often are we releasing what is the deployment speed how many deployments are we doing how long does it take to release a new priority item so something new shows up on that pizza twirly how long does it take to actually get at the customers table what is the sentiment of the user population are they happy or getting happier or are they kind of getting fed up are we more efficient how many admins do we have per customers how many support calls are we getting how used are the different parts of our application how many bugs are being raised indication of quality are we meeting sla service level agreements ideal quality what's the morale of our team is our team happy but are people leaving or are we retaining them so what's the overall morale so there's all these different interactions i really have to think about so monitoring is key to everything we're changing all these processes remember i'm making all these big changes okay i need to make sure it's of value is the customer happy are things performing well as as a i've got custom in different places here there's different ideas there's like the business owner there's maybe the end users target it could be different am i providing value the team that's doing all of this stuff how are they do they hate this is it improving their lives are they overstressed i need to know and understand those things to really understand is what i'm doing the right thing or do i need to reassess a whole point of this is remember those continual learnings in those loops there's always that monitor and learn we have to learn we have to we have to take those steps okay so last key thing infrastructure is code so self-service is a key to agility i've talked about those pipelines and the idea that hey i'm not waiting for some operator to click the button it kind of just goes through but i also talked about build and validating the environment i don't want to create things through a portal portals while intuitive uh i mean they're just subject to error i'm going to click the wrong thing i do the wrong thing i want it automated so what we always think about is infrastructure as code so i don't want to create by the portal i want my infrastructure to be defined by some kind of code now these are typically declarative and item potent this is what i want it to look like i'm not telling you how to do it and i can just keep re-running that if it already matches great it won't change anything i'm going to use them actually in my pipelines so i go back to my picture kind of over here i could absolutely think about okay i have my infrastructure as code now that infrastructure could be a storage account it could be a kubernetes environment it could be a bunch of vms whatever that is i have my infrastructure as code now that's got a whole bunch of resources it's defined this could be a json file it could be a yaml file things like kubernetes it could be a bicep file if it was azure specific but the key point it is declarative it is item potent i can keep re-running the same template it's not going to error if it's already deployed then it's just going to match i think that's what declarative wrong a terrible spell this is a key property it's prescriptive it's going to look this way i can i can source control this thing it's json it's yaml so because it's kind of textual well i can actually store that in my git repo it's not some special unique butterfly it will be in my git repo for my project the same as everything else so i'm not doing anything kind of special around there and it is human readable and because it's declarative saying what i want the desired state to be it makes it i can audit it very easily because hey does it match what is deployed so i can demonstrate yes we have had this configuration which is required and from these hey i can push out resources to the cloud i could push out something to a kubernetes environment that's supposed to be a steering wheel i i can't draw that at all it could push out to things like an operating system i could use chef puppet powershell dsc there's all different things i could create docker files composition files these could be yaml files for kubernetes i'll talk about in a second i can also do things like get ops so git ops is the idea that i can just point my for example kubernetes cluster to a repo and every time there's a commit made it will actually go and pull down the changes and apply them so again those yaml files are all stored in the repo and through things like flux and helm helmet is really just a structured um combination of multiple yaml files that make up a complete solution i just have to once deploy my new desired state and all my kubernetes clusters will just go and pull those things down straight away this single template defines an entire service now i could have smaller kind of kind of parameter files that might be environmental specific so i have a dev one i might have a uat one i prod but the actual template itself is the same i could use that in completely different applications they can all share those things and so all of these files when i talk about build verified infrastructure i'm doing that with my declarative files every time we see that validate infrastructure in all the pipelines i'm using an infrastructure's code to actually do that all of these things really come together that's kind of the key point in what we're doing on this so talk about git ups we're going to have a whole lesson on get ops as well getting ready so that was all the topic i wanted to cover there was a lot of stuff i know there is nothing cloud specific there is no tool specific really about this i'm wondering about the principles and the ideas behind it i am an azure person go and get visual studio code it's free cross-platform linux mac os windows i'm going to be demoing a lot of things in that go and get git um again it's available across platform i can use git entirely on my local machine i don't have to have any kind of server i can have a complete repository on my my machine i'm an edge person i'm going to demo when i deploy things to azure if you have a different cloud you use use that not gonna make any difference if you don't have anything you can get a free azure um subscription gives you a bucket of money you can use i think for the first 30 days there's some some services that are free for a year there are some that are free always so go and sign up you can go and sign up for a free github account so one of the nice things actually show this quick so there's different github plans but for free i can have unlimited number of public and private repos there's a number of automation minutes package storage issues and projects community support at zero dollars so i think we can all likely do that and likewise for azure devops as well so if i go and jump to the azure devops link and all these links are actually in the description and these actually more about the git ops repo i'll have all these things azure devops is actually free for the first five people so again if we go and look at the pricing there's stuff i can get individually but notice the first five users are free in any company like if they have msdn they don't even count out of those five so i can actually go and start using this even if i create a couple of accounts so i can show things working together i can go and create that thing so go and sign up so i've got these tools available most of my focus when i'm talking about tooling again will be github and azure devops again there are other solutions you don't have to use these is just what i'm more familiar with so i'll demo on those it's the concepts that matter and those get ups those concepts are fairly universal across different solutions so that was it um any questions about this lesson please post below please don't say when's the next one coming out i'm glad probably trying to live on a weekly cadence there'll be times i won't because i want to do a different topic about a certain technology in between but for the most part i'm going to try and do one of these week comments about this content below huge amount of work to create this so please please like subscribe and share and uh until next lesson take care you

Channel: John Savill's Technical Training

Views: 29,202

Rating: 4.9829302 out of 5

Keywords: DevOps, master class, agile, scrum, kanban, git, continuous integration, continuous deployment, ci, cd, monitoring, IaC, infrastructure as code

Id: YMdtaWfU_QE

Length: 99min 8sec (5948 seconds)

Published: Tue Aug 10 2021