Neil Crawdford - Trunk based development, continuous deployment and why you should adopt them

[@witchmorrow]

really awesome ideas here, thank you for uploading and thank you to the speaker!

[@ddg170]

He drank the water at 19:55

[@mescalito2]

awesome, I haven't got to that part, but he's making me nervous already :P

[@mertyertugrul]

TBD starts at 9:21

[@TristanBailey]

Great talk and some practical markers.

[@piggyraccoon5464]

I was disturbed by his procrastination to take a sip from the drink.

[@guilleagudelo]

hahah, I think it was funny. When the guy finally drank, I said Yes! Finally!

[@alexwatson6370]

Trunk-based drinking

[@BuyCarsTVPakistan]

Pre-commit and Pre-pust ideas are much better than complicated git flow model with branches and merge hells. This must be standard now and I hope there is some tool that includes all of this on client level including CI/CD.

[@alex_chugaev]

How do you make code review with such flow?

[@RayZde]

Branch and PR

[@TristanBailey]

If they are released under a flag and don’t break when off. You should be able to pass to review and they test turning on? Could also be that Trunk goes to CD to staging and then release build branches go to live.

[@MeursaultYT]

Automate them as much as possible; spend time/money creating an automated, accurate and fast feedback loop to Developers (sast, linting, automated tests). You can always pair up if needed but try to avoid it in general.

[@shayelmualem3218]

Great video - thank you!

[@TrueMetalGaming]

Who's the feature toggle provider? I don't understand the name

[@Qrzychu92]

It's LaunchDarkly

[@coderlifer4870]

Unfortunately, this does not work on mission-critical software products where you ship software or embed software in devices. Examples of these devices are medical devices where people die if there is a bug in the software, components in aircraft where the plane could crash if there is a bug, or components in cars where it could crash if the autopilot fails to disengage when it reaches 90mph. Can your nightly automated test validate the 90mph scenario? Can you do continuous deployment to thousands of cars and when you find a bug you would recall all those cars?

[@connormc711]

I think you are conflating engineering and development. If you are developing embedded devices you better not be coding without several prototypes and reviews. Are you an idiot?

[@multiHappyHacker]

LOW volume

[@danepane527]

Seriously has extreme development ever worked in development? My small experience.. no

[@RayZde]

Since the inception of Google

[@Qrzychu92]

in my understanding, you don't. You just do pair programming, which is like review on the fly. Never done that myself, so I can't tell you if that's done by single other dev or what.

[@privatename3621]

Wow. 10 second developer commit to live production. Impressive. And not once did I hear him utter the word "code review". Umm... Coming from the practices of a large billion dollar company that can't afford any down time (hey, it's a goal, right?) ...I just can't wrap my head around the idea of a small company allowing 45 developers to immediately commit code essentially straight to live production, without a strong series of manual human testing, and general "bake time" needed for complex systems. Most developers make the worst testers (I do not belong to that class and never have), mainly because they have blinders on and focus only on what they are working on in front of them. They often pay less attention to what they might break "on the other end" with their changes. That is where independent testing comes in. And not just automated smoke tests. I mean the kind of testing that required human eyeballs and human hands clicking real buttons and walking paths that the developers "haven't thought about trying". Having code go from a developer commit to production in "10 seconds", or whatever this guy was claiming, is heresy in any large company with millions of dollars at stake. This is probably why the area of CI/CD is still pretty controversial (isn't TDD dead already?) and will always need to match the maturity of and size of the company. Lone developers who write their own mobile apps, wear all the hats, and know the entire code base end to end, are best suited for "immediate deployment" scenarios. But very large companies, with very large interoperable product lines, and many different departments with many different teams, all coordinating on the development, integration, and staged release of complex production systems ...that's no place for allowing "renegade" commits to zing through some "ultra fast" devops pipeline, sight unseen, and go straight into production. That's a recipe for disaster and most large companies. All those tried and true checkpoints are there for slowing down the process just long enough to allow for careful scrutiny and deep vetting & validation. This is why a Git Flow style, multi-branch workflow, with separate Dev, QA/Cert, and Staging environments to test in, each with their own individual "week of testing" and strict verification checkpoints and audit trails, are needed in situations where a site, an API or application features being down doesn't just mean that some user sitting at home on their computer can't expand the subtree of a "2nd cousin once removed" because of a newly introduced bug. Rather, it could mean the loss or delay of millions of transactions by customers in the heat of holiday shopping coming to a grinding halt. Or an online tax prep site shutting down on the deadline for tax filing. Or the first day of a major streaming release being blown up by a crippled system ...all because of some trainee developer committed a seemingly innocent change that zinged through all the automated tests successfully and went straight into production. Congrats. Your "10 second" commit-to-live-production workflow just cost your company 50 million dollars, and maybe potential lawsuits.

[@zxcsa22]

I think you missed the part of the large amount of checks that run locally before the code is pushed.

[@tenminutetokyo2643]

Not nearly as big a problem as the massive mess the web is. We need consolidation.