WEBVTT 1 00:00:00.080 --> 00:00:01.600 You know, it's funny. If you just like look at 2 00:00:01.600 --> 00:00:03.759 your phone right now, chances are one of your apps 3 00:00:03.799 --> 00:00:05.919 just updated in the background. Oh yeah, you probably didn't 4 00:00:05.919 --> 00:00:08.439 even notice, right, you didn't even notice. You open it up, 5 00:00:08.439 --> 00:00:10.640 there's a new feature, maybe a fresh layout, and the 6 00:00:10.679 --> 00:00:12.039 application just works. 7 00:00:12.279 --> 00:00:14.480 It's totally seamless, it really is. 8 00:00:14.759 --> 00:00:17.160 And you know, have you ever wondered how these modern 9 00:00:17.280 --> 00:00:22.239 tech giants actually managed to update their software seamlessly, like 10 00:00:22.519 --> 00:00:25.120 multiple times a day without breaking the internet. 11 00:00:25.000 --> 00:00:27.359 Especially when you compare it to the old days exactly? 12 00:00:27.519 --> 00:00:30.199 I mean, think back to that shared pain of older 13 00:00:30.239 --> 00:00:34.240 software development, the kind that took literally years to release 14 00:00:34.280 --> 00:00:36.640 a single massive update, and when. 15 00:00:36.479 --> 00:00:39.840 It finally did arrive, it was inevitably full of bugs. 16 00:00:40.200 --> 00:00:44.759 Always. So welcome to today's deep dive. If you're our 17 00:00:45.000 --> 00:00:48.280 learner today, your mission is simple. We are giving you 18 00:00:48.359 --> 00:00:52.359 the ultimate shortcut to understanding exactly how that modern seamless 19 00:00:52.399 --> 00:00:53.119 engine works. 20 00:00:53.200 --> 00:00:55.719 We're basically looking at the difference between a finely tuned, 21 00:00:55.920 --> 00:01:00.799 continuously running engine and well, a very fragile, very expensive 22 00:01:01.000 --> 00:01:01.759 house of cards. 23 00:01:02.280 --> 00:01:04.879 Couldn't have said it better. We're pulling from excerpts of 24 00:01:04.920 --> 00:01:09.519 the book Azure DevOps explained by Shujazl, Stefano, d'miliani and 25 00:01:09.560 --> 00:01:10.359 Amit Malik. 26 00:01:10.599 --> 00:01:12.959 And our goal here isn't to just throw a dictionary 27 00:01:13.000 --> 00:01:15.400 of technical jargon at you. I mean nobody. 28 00:01:15.040 --> 00:01:16.079 Wants that, definitely not. 29 00:01:16.280 --> 00:01:19.959 We want to decode what DevOps actually is at its core, 30 00:01:20.640 --> 00:01:24.760 because it represents this massive fundamental shift in how teams 31 00:01:24.760 --> 00:01:26.519 build products and deliver value. 32 00:01:26.680 --> 00:01:29.920 Right, and we'll be looking at how Microsoft's Azure DevOps 33 00:01:29.959 --> 00:01:34.040 platform takes those high level, sort of abstract ideas and 34 00:01:34.079 --> 00:01:38.000 turns them into a mechanical, daily reality for developers. 35 00:01:38.079 --> 00:01:40.480 It's the practical application of the philosophy. 36 00:01:40.599 --> 00:01:43.560 Okay, left untack this because before we can really appreciate 37 00:01:43.599 --> 00:01:46.560 the specific tools Microsoft built, we have to understand the 38 00:01:46.560 --> 00:01:47.760 pain points they were trying to. 39 00:01:47.680 --> 00:01:49.680 Solve, right, exactly, you have to look at the history. 40 00:01:49.840 --> 00:01:52.239 Yeah, for anyone who has been in the industry a while, 41 00:01:52.280 --> 00:01:56.519 the old waterfall methodology is uh, well, it's a familiar ghost. 42 00:01:56.359 --> 00:01:58.000 A very haunting one for some people. 43 00:01:58.159 --> 00:02:01.439 True, we don't need to rehash the entire rigid process 44 00:02:01.480 --> 00:02:05.239 of moving from requirements to design to implementation. But the 45 00:02:05.280 --> 00:02:07.000 fatal flaw was always the isolation. 46 00:02:07.480 --> 00:02:11.840 The silos. Development and IT operations were treated as totally 47 00:02:11.879 --> 00:02:17.240 separate kingdoms. They shared almost no cross platform knowledge whatsoever, which. 48 00:02:17.039 --> 00:02:18.520 Is wild to think about now. 49 00:02:18.639 --> 00:02:21.919 It really is. Developers would write the code on their machines, 50 00:02:22.319 --> 00:02:25.400 make sure it worked in their highly specific local environment, 51 00:02:25.879 --> 00:02:28.680 and then essentially toss it over a brick wall to 52 00:02:28.759 --> 00:02:33.560 the system administrators. Good look, pretty much. Those administrators were 53 00:02:33.599 --> 00:02:37.319 then tasked with the near impossible job of integrating and 54 00:02:37.400 --> 00:02:41.560 deploying that foreign code into the real world infrastructure. 55 00:02:40.919 --> 00:02:44.400 Which is why the customer's roll, or really the lack thereof, 56 00:02:44.599 --> 00:02:47.360 was such a massive disaster in that model completely. I mean, 57 00:02:47.360 --> 00:02:49.759 a company could spend a year building a complex system 58 00:02:49.800 --> 00:02:52.479 based on a design document created on day one, but 59 00:02:52.479 --> 00:02:55.000 by the time the customer finally sees the working software, 60 00:02:55.159 --> 00:02:57.199 their needs have entirely changed, and. 61 00:02:57.159 --> 00:02:59.960 That leads to massive, expensive redesign. 62 00:03:00.400 --> 00:03:02.919 Right it sounds like the waterfall method is basically like 63 00:03:03.039 --> 00:03:06.039 paying a contractor to build a house, leaving the country 64 00:03:06.080 --> 00:03:07.919 for a year and just hoping it looks good when 65 00:03:07.919 --> 00:03:08.439 you get back. 66 00:03:08.560 --> 00:03:10.039 That is a terrifying thought. 67 00:03:10.080 --> 00:03:12.560 Isn't it. But DevOps, on the other hand, is like 68 00:03:12.639 --> 00:03:15.120 reviewing the house room by room as it's being built, 69 00:03:15.159 --> 00:03:17.360 so you know you can actually change the paint color 70 00:03:17.400 --> 00:03:18.280 before it dries. 71 00:03:18.560 --> 00:03:21.800 If we connect this to the bigger picture, that visual 72 00:03:22.439 --> 00:03:26.960 perfectly captures the business value. This evolution into DevOps, which 73 00:03:27.000 --> 00:03:32.479 merges development, IT, operations, and quality assurance. It's entirely about 74 00:03:32.520 --> 00:03:35.479 breaking projects down into smaller iterative phases. 75 00:03:35.639 --> 00:03:35.800 Right. 76 00:03:35.879 --> 00:03:40.639 The sprints exactly sprints. By reviewing daily builds and having 77 00:03:40.800 --> 00:03:43.520 end of sprint demos, the customer is deeply involved the 78 00:03:43.560 --> 00:03:44.479 whole time. 79 00:03:44.319 --> 00:03:45.840 So they aren't just waiting around for a year. 80 00:03:46.039 --> 00:03:48.439 No, they get a stronger sense of ownership, and it 81 00:03:48.520 --> 00:03:52.199 guarantees that the development is strictly tied to actual current 82 00:03:52.400 --> 00:03:56.439 market needs rather than some outdated assumptions from twelve months ago. 83 00:03:56.759 --> 00:03:59.400 That makes so much sense. So that's the underlying philosophy. 84 00:03:59.599 --> 00:04:01.800 But the book book lays out six core principles that 85 00:04:01.879 --> 00:04:04.319 actually make this function in reality. 86 00:04:03.960 --> 00:04:05.599 With the commandments essentially. 87 00:04:05.840 --> 00:04:08.280 Yeah, and instead of just listing them out like a 88 00:04:08.319 --> 00:04:11.919 table of contents, let's imagine how this works in practice. 89 00:04:11.960 --> 00:04:15.719 The text uses a sample sandbox project called tailwind Traders, 90 00:04:15.759 --> 00:04:18.079 which is like a retail e commerce. 91 00:04:17.720 --> 00:04:20.480 App, a great real world example to ground this in. 92 00:04:21.079 --> 00:04:23.800 Right, So let's say tailwind Traders wants to roll out 93 00:04:23.839 --> 00:04:27.519 a new dark Mode feature. Under the first two principles 94 00:04:27.759 --> 00:04:30.800 customer centric action and creating with the end in mind, 95 00:04:31.360 --> 00:04:33.839 the team isn't just writing code in a vacuum. 96 00:04:34.000 --> 00:04:37.160 No, they're acting like a true product company. They're building 97 00:04:37.160 --> 00:04:40.079 short feedback loops with real users to see if dark 98 00:04:40.079 --> 00:04:42.120 mode actually improves the shopping experience. 99 00:04:42.279 --> 00:04:44.800 And that leads directly into the third principle, which is 100 00:04:44.959 --> 00:04:47.040 end to end responsibility. 101 00:04:46.319 --> 00:04:47.879 Which is a huge cultural shift. 102 00:04:48.040 --> 00:04:51.319 Huge because in the old siloed days, the front end 103 00:04:51.319 --> 00:04:54.240 developer builds the dark mode toggle, throws it over the wall, 104 00:04:54.439 --> 00:04:55.720 and goes home for the weekend. 105 00:04:55.959 --> 00:04:58.959 And if that toggle causes the entire payment gateway to 106 00:04:59.000 --> 00:05:01.759 crash on a Friday night, it's the operations team that 107 00:05:01.800 --> 00:05:03.399 gets the panic phone calls at two in. 108 00:05:03.399 --> 00:05:06.519 The morning, which is so unfair. But DevOps changes that 109 00:05:06.600 --> 00:05:09.560 dynamic entirely. The rule is basically, if you build it, 110 00:05:09.639 --> 00:05:10.160 you run it. 111 00:05:10.480 --> 00:05:13.800 Yes, if you build it, you maintain it until it's 112 00:05:13.879 --> 00:05:14.600 end of life. 113 00:05:14.680 --> 00:05:18.240 That drastically changes how carefully someone writes code, doesn't it 114 00:05:18.560 --> 00:05:20.079 Knowing you are the one who has to wake up 115 00:05:20.120 --> 00:05:22.639 at two am to fix a memory leak you created 116 00:05:22.959 --> 00:05:25.000 adds a whole new level of accountability. 117 00:05:25.319 --> 00:05:29.319 It forces a cultural shift toward higher quality naturally, but 118 00:05:29.439 --> 00:05:32.600 to make that work, you have to adopt the fourth principle, 119 00:05:32.959 --> 00:05:35.439 which is cross functional autonomous. 120 00:05:34.920 --> 00:05:37.600 Teams, right moving away from the specialists exactly. 121 00:05:37.600 --> 00:05:39.519 You have to move away from the hyper specialized IT 122 00:05:39.839 --> 00:05:44.360 culture where you have like one database person, one security person, 123 00:05:44.439 --> 00:05:48.160 and one front end person. DevOps requires what the industry 124 00:05:48.160 --> 00:05:49.920 calls T shaped profiles. 125 00:05:50.000 --> 00:05:53.120 T shaped profiles. I love that visual. The vertical stem 126 00:05:53.160 --> 00:05:55.800 of the T represents your deep expertise in one area, 127 00:05:55.879 --> 00:05:57.360 right like maybe writing front end. 128 00:05:57.240 --> 00:05:58.959 Code, Yes, your core competency. 129 00:05:59.120 --> 00:06:02.079 But then the horizon unkle bar represents a broad baseline 130 00:06:02.079 --> 00:06:04.800 of skills across other disciplines, so that front end developer 131 00:06:04.839 --> 00:06:09.800 also needs to understand the basics of database indexing, automated testing, 132 00:06:09.879 --> 00:06:11.759 and server administration, which. 133 00:06:11.560 --> 00:06:15.480 Means the team can function independently. They aren't constantly waiting 134 00:06:15.519 --> 00:06:18.079 on external specialists to unblock them. 135 00:06:18.199 --> 00:06:20.639 They can just handle the entire life cycle of that 136 00:06:20.839 --> 00:06:22.000 dark mode feature. 137 00:06:21.720 --> 00:06:25.360 Themselves exactly, which brings us to the final two principles, 138 00:06:26.000 --> 00:06:29.079 continuous improvement and automating everything. 139 00:06:29.360 --> 00:06:31.839 Yeah, I noticed the book places a massive emphasis on 140 00:06:32.040 --> 00:06:37.800 eradicating waste through automation, specifically they highlight infrastructure as code 141 00:06:38.199 --> 00:06:38.959 or IAC. 142 00:06:39.160 --> 00:06:42.439 Infrastructure's code is basically the silver bullet for one of 143 00:06:42.480 --> 00:06:44.560 the most persistent headaches in software. 144 00:06:44.160 --> 00:06:46.319 Development, the snowflake environment. 145 00:06:45.959 --> 00:06:50.560 The dreaded snowflake environment. Without IAC, teams can figure their 146 00:06:50.600 --> 00:06:54.720 deployment servers manually over time. An administrator might tweak a 147 00:06:54.800 --> 00:06:58.319 registry key here or updata specific library there just to 148 00:06:58.319 --> 00:06:59.120 get something working. 149 00:06:59.240 --> 00:07:01.319 Just putting bandew right and. 150 00:07:01.319 --> 00:07:04.720 Fast forward a year. That server is a snowflake. It's 151 00:07:04.759 --> 00:07:08.920 a completely unique, manually configured setup that is virtually impossible 152 00:07:08.959 --> 00:07:09.600 to reproduce. 153 00:07:09.800 --> 00:07:11.959 So when you try to deploy new software into it, 154 00:07:11.959 --> 00:07:16.800 it inevitably crashes because it expects some undocumented, forgotten tweak exactly. 155 00:07:16.959 --> 00:07:19.560 But I know you had some thoughts on automating everything. 156 00:07:19.639 --> 00:07:21.319 I do. Yeah, I have to push back on this 157 00:07:21.319 --> 00:07:25.240 a little bit. Automating everything sounds incredibly efficient on paper, sure, 158 00:07:25.920 --> 00:07:29.480 But if we completely remove the human element from that 159 00:07:29.600 --> 00:07:33.160 final button press, if we just let code provision servers 160 00:07:33.199 --> 00:07:37.160 and deploy software automatically, aren't teams flying completely blind. 161 00:07:37.279 --> 00:07:38.399 That's a very common fear. 162 00:07:38.560 --> 00:07:42.040 I mean, what happens when a sudden, unexpected error occurs 163 00:07:42.040 --> 00:07:44.560 in the wild. Doesn't the human element act as a 164 00:07:44.560 --> 00:07:45.319 safety net. 165 00:07:45.439 --> 00:07:49.959 It's a natural concern, but automated configuration management actually enforces 166 00:07:50.000 --> 00:07:54.199 safety rather than removing it. Tools like Azure Automation, or 167 00:07:54.240 --> 00:07:57.600 even third party integrations like Chef and Puppet. They don't 168 00:07:57.639 --> 00:07:59.040 just mindlessly push code. 169 00:07:59.079 --> 00:07:59.879 Okay, so what do they do? 170 00:08:00.319 --> 00:08:03.639 They operate on a principle of desired state enforcement. You 171 00:08:03.680 --> 00:08:06.800 write a text file that says, this server must always 172 00:08:06.800 --> 00:08:10.319 have precisely these three ports, open and run this exact 173 00:08:10.439 --> 00:08:11.639 version of this software. 174 00:08:11.720 --> 00:08:14.480 Oh I see, So it's constantly checking the reality against 175 00:08:14.519 --> 00:08:15.720 the blueprint. 176 00:08:15.399 --> 00:08:19.519 Constantly, like every few minutes. If a human accidentally logs 177 00:08:19.519 --> 00:08:22.399 in and changes a setting, or if a malicious actor 178 00:08:22.439 --> 00:08:26.000 tries to alter the environment, the automated tooling detects that 179 00:08:26.079 --> 00:08:29.319 the server has drifted from its desired state. 180 00:08:29.360 --> 00:08:30.800 And it just fixes it. 181 00:08:30.800 --> 00:08:34.159 It instantly overwrites the change to correct it. It resolves 182 00:08:34.240 --> 00:08:39.240 unexpected variations far faster and more consistently than a human. Ever. 183 00:08:39.240 --> 00:08:43.200 Could it really eliminates the variability of human error entirely? 184 00:08:43.399 --> 00:08:46.759 Okay? Wow, that is a brilliant mechanism. It actually makes 185 00:08:46.799 --> 00:08:50.919 it safer, much safer. So having laid that philosophical groundwork, 186 00:08:50.960 --> 00:08:54.000 let's move from the abstract principles to the tangible tools. 187 00:08:54.320 --> 00:08:56.879 We're talking about the Microsoft as your devop. 188 00:08:56.600 --> 00:08:58.519 Suite, the actual tool belt. Right. 189 00:08:58.559 --> 00:09:02.960 The text outlines four phase of the app life cycle plan, develop, deliver, 190 00:09:03.080 --> 00:09:04.039 and operate. 191 00:09:03.840 --> 00:09:06.519 And the suite is designed to map directly to those phases. 192 00:09:06.879 --> 00:09:09.639 For planning, you have Azure boards. For developing, you have 193 00:09:09.720 --> 00:09:11.480 Azure repos handling source control. 194 00:09:11.639 --> 00:09:13.919 And the text points at a critical distinction here with 195 00:09:14.039 --> 00:09:17.519 repos right, Azure supports both GET and Team Foundation Version 196 00:09:17.519 --> 00:09:19.879 Control or TFC. 197 00:09:19.320 --> 00:09:20.879 Yes, and the distance is architectural. 198 00:09:21.159 --> 00:09:24.840 I found that comparison really interesting because Git is a 199 00:09:24.879 --> 00:09:29.600 distributed system. Every single developer has a complete local copy 200 00:09:29.639 --> 00:09:31.559 of the repository right on their. 201 00:09:31.440 --> 00:09:35.240 Machine, the entire history, all the branches, everything right, so. 202 00:09:35.159 --> 00:09:39.120 They can commit changes offline, experiment locally, and only sync 203 00:09:39.200 --> 00:09:41.480 with the main project when they are totally ready. 204 00:09:41.519 --> 00:09:46.320 Whereas TFC is centralized, the developers only have the current 205 00:09:46.399 --> 00:09:49.759 working version on their local machine, all the historical data, 206 00:09:50.080 --> 00:09:53.519 the branching, and the merging that is all maintained purely 207 00:09:53.559 --> 00:09:54.360 on the central server. 208 00:09:54.639 --> 00:09:56.360 Is anyone still using TFFC. 209 00:09:56.720 --> 00:09:59.919 Modern teams overwhelmingly default to GET for its speed and flexible, 210 00:10:01.279 --> 00:10:04.240 but TFPC is still supported for legacy enterprise environments. 211 00:10:04.759 --> 00:10:06.360 The big older companies. 212 00:10:05.919 --> 00:10:09.679 Right, organizations that require strict centralized audit controls over every 213 00:10:09.679 --> 00:10:11.960 single code change often still rely. 214 00:10:11.879 --> 00:10:13.799 On it makes sense, so once the code is in 215 00:10:13.840 --> 00:10:17.200 the repository, we move to the delivery phase. With Azure pipelines, 216 00:10:17.519 --> 00:10:21.480 this is the CICD engine, continuous integration and continuous delivery. 217 00:10:21.559 --> 00:10:23.559 This is the real heartbeat of DevOps. 218 00:10:23.799 --> 00:10:26.000 Let's look at the actual mechanics here, the nuts and 219 00:10:26.039 --> 00:10:29.159 bolts of it all. When a developer finishes coding that 220 00:10:29.279 --> 00:10:32.360 dark mode feature we talked about for tail intraders, they 221 00:10:32.399 --> 00:10:35.679 don't just like email a ZIP file to a manager, 222 00:10:35.799 --> 00:10:36.320 definitely not. 223 00:10:36.639 --> 00:10:39.240 They hit commit in Azure. 224 00:10:38.879 --> 00:10:42.399 Reposts, and that commit acts as a digital tripwire. Right 225 00:10:42.440 --> 00:10:46.000 a human doesn't review it to trigger the next step exactly. 226 00:10:45.879 --> 00:10:50.360 The repository sends an automated webhook to Azure pipelines. Pipelines 227 00:10:50.399 --> 00:10:54.080 instantly wakes up, reads a configuration file, and spins up 228 00:10:54.120 --> 00:10:57.240 a pristine, temporary virtual machine. 229 00:10:56.879 --> 00:10:59.480 A brand new environment every time. 230 00:10:59.279 --> 00:11:02.320 Every single time, it injects the new dark mode code 231 00:11:02.399 --> 00:11:05.320 into a copy of the tailin traders app, compiles it 232 00:11:05.559 --> 00:11:09.120 and runs perhaps thousands of automated security and functional tests 233 00:11:09.159 --> 00:11:10.679 in a matter of seconds. 234 00:11:10.320 --> 00:11:12.399 And if even one test fails. 235 00:11:12.200 --> 00:11:15.679 The pipeline halts. It destroys the virtual machine and alerts 236 00:11:15.720 --> 00:11:17.919 the developer exactly which line of code broke. 237 00:11:18.000 --> 00:11:18.960 But if it passes. 238 00:11:19.159 --> 00:11:22.440 If it passes, the pipeline automatically packages it and deployed 239 00:11:22.480 --> 00:11:23.759 it to the live production server. 240 00:11:23.919 --> 00:11:24.919 It's totally seamless. 241 00:11:25.200 --> 00:11:28.360 Add in Azure test plans for the manual exploratory testing 242 00:11:28.440 --> 00:11:32.799 by stakeholders and Azure artifacts for sharing packaged code dependencies 243 00:11:32.799 --> 00:11:35.679 across different teams, and you have the full life cycle. 244 00:11:35.759 --> 00:11:40.039 And the text also mentions these cool extensions like ARM outputs, 245 00:11:40.080 --> 00:11:44.159 which uses Azure Resource Manager to dynamically read those infrastructure 246 00:11:44.200 --> 00:11:44.879 blueprints we. 247 00:11:44.840 --> 00:11:47.519 Talked about, yes, the IIC files right. 248 00:11:48.000 --> 00:11:51.720 And team project health which gives visual cues right on 249 00:11:51.759 --> 00:11:54.919 the dashboard. All these tools are just highly interconnected. 250 00:11:55.080 --> 00:11:58.720 They feed data into one another continuously. That's a closed loop. 251 00:11:59.000 --> 00:12:02.080 Here's where it gets really interesting listening to the mechanics 252 00:12:02.080 --> 00:12:06.120 of these tools triggering one another. It's honestly like operating 253 00:12:06.159 --> 00:12:08.960 a high end futuristic restaurant kitchen. 254 00:12:09.159 --> 00:12:10.480 Okay, I like where this is going. 255 00:12:10.559 --> 00:12:13.200 Think about it. Azure Boards is the order ticket rail 256 00:12:13.360 --> 00:12:16.000 telling the kitchen staff exactly what needs to be cooked. 257 00:12:16.480 --> 00:12:18.879 As your repos is the pantry holding all the raw 258 00:12:19.000 --> 00:12:22.240 ingredients and the history of every recipe ever created. As 259 00:12:22.279 --> 00:12:26.240 your pipelines is the automated cooking conveyor belt that perfectly 260 00:12:26.279 --> 00:12:29.320 times the preparation and tests the temperature of the meat. 261 00:12:29.799 --> 00:12:32.600 Test plans are the head chefs doing the final taste 262 00:12:32.639 --> 00:12:33.879 testing before the dish. 263 00:12:33.720 --> 00:12:35.720 Leaves the kitchen and Azure artifacts. 264 00:12:35.840 --> 00:12:38.279 Those are the signature sauces you bottle up and share 265 00:12:38.320 --> 00:12:40.600 with other restaurant branches so they don't have to reinvent 266 00:12:40.639 --> 00:12:41.279 the recipe. 267 00:12:41.399 --> 00:12:44.240 That is a highly accurate way to map the ecosystem, 268 00:12:44.360 --> 00:12:46.720 Honestly it is. And the most vital part of that 269 00:12:46.840 --> 00:12:50.840 kitchen analogy is the automated feedback loop. How soon, well, 270 00:12:50.919 --> 00:12:53.480 if the head chefs using test plans discover the soup 271 00:12:53.519 --> 00:12:55.679 is too salty, they don't just throw it away and 272 00:12:55.759 --> 00:12:59.000 yell at the cooks. That feedback loop instantly goes back 273 00:12:59.039 --> 00:13:02.440 to the pantry Azure repos to log the air, adjust 274 00:13:02.440 --> 00:13:05.679 the recipe blueprint, and trigger the pipeline's conveyor built to 275 00:13:05.679 --> 00:13:08.399 cook a new, corrected badge for the very next bowl 276 00:13:08.600 --> 00:13:11.679 exactly and all without the restaurant ever closing its doors 277 00:13:11.679 --> 00:13:12.200 to the public. 278 00:13:12.279 --> 00:13:15.759 It's an incredible system. But to really give you the learner, 279 00:13:15.840 --> 00:13:18.960 a practical understanding of how a team actually starts their 280 00:13:19.039 --> 00:13:22.440 day in this environment, we need to zoom in tightly 281 00:13:22.519 --> 00:13:24.480 on chapter two's focus. 282 00:13:24.039 --> 00:13:25.960 Which is Azure boards, right. 283 00:13:25.840 --> 00:13:27.960 Because before you can automate the kitchen, you have to 284 00:13:28.039 --> 00:13:29.039 organize the chaos. 285 00:13:29.080 --> 00:13:32.679 You absolutely do the very first thing a team must 286 00:13:32.720 --> 00:13:36.039 do when creating a project in Azure DevOps is choose 287 00:13:36.080 --> 00:13:37.039 a process template. 288 00:13:37.480 --> 00:13:39.679 And this isn't just a minor setting, No, this. 289 00:13:39.679 --> 00:13:44.000 Decision dictates the entire organizational vocabulary and hierarchy of your 290 00:13:44.000 --> 00:13:47.480 work tracking system. Azure provides four main options out of 291 00:13:47.480 --> 00:13:51.279 the box, Basic, Agile, Scrum, and CMMI. 292 00:13:51.679 --> 00:13:54.159 Basic is well exactly what it sounds like. It tracks 293 00:13:54.159 --> 00:13:58.320 simple epics, issues and tasks. Agile, which is actually what 294 00:13:58.399 --> 00:14:02.440 the tail in traders sandbox project defaults to, tracks features 295 00:14:02.600 --> 00:14:03.919 user stories and tasks. 296 00:14:04.200 --> 00:14:08.559 Scrum uses slightly different terminology, focusing on product backlog items 297 00:14:08.600 --> 00:14:11.399 and bugs to align strictly with the Scrum methodology. 298 00:14:11.399 --> 00:14:13.879 And then there's CMMI, which is a whole other beast. 299 00:14:14.000 --> 00:14:17.759 CMMI stands for capability, maturity, model integration. It is a 300 00:14:17.879 --> 00:14:22.080 highly formal, incredibly rigorous template. Not just user stories then No, 301 00:14:22.200 --> 00:14:25.720 Instead of just tracking user stories, attracts detailed requirements, mandatory 302 00:14:25.759 --> 00:14:28.360 change requests, risk assessments, and formal reviews. 303 00:14:28.519 --> 00:14:35.279 Which raises a really practical question. With so many templates available, Agile, Scrum, Basic, 304 00:14:35.759 --> 00:14:39.320 the super formal CMMI, how does a team know which 305 00:14:39.320 --> 00:14:41.679 one to pick without getting totally bogged down in like 306 00:14:42.080 --> 00:14:44.159 process for the sake of process. 307 00:14:43.759 --> 00:14:45.960 Right, why wouldn't everyone just pick basic and move as 308 00:14:46.000 --> 00:14:46.879 fast as possible? 309 00:14:47.000 --> 00:14:47.559 Exactly? 310 00:14:47.720 --> 00:14:51.720 What's fascinating here is that Azure boards forces teams to 311 00:14:51.879 --> 00:14:56.080 deliberately choose their level of bureaucracy right up front. It 312 00:14:56.159 --> 00:14:59.399 forces a conversation about regulatory. 313 00:14:58.720 --> 00:15:00.440 Reality, ragilatory reality. 314 00:15:00.440 --> 00:15:03.279 Give me an example. Sure, a small, fast moving startup 315 00:15:03.600 --> 00:15:06.879 building a social media app will likely choose basic or agile. 316 00:15:07.200 --> 00:15:09.720 Their primary risk is moving too slowly. They just need 317 00:15:09.759 --> 00:15:11.279 to track features and fixed bugs. 318 00:15:11.559 --> 00:15:14.720 But consider a major bank, right, or a healthcare company 319 00:15:14.799 --> 00:15:17.039 developing software that manages patient records. 320 00:15:17.080 --> 00:15:19.120 Exactly. They can't just move fast and break things. 321 00:15:19.159 --> 00:15:19.879 No, absolutely not. 322 00:15:20.159 --> 00:15:23.159 They must use CMMI. When a developer at a bank 323 00:15:23.320 --> 00:15:26.799 changes how an interest rate is calculated. Regulators require an 324 00:15:26.840 --> 00:15:30.639 auditable paper trail to prove what happened right, proving that 325 00:15:30.679 --> 00:15:34.039 a risk assessment was performed, that a formal change request 326 00:15:34.080 --> 00:15:37.519 was filed, and that multiple stakeholders signed off on the 327 00:15:37.559 --> 00:15:42.440 exact line of code. CMMI bakes that compliance directly into 328 00:15:42.440 --> 00:15:43.399 the daily workflow. 329 00:15:43.639 --> 00:15:47.600 It's about matching the digital tool directly to the organizational 330 00:15:47.639 --> 00:15:51.279 reality precisely. Let's look at the mechanics of the agile templates, 331 00:15:51.240 --> 00:15:54.320 since that's what so many modern teams use. The core 332 00:15:54.440 --> 00:15:57.000 unit of work is the work item. The text gives 333 00:15:57.039 --> 00:15:59.919 a great example of creating a user story. As a user, 334 00:16:00.200 --> 00:16:01.720 I want to edit my user profile. 335 00:16:02.039 --> 00:16:05.919 But in Azure Boards, this isn't just a digital sticky note. 336 00:16:05.720 --> 00:16:08.120 Far from it. The anatomy of that work item is 337 00:16:08.240 --> 00:16:09.360 incredibly deep. 338 00:16:09.519 --> 00:16:11.759 It functions as the single source of truth for that 339 00:16:11.840 --> 00:16:15.759 specific feature. You can add searchable tags like profile improvements, 340 00:16:16.080 --> 00:16:19.360 you track its state moving from new to active to closed. 341 00:16:19.080 --> 00:16:21.879 And it has its own internal social network for discussion, 342 00:16:21.879 --> 00:16:22.960 which I thought was really cool. 343 00:16:23.039 --> 00:16:23.799 It's very useful. 344 00:16:23.879 --> 00:16:26.440 You can just type the at at symbol to mention 345 00:16:26.519 --> 00:16:29.919 specific developers to ask a question or use the hashtag 346 00:16:29.960 --> 00:16:32.759 symbol to link the conversation directly to a specific pull 347 00:16:32.799 --> 00:16:34.240 request in the code repository. 348 00:16:34.480 --> 00:16:37.000 It keeps all the context attached to the work itself, 349 00:16:37.519 --> 00:16:40.039 rather than buried in some separate email chain or chat 350 00:16:40.080 --> 00:16:41.240 app where it gets lost. 351 00:16:41.440 --> 00:16:45.840 And crucially, the team assigns story points to the work item. 352 00:16:46.200 --> 00:16:49.919 Yes, and we should clarify this isn't a measurement of hours. 353 00:16:49.919 --> 00:16:53.519 Right, It's a numeric value that estimates the abstract complexity 354 00:16:53.559 --> 00:16:57.159 and effort required to build the feature over time. By 355 00:16:57.200 --> 00:16:59.840 tracking how many story points the team successfully completes in 356 00:16:59.879 --> 00:17:04.000 a two week sprint, the software calculates the team's velocity. 357 00:17:03.679 --> 00:17:08.240 Which gives project managers highly accurate, data driven forecasting for 358 00:17:08.359 --> 00:17:11.720 when future features will actually be delivered, rather than just guessing. 359 00:17:12.079 --> 00:17:14.400 All of these work items live in the backlog, which 360 00:17:14.440 --> 00:17:17.960 acts as the master roadmap. Project managers can literally drag 361 00:17:18.000 --> 00:17:20.400 and drop items up and down the list to instantly 362 00:17:20.440 --> 00:17:23.279 reprioritize what the team should focus on next. 363 00:17:23.240 --> 00:17:26.680 And from that backlog items are pulled onto the canbin board. 364 00:17:26.839 --> 00:17:28.200 That's the visual part, right. 365 00:17:28.519 --> 00:17:32.880 This provides the visual flow of the work through columns new, active, resolved, 366 00:17:33.000 --> 00:17:33.599 and closed. 367 00:17:33.920 --> 00:17:37.119 New is work prioritized but not yet started. Obviously, active 368 00:17:37.240 --> 00:17:38.799 is the code the team is writing right now. 369 00:17:39.000 --> 00:17:43.039 Resolved means the developer believes the code is done, but 370 00:17:43.119 --> 00:17:46.920 it's sitting in the testing phase, and closed means it 371 00:17:46.960 --> 00:17:50.119 has fully met the team's definition of done and is 372 00:17:50.160 --> 00:17:51.599 out there in the customer's hands. 373 00:17:51.720 --> 00:17:55.200 The text mentions that teams use a specific sprint taskboard 374 00:17:55.279 --> 00:17:58.079 view during their daily stand up meetings. They look at 375 00:17:58.079 --> 00:18:01.720 the active column, discuss what's in progress, and immediately flag 376 00:18:01.759 --> 00:18:02.720 any roadblocks. 377 00:18:03.240 --> 00:18:06.640 And when you are dealing with enterprise software, you might 378 00:18:06.720 --> 00:18:09.759 have thousands of these items floating around. 379 00:18:09.480 --> 00:18:14.440 Which sounds overwhelming, but Azur DevOps solves that noise with queries. 380 00:18:14.640 --> 00:18:17.599 Right, Yes, queries are essential. You can build a custom 381 00:18:17.680 --> 00:18:19.480 query to filter the database, for. 382 00:18:19.400 --> 00:18:22.759 Example, showing only the work items assigned to you, tagged 383 00:18:22.759 --> 00:18:25.920 with profile improvements that are currently stuck in the resolved state. 384 00:18:26.039 --> 00:18:28.480 It cuts through the overwhelming scale of the project to 385 00:18:28.519 --> 00:18:31.640 show you exactly what needs your attention today. It basically 386 00:18:31.720 --> 00:18:33.640 prevents anything from falling through the cracks. 387 00:18:33.720 --> 00:18:36.720 So to pull all these threads together. What we've learned 388 00:18:36.759 --> 00:18:38.960 from az your DevOps explained is that this isn't just 389 00:18:39.079 --> 00:18:41.680 a fancy suite of software tool not at all as 390 00:18:41.720 --> 00:18:45.440 your DevOps is the digital manifestation of a massive cultural shift. 391 00:18:45.799 --> 00:18:49.720 It takes these high minded principles, shared end to end responsibility, 392 00:18:50.039 --> 00:18:55.680 dismantling isolated silos, automating manual waste, and it provides a literal, 393 00:18:56.119 --> 00:18:59.759 tangible dashboard to ensure a team actually practices what they 394 00:19:00.000 --> 00:19:00.920 reach from. 395 00:19:00.720 --> 00:19:04.440 The Azure boards, keeping the human element aligned to repose, 396 00:19:04.519 --> 00:19:08.720 securing the code history to pipelines, executing the automated delivery 397 00:19:08.759 --> 00:19:09.359 trip wires. 398 00:19:09.599 --> 00:19:13.319 The platform essentially forces best practices into the muscle memory 399 00:19:13.359 --> 00:19:14.160 of the organization. 400 00:19:14.599 --> 00:19:16.599 That's a great way to put it. A company can't 401 00:19:16.599 --> 00:19:20.000