Beautiful

Thanks! Be sure to check out the whole series at 9am PDT every Wednesday through July 31. We have some amazing panelists coming up - Esther Derby, Linda Rising, Barton Friedland, and more!

Thanks for your question. This video is a short clip from a longer live event recording you can find here - kzfaq.info/get/bejne/jL2KZsJ9ns21fI0.htmlfeature=shared. But to answer your questions, one of our panelists, Mike Rieser, has responded to it for you: Trunk-based development requires Continuous Integration but is independent of Continuous Delivery or Continuous Deployment. With Trunk-based development, there isn’t a release branch different from the trunk, and there are almost never any other branches. There may be very rare exceptions or branches that are only used to handoff incomplete work between developers (such as mob.sh). With Trunk-based development, the developers push frequently and directly to Trunk (or mainline), they never hold onto changes for very long. They want their commits integrated quickly and often. They will also pull changes from the mainline frequently as well. If the organization is doing Continuous Deployment, then all the commits to the Trunk (or mainline) will go through all the necessary checks and if they pass go immediately into production or whatever the deployed state of that app is. If the organization is doing Continuous Delivery, there will be a decision made and the deployment will be done when it’s been decided. Either way, it’s the code that has been committed directly to the Trunk or mainline that is deployed, and that is the branch (trunk) where development is done.

​@@IndustrialLogic Thanks for the reply! I do understand that Trunk is more concerned with CI (frequent updates of the trunk), but what I don't understand is "what is passed to the CD pipeline in Trunk based development?". What I understand from Continuous Delivery is that every single commit that is pushed to the main branch should be packaged in a uniquely identifiable artifact. The artifact is then passed through a set of acceptance tests. These tests should provide an answer to the question: "Is this artifact ready for production?". It doesn't have to be deployed at that moment, but you need to know if that artifact is in a prod releasable state, which means the codebase is prod releasable. This is Continuous Delivery for me: making sure devs are using CI, and making sure the trunk is always prod releasable through automated tests. The part that confuses me about Trunk based is that there are also release branches... So should we pass every commit in the trunk to the CD pipeline, or just the commits located in release branches? If we pass the artifacts built from every trunk commit to the CD pipeline, what is the point of the release branches? I thought the purpose of the release branches was to group a set of trunk commits and guarantee they work well enough to be considered "releasable". TL;DR: In Continuous Delivery, if every trunk commit is passed to the CD pipeline, what's the point of the release branches? Thanks! EDIT: I just read the official guide of Trunk Based Development: trunkbaseddevelopment.com/branch-for-release/ They say "CD teams do not do release branches". Everything makes sense now! I went over that page multiple times and apparently my brain just chose to ignore that blue section.

@@user-jw2kc8ip5q First let’s talk about idea and then practical. Ideally, for every commit, you want to run any and all tests you have. In practice, unless the build is seconds to a minute long (possible), you won’t have the time to do this unless you then want for each commit to go through. When the team is small, say 2 - 4 committers (people /pairs / ensembles), you won’t have to wait other commits often. As the team grows, both the frequency of commits increases, and the build times tend to grow over time. At some point you’ll realize that the value of having the build system individually verify each commit isn’t worth the cost of waiting for longer build times. This only works if the team has agreed to, and is practicing CI, then it’s probably OK to not build each commit by itself - each committing group is doing that locally. And important mental model: The build server is NOT doing CI/CD. Humans are. The build server is making sure we didn’t mess up. It is keeping us honest, and makes sure that if we do have a regression, it’s caught quickly (well under an hour), so it is easier to fix, and less code gets built on top of that regression. While it is possible to have a regression, in practice it doesn’t happen too often. So the value of waiting for each individual commit is often not worth the cost of waiting. When a regression happens, we’ll use something like git bisect to find it, and fix it. But while that does happen, it is rare. Something to consider is the idealized form of CI / CD versus the practical version, where you consider transaction costs like build time, and you back off of the ideal to the practical. Regarding release branches. You do not need release branches. You can have them. We’ve used them. And so long as they are short-lived, and any fix you make is then merged back to main, it is OK. However, rather than using either feature or release branches, we prefer to use feature toggles. The code is deployed, but not generally accessible to all users. If we have new work behind a feature toggle, then a defect in a release means: * fix the defect in main * make sure the toggles are configured for what is intended to be available * build and push a new version (preferably with 0 down time) To summarize: * At the end of the day, we only care about working code in production that can be reliably updated and re-released at will. * CI / CD are ways of working - human practices and agreements - that can be supports by tooling. * We keep new features behind feature toggles, to remove the need for both feature branches and release branches * We want to work in ways that reduce risk but do not greatly increase development time * The desire to keep development time down is NOT about rapid feature delivery (it supports it), but is about getting and maintaining rapid feedback * If the build is fast enough, we might run each commit individually, that is ideal, but at some point, the commits are likely to happen faster than the transaction costs for the build time - and you back off of the ideal, accept some risk, and make sure that build failures stop development to get the regression fixed. Your head seems to be in the right place. Keep asking “how is this practice helping.” E.g., why do we need release branches when we do CI/CD. We can work in ways that make them unnecessary, we can work in ways that make them add value.

Absolutely agree!

+1. I always use the word "translator" when describing the driver's role. Drivers build an important skill: they listen to directions about what we're trying to accomplish, then translate it into appropriate code. As skills build (in the language or tooling at hand, in the understanding of the system getting changed, in the ability to parse and interpret verbal direction, etc.), the directions become less detailed. Rather than "turn Left here, go 100 ft, turn right, turn left, etc.", an experienced driver can be told "head to Union Station." In a true driver-navigator role (e.g. in a car or airplane), the "navigators" are making the decision about where to end up. The driver is suppose to be listening to specific direction and otherwise focusing on the road.

That's so you don't scare people away completely ;-)