WEBVTT 00:00:00.000 --> 00:00:04.540 Imagine you're building a skyscraper. OK, a skyscraper. 00:00:04.660 --> 00:00:06.900 Right. And you wouldn't just hire 50 different 00:00:06.900 --> 00:00:09.900 construction crews, send them to secret, isolated 00:00:09.900 --> 00:00:12.359 locations all over the city, and have them pour 00:00:12.359 --> 00:00:15.789 concrete and weld steel. completely on their 00:00:15.789 --> 00:00:19.370 own. No, obviously not. That would be completely 00:00:19.370 --> 00:00:21.789 chaotic. Right. And then imagine trying to just, 00:00:21.789 --> 00:00:24.649 like, assemble the entire structure the day before 00:00:24.649 --> 00:00:26.469 the grand opening. Yeah, the plumbing definitely 00:00:26.469 --> 00:00:28.609 wouldn't line up. Exactly. The load -bearing 00:00:28.609 --> 00:00:30.070 walls would clash, and the whole thing would 00:00:30.070 --> 00:00:33.009 just collapse under its own weight. But the crazy 00:00:33.009 --> 00:00:36.450 thing is, for decades, that chaotic final day 00:00:36.450 --> 00:00:39.689 assembly is basically exactly how the tech industry 00:00:39.689 --> 00:00:42.950 built massively complex software. It really was. 00:00:43.149 --> 00:00:45.250 Which is terrifying to think about now. It is. 00:00:45.509 --> 00:00:47.850 So welcome to the deep dive. Today we're looking 00:00:47.850 --> 00:00:49.890 at something that honestly you probably rely 00:00:49.890 --> 00:00:52.159 on every single day without realizing it. Our 00:00:52.159 --> 00:00:54.380 mission today is to decode the invisible engine 00:00:54.380 --> 00:00:56.820 that prevents the modern digital world from constantly 00:00:56.820 --> 00:00:58.439 falling apart. We're talking about continuous 00:00:58.439 --> 00:01:02.399 integration or CI. Which, you know, on the surface, 00:01:02.439 --> 00:01:05.260 that sounds like a super dry, purely administrative 00:01:05.260 --> 00:01:07.859 back -end process, like just a way developers 00:01:07.859 --> 00:01:09.799 manage their files. Yeah, it sounds like digital 00:01:09.799 --> 00:01:12.420 paperwork. Exactly. But when you look at the 00:01:12.420 --> 00:01:14.879 mechanics of what CI actually does, you realize 00:01:14.879 --> 00:01:17.579 it's this radical shift in how humans collaborate. 00:01:17.920 --> 00:01:20.620 It completely changed how we manage risk when 00:01:20.620 --> 00:01:23.560 solving shared intellectual puzzles. Okay, let's 00:01:23.560 --> 00:01:25.819 unpack this, because you don't have to be a software 00:01:25.819 --> 00:01:29.140 engineer to appreciate this. Understanding CI 00:01:29.140 --> 00:01:31.560 is really the ultimate cheat code for understanding 00:01:31.560 --> 00:01:35.379 how modern teams build complex things. Basically, 00:01:35.459 --> 00:01:37.540 CI is the practice where developers frequently 00:01:37.540 --> 00:01:40.560 merge their code changes into a shared integration 00:01:40.560 --> 00:01:42.989 branch. And they do this to ensure the whole 00:01:42.989 --> 00:01:45.209 system is always in a workable state. Right, 00:01:45.230 --> 00:01:48.510 the key word there being frequently. But to really 00:01:48.510 --> 00:01:50.810 appreciate how revolutionary that is, we have 00:01:50.810 --> 00:01:53.390 to look back at when and why it started. Because 00:01:53.390 --> 00:01:55.230 it didn't just appear out of nowhere. No, it 00:01:55.230 --> 00:01:57.510 came out of necessity. So let's look at the timeline. 00:01:57.890 --> 00:02:00.349 Back in 1989, there were these researchers, Kaiser, 00:02:00.629 --> 00:02:02.950 Perry, and Shell. And they developed an environment 00:02:02.950 --> 00:02:05.930 called Infuse. Which was sort of the earliest 00:02:05.930 --> 00:02:08.610 academic seed for systematically integrating 00:02:08.610 --> 00:02:12.430 code. Yeah. But the actual term continuous integration 00:02:12.430 --> 00:02:15.750 wasn't coined until 1991 by a software engineer 00:02:15.750 --> 00:02:18.949 named Grady Bouch. Although, and this is a big 00:02:18.949 --> 00:02:22.020 caveat, Butch wasn't advocating for the multiple 00:02:22.020 --> 00:02:24.719 times a day integration that we see now. He couldn't. 00:02:24.840 --> 00:02:27.159 The hardware limitations of the early 90s just 00:02:27.159 --> 00:02:29.879 made daily integration physically impossible. 00:02:30.060 --> 00:02:31.879 Right. Because the computers were just too slow. 00:02:32.199 --> 00:02:35.319 Exactly. We're talking about an era where compiling 00:02:35.319 --> 00:02:39.560 a large C++ code base meant mapping thousands 00:02:39.560 --> 00:02:42.240 of dependencies using single core processors. 00:02:42.639 --> 00:02:45.659 And you know. highly limited RAM. So just moving 00:02:45.659 --> 00:02:48.520 data around took forever. Yeah, moving data in 00:02:48.520 --> 00:02:50.699 and out of those slow hard drives meant a full 00:02:50.699 --> 00:02:53.099 system build could take hours. Sometimes it would 00:02:53.099 --> 00:02:54.939 drag on for an entire weekend. You simply couldn't 00:02:54.939 --> 00:02:57.120 run a continuous pipeline because the infrastructure 00:02:57.120 --> 00:02:59.460 would just choke. Wow. Okay, so the methodology 00:02:59.460 --> 00:03:01.919 was totally bottlenecked by the silicon. But 00:03:01.919 --> 00:03:04.960 then we hit 1997 and the landscape really starts 00:03:04.960 --> 00:03:07.039 to shift. It does. This is when Kent Beck and 00:03:07.039 --> 00:03:09.719 Ron Jeffries are brought in to rescue this notoriously 00:03:09.719 --> 00:03:12.979 complex project, the Chrysler Comprehensive Com 00:03:12.979 --> 00:03:15.370 - compensation system, basically a massive payroll 00:03:15.370 --> 00:03:19.030 system. And payroll systems are absolute monsters 00:03:19.030 --> 00:03:22.530 of logic. There are so many edge cases and tax 00:03:22.530 --> 00:03:25.349 rules. Totally. So to tame this beast, they invent 00:03:25.349 --> 00:03:27.669 a methodology called extreme programming, or 00:03:27.669 --> 00:03:30.610 XP. And continuous integration is basically the 00:03:30.610 --> 00:03:33.180 structural backbone of XP. What's fascinating 00:03:33.180 --> 00:03:36.639 here is the behavioral shift. When Beck published 00:03:36.639 --> 00:03:38.879 the Core Tenants of Extreme Programming a year 00:03:38.879 --> 00:03:41.840 later, he wasn't fixated on processor speeds 00:03:41.840 --> 00:03:44.080 or server architecture. Oh, really? What was 00:03:44.080 --> 00:03:46.939 the focus? He emphasized face -to -face communication. 00:03:47.520 --> 00:03:50.460 He focused on tight feedback loops. CI wasn't 00:03:50.460 --> 00:03:52.580 born from better servers. It was born from a 00:03:52.580 --> 00:03:55.500 need for better human teamwork. Teams were failing 00:03:55.500 --> 00:03:57.919 because the longer developers worked in isolation, 00:03:58.240 --> 00:04:00.139 the further their mental models of the software 00:04:00.139 --> 00:04:02.699 drifted apart. Ah, OK. So why did they feel the 00:04:02.699 --> 00:04:04.400 need to invent this? Like, what were they running 00:04:04.400 --> 00:04:06.800 away from? Let's talk about the friction of concurrent 00:04:06.800 --> 00:04:09.379 development. Yeah, the classic problem. Right. 00:04:09.560 --> 00:04:12.039 So imagine a college group project. You've got 00:04:12.039 --> 00:04:14.780 four people. They divide up the work, and they 00:04:14.780 --> 00:04:16.879 write their own chapters for a month without 00:04:16.879 --> 00:04:19.259 talking to each other. A recipe for disaster. 00:04:19.620 --> 00:04:21.939 Exactly. Yeah. And then they try to staple it 00:04:21.939 --> 00:04:24.730 all together the night before it's due. In software, 00:04:25.069 --> 00:04:28.149 this is literally called merge hell or integration 00:04:28.149 --> 00:04:31.069 hell. It's a very accurate name. Let's look at 00:04:31.069 --> 00:04:33.610 the actual mechanics of how that divergence happens. 00:04:33.970 --> 00:04:36.949 Say you have a developer. and they copy the current 00:04:36.949 --> 00:04:40.310 code base to their local machine. OK. An exact 00:04:40.310 --> 00:04:42.769 snapshot of that moment. Right. But the moment 00:04:42.769 --> 00:04:45.149 they do that, an invisible clock starts ticking. 00:04:45.670 --> 00:04:48.370 Because as time passes, other developers are 00:04:48.370 --> 00:04:50.569 adding and changing code on the main branch. 00:04:50.930 --> 00:04:54.129 So this local copy starts to diverge from reality. 00:04:54.430 --> 00:04:56.490 So the foundation is basically shifting underneath 00:04:56.490 --> 00:04:58.490 them while they work. Exactly. And the longer 00:04:58.490 --> 00:05:00.790 they wait to merge their work back into the main 00:05:00.790 --> 00:05:04.029 branch, the higher the risk of massive catastrophic 00:05:04.029 --> 00:05:06.170 conflicts. Because the code they're interacting 00:05:06.170 --> 00:05:08.730 with might not even exist anymore, or it works 00:05:08.730 --> 00:05:11.350 completely differently. Yes. And eventually, 00:05:11.750 --> 00:05:13.769 untangling those conflicts and integrating the 00:05:13.769 --> 00:05:17.449 code takes more time and mental energy than writing 00:05:17.449 --> 00:05:19.810 the feature in the first place. That sounds miserable. 00:05:20.370 --> 00:05:23.269 So the only way to beat merge hell is to just 00:05:23.269 --> 00:05:25.410 never let the code diverge too far in the first 00:05:25.410 --> 00:05:27.490 place. That's the core realization. Which leads 00:05:27.490 --> 00:05:30.259 to the golden rule. come it frequently, like 00:05:30.259 --> 00:05:33.160 at least once a day. Right. You take that massive, 00:05:33.420 --> 00:05:35.519 high -risk integration phase that used to happen 00:05:35.519 --> 00:05:38.500 at the very end, and you shatter it into tiny, 00:05:38.819 --> 00:05:42.000 manageable, daily microintegrations. But OK, 00:05:42.079 --> 00:05:44.560 here's where it gets really interesting. Just 00:05:44.560 --> 00:05:47.439 telling a team of engineers to merge every day 00:05:47.439 --> 00:05:50.240 sounds like total chaos unless there are strict 00:05:50.240 --> 00:05:52.439 ground rules. Oh, absolutely. You need guardrails. 00:05:52.519 --> 00:05:54.500 Well, let's talk about the rule of atomic commits. 00:05:55.100 --> 00:05:57.139 I was thinking about this like a fast food combo 00:05:57.139 --> 00:06:00.089 meal. OK. meal. Walk me through that. So when 00:06:00.089 --> 00:06:02.089 you order a combo, the restaurant doesn't process 00:06:02.089 --> 00:06:05.790 the burger, charge you, then pause, process the 00:06:05.790 --> 00:06:08.589 fries, charge you, and then eventually do the 00:06:08.589 --> 00:06:11.050 drink. Right. It's one transaction. Exactly. 00:06:11.649 --> 00:06:14.649 The version control system handles all the developer's 00:06:14.649 --> 00:06:18.550 changes as one single unbreakable unit. It's 00:06:18.550 --> 00:06:21.889 atomic. It either completely succeeds or it completely 00:06:21.889 --> 00:06:24.750 fails and rolls back. You can't leave the system 00:06:24.750 --> 00:06:27.279 in a half -finished state. That atomic integrity 00:06:27.279 --> 00:06:30.600 is the bedrock. But the engine that truly makes 00:06:30.600 --> 00:06:34.800 CI work is automation. That's another non -negotiable 00:06:34.800 --> 00:06:37.339 rule. Everything must be automated. So humans 00:06:37.339 --> 00:06:40.240 aren't manually doing the merging? No. You can't 00:06:40.240 --> 00:06:42.740 rely on a human to manually type out compilation 00:06:42.740 --> 00:06:44.819 instructions every single time someone merges 00:06:44.819 --> 00:06:47.500 a change. It's too slow and invites too much 00:06:47.500 --> 00:06:50.040 human error. So a single command has to be able 00:06:50.040 --> 00:06:52.160 to build the whole system. OK. So who issues 00:06:52.160 --> 00:06:54.949 that command? a continuous integration server. 00:06:55.290 --> 00:06:57.730 It's often called a daemon. It constantly monitors 00:06:57.730 --> 00:07:00.009 the repository. And the second a developer pushes 00:07:00.009 --> 00:07:02.430 an atomic commit, it automatically builds the 00:07:02.430 --> 00:07:04.930 system from scratch. Wow. OK, so it's like an 00:07:04.930 --> 00:07:07.089 automated referee. But it's not just building 00:07:07.089 --> 00:07:09.610 it, right? It's testing it too. Exactly. And 00:07:09.610 --> 00:07:12.069 this ties heavily into test -driven development. 00:07:12.589 --> 00:07:14.370 Developers have to ensure that their local unit 00:07:14.370 --> 00:07:16.529 tests pass before they're even allowed to commit. 00:07:16.689 --> 00:07:20.230 The safety net. Yes. And furthermore, Every single 00:07:20.230 --> 00:07:22.910 time a bug is fixed, it must come with a new 00:07:22.910 --> 00:07:25.449 automated test case. So the bug can never happen 00:07:25.449 --> 00:07:28.269 again. Right, to prevent regressions. The system 00:07:28.269 --> 00:07:31.269 builds this ever -expanding suit of armor. But 00:07:31.269 --> 00:07:32.750 wait, let me push back on that for a second. 00:07:33.029 --> 00:07:36.389 If a huge team is committing code multiple times 00:07:36.389 --> 00:07:39.519 a day... and every commit triggers a full build 00:07:39.519 --> 00:07:42.480 and thousands of tests. Doesn't that just slow 00:07:42.480 --> 00:07:44.620 everything down? Like, doesn't the server just 00:07:44.620 --> 00:07:46.959 crash under the weight of it all? That is a very 00:07:46.959 --> 00:07:49.639 real danger, which is why another core rule is 00:07:49.639 --> 00:07:53.240 keep the build fast. If the build has high latency, 00:07:53.740 --> 00:07:56.180 like if a developer is sitting in a queue for 00:07:56.180 --> 00:07:59.100 hours waiting to see if their code worked, the 00:07:59.100 --> 00:08:01.480 entire value of CI completely breaks down. Because 00:08:01.480 --> 00:08:03.000 they lose their train of thought. They've moved 00:08:03.000 --> 00:08:06.060 on. Exactly. The feedback loot has to be immediate. 00:08:06.199 --> 00:08:08.120 So how do you keep it fast with thousands of 00:08:08.120 --> 00:08:10.920 tests? Through aggressive parallelization and 00:08:10.920 --> 00:08:13.319 distributed caching, you don't run tests one 00:08:13.319 --> 00:08:16.019 by one. The daemon distributes them across a 00:08:16.019 --> 00:08:18.500 massive cluster of servers to run simultaneously. 00:08:18.779 --> 00:08:20.959 Ah, okay. That makes sense. Yeah. So what does 00:08:20.959 --> 00:08:23.040 this all mean for the developers? The benefits 00:08:23.040 --> 00:08:26.519 are massive. First off, reverting to a good state 00:08:26.519 --> 00:08:29.980 is incredibly easy. But most importantly, it 00:08:29.980 --> 00:08:32.759 gives you perfect forensics. Because the changes 00:08:32.759 --> 00:08:35.879 are so small. Yes. If the system is built after 00:08:35.879 --> 00:08:38.019 each micro change and suddenly the build breaks, 00:08:38.360 --> 00:08:39.899 you don't have to search through a month's worth 00:08:39.899 --> 00:08:42.419 of code. You know exactly which single commit 00:08:42.419 --> 00:08:45.440 caused the bug. It isolates the variable. Exactly. 00:08:45.820 --> 00:08:48.120 And psychologically, it encourages developers 00:08:48.120 --> 00:08:52.080 to write less complex, highly modular code. Because 00:08:52.080 --> 00:08:53.720 they know it's going to be tested against the 00:08:53.720 --> 00:08:56.299 main system in a few hours. OK, I have to play 00:08:56.299 --> 00:08:58.059 devil's advocate here. This sounds like a perfect 00:08:58.059 --> 00:09:00.580 utopia. What's the catch? Because there's always 00:09:00.580 --> 00:09:03.139 a catch. There are quite a few, actually. The 00:09:03.139 --> 00:09:05.220 initial setup and the ongoing maintenance of 00:09:05.220 --> 00:09:07.720 those automated tests takes massive effort. It's 00:09:07.720 --> 00:09:10.200 a huge operational tax. Because the tests keep 00:09:10.200 --> 00:09:12.740 breaking when the app changes. Exactly. And remember, 00:09:12.840 --> 00:09:15.279 the CI system is entirely blind. It doesn't know 00:09:15.279 --> 00:09:17.600 if the software is actually good or user -friendly. 00:09:18.340 --> 00:09:21.080 Its value depends 100 % on the quality of the 00:09:21.080 --> 00:09:23.440 tests humans write. Garbage in, garbage out. 00:09:23.820 --> 00:09:27.799 Just much faster. Right. And it also forces developers 00:09:27.799 --> 00:09:29.980 to constantly break their work into tiny chunks, 00:09:30.480 --> 00:09:32.559 which can be really annoying for programmers 00:09:32.559 --> 00:09:34.600 who want to just get into a flow state and build 00:09:34.600 --> 00:09:36.700 a massive feature all at once. Yeah, I can see 00:09:36.700 --> 00:09:38.710 how that would cause friction. And this raises 00:09:38.710 --> 00:09:40.990 an important question about where CI actually 00:09:40.990 --> 00:09:43.289 struggles. There's a major exception to all of 00:09:43.289 --> 00:09:45.289 this. The airplane exception. Yes, the airplane 00:09:45.289 --> 00:09:48.330 exception. For safety and mission -critical systems 00:09:48.330 --> 00:09:50.669 like the flight software on an airplane under 00:09:50.669 --> 00:09:54.850 the DO -178C standard or car brakes under ISO 00:09:54.850 --> 00:09:58.529 26262 rapid CI is incredibly difficult. Because 00:09:58.529 --> 00:10:00.789 the regulations are so strict. Exactly. You can't 00:10:00.789 --> 00:10:03.190 just deploy a quick automated patch to a jet 00:10:03.190 --> 00:10:05.649 engine while it's flying. The frameworks demand 00:10:05.649 --> 00:10:09.210 exhaustive legally documentation and human review 00:10:09.210 --> 00:10:12.570 for every line of code. That makes rapid continuous 00:10:12.570 --> 00:10:14.970 integration almost impossible to achieve. Right. 00:10:14.990 --> 00:10:16.710 You actually want the friction in those cases 00:10:16.710 --> 00:10:19.330 to slow things down. Exactly. Safety over speed. 00:10:20.090 --> 00:10:22.590 But, okay, if you aren't building an airplane, 00:10:24.070 --> 00:10:26.370 let's say you're building a modern web app, CI 00:10:26.370 --> 00:10:28.470 doesn't just stop at integrating code into a 00:10:28.470 --> 00:10:30.370 repository, right? It extends all the way to 00:10:30.370 --> 00:10:33.370 the user. It does. Because you can't just test 00:10:33.370 --> 00:10:35.649 code in a vacuum. You need to know it survives 00:10:35.649 --> 00:10:37.830 contact with the real world. But you can't test 00:10:37.830 --> 00:10:39.970 on the live servers without breaking things for 00:10:39.970 --> 00:10:42.610 actual users. Right. So you need a clone of the 00:10:42.610 --> 00:10:45.850 production environment. But exact replicas are 00:10:45.850 --> 00:10:48.389 way too cost prohibitive. You can't duplicate 00:10:48.389 --> 00:10:50.929 Amazon's entire database just for a test run. 00:10:51.070 --> 00:10:53.860 So what do they do? Teams use scalable staging 00:10:53.860 --> 00:10:56.139 environments. These are sandboxes that mimic 00:10:56.139 --> 00:10:59.580 production. But modern apps also rely on tons 00:10:59.580 --> 00:11:02.340 of third -party APIs like payment processors. 00:11:02.700 --> 00:11:06.419 You can't just fire 10 ,000 fake test transactions 00:11:06.419 --> 00:11:08.700 at Visa every day. They block you instantly. 00:11:08.899 --> 00:11:11.360 Exactly. So they use something called service 00:11:11.360 --> 00:11:13.730 virtualization. They essentially mock the third 00:11:13.730 --> 00:11:16.490 party APIs. The staging environment tricks the 00:11:16.490 --> 00:11:18.230 pipeline into thinking it's talking to Visa, 00:11:18.330 --> 00:11:20.889 and it gets a fake approved response back. Oh, 00:11:20.950 --> 00:11:23.129 wow. So it's like a perfectly simulated reality 00:11:23.129 --> 00:11:25.429 for the code. Yes. And when you perfect that 00:11:25.429 --> 00:11:27.610 simulation, you unlock the ultimate evolution 00:11:27.610 --> 00:11:30.870 of this. There was a famous 2010 article by Timothy 00:11:30.870 --> 00:11:34.169 Fitz about his company, IMVU. Right. I remember 00:11:34.169 --> 00:11:36.809 reading about this. He took CI and pushed it 00:11:36.809 --> 00:11:39.269 into continuous delivery and continuous deployment 00:11:39.269 --> 00:11:42.799 CD. Exactly. Their staging and testing pipelines 00:11:42.799 --> 00:11:46.000 were so robust that the moment a developer merged 00:11:46.000 --> 00:11:49.220 code, if it passed the automated tests, the daemon 00:11:49.220 --> 00:11:51.740 deployed it directly to live production servers. 00:11:52.019 --> 00:11:54.820 They were deploying code to production 50 times 00:11:54.820 --> 00:11:57.700 a day, which back in 2010 people thought was 00:11:57.700 --> 00:11:59.899 completely insane. They thought it was reckless. 00:12:00.169 --> 00:12:03.350 But it actually reduced the blast radius of failures 00:12:03.350 --> 00:12:06.330 compared to doing huge quarterly updates. Because 00:12:06.330 --> 00:12:08.889 the changes were so small. Right. And if we connect 00:12:08.889 --> 00:12:10.710 this to the bigger picture, this is really how 00:12:10.710 --> 00:12:13.509 the cloud era operates. Small teams can thrive 00:12:13.509 --> 00:12:16.629 with one simple pipeline, but massive organizations 00:12:16.629 --> 00:12:18.669 have to split things up. Yeah, a giant company 00:12:18.669 --> 00:12:20.710 can't just use one repository for everything. 00:12:20.850 --> 00:12:23.149 No, they have hundreds of microservices, each 00:12:23.149 --> 00:12:25.870 with their own CICD pipelines. But that creates 00:12:25.870 --> 00:12:28.690 a huge security dilemma. Administrators usually 00:12:28.690 --> 00:12:31.320 follow the principle of least privilege, you 00:12:31.320 --> 00:12:33.659 only give a system the minimum access it needs. 00:12:33.919 --> 00:12:36.259 But a CI pipeline needs permission to basically 00:12:36.259 --> 00:12:38.799 rebuild the entire infrastructure. Yeah. Exactly. 00:12:39.059 --> 00:12:42.080 It needs broad access to spin up servers and 00:12:42.080 --> 00:12:45.740 modify databases. So strict least privilege rules 00:12:45.740 --> 00:12:48.159 often break the automation. So they have to give 00:12:48.159 --> 00:12:50.460 the automation the keys to the kingdom. They 00:12:50.460 --> 00:12:53.879 do, but they rely heavily on compensating security 00:12:53.879 --> 00:12:56.240 controls to minimize the blast radius if things 00:12:56.240 --> 00:12:59.559 go wrong. They use containerization, strict network 00:12:59.559 --> 00:13:02.320 boundaries, and canary deployments. Canary deployments, 00:13:02.320 --> 00:13:04.340 that's where they only release the new code to, 00:13:04.559 --> 00:13:08.019 like 1 % of the users first. Yes. And if the 00:13:08.019 --> 00:13:10.899 automated telemetry detects an error, it instantly 00:13:10.899 --> 00:13:13.879 rolls it back before the other 99 % even notice. 00:13:14.039 --> 00:13:16.419 That is incredible. It really is an architecture 00:13:16.419 --> 00:13:18.940 built on the assumption that failure is inevitable, 00:13:19.080 --> 00:13:21.279 so recover. just has to be instant. Exactly. 00:13:21.740 --> 00:13:23.460 Well, to wrap this all up, continuous integration 00:13:23.460 --> 00:13:26.340 is ultimately about conquering the chaos of collaboration. 00:13:26.840 --> 00:13:29.019 By making changes small, atomic, and heavily 00:13:29.019 --> 00:13:31.960 automated, we can build massively complex systems 00:13:31.960 --> 00:13:35.000 safely. It really is a marvel, and I'll leave 00:13:35.000 --> 00:13:38.759 you with a final thought to mull over. CI operates 00:13:38.759 --> 00:13:41.519 on this very counterintuitive philosophy. It 00:13:41.519 --> 00:13:43.519 says that if something is painful, like merging 00:13:43.519 --> 00:13:47.080 complex code, your instinct is to avoid it. But 00:13:47.080 --> 00:13:48.799 you shouldn't. You should actually do it more 00:13:48.799 --> 00:13:51.299 often. Do the painful thing constantly. Yes. 00:13:51.500 --> 00:13:54.600 Until the sheer repetition forces you to automate 00:13:54.600 --> 00:13:57.039 it and perfect it. It really makes you wonder 00:13:57.039 --> 00:14:00.019 what personal or professional bottlenecks in 00:14:00.019 --> 00:14:02.539 your own life would completely disappear if you 00:14:02.539 --> 00:14:04.960 stopped delaying them and instead forced yourself 00:14:04.960 --> 00:14:07.620 to integrate them every single day. Wow. That 00:14:07.620 --> 00:14:09.789 is a really powerful way to look at it. Thank 00:14:09.789 --> 00:14:11.690 you so much for joining us on this deep dive. 00:14:12.009 --> 00:14:13.909 Keep questioning the systems that run our world, 00:14:14.269 --> 00:14:16.470 keep exploring, and we'll see you next time.