Next, trunk based development.
To understand trunk-based development you need to understand that the “source of truth” for an application, what is supposed to be running in production, is something called the trunk. When you make changes, you make those changes in a branch and then merge the branch back into the trunk so that it contains all of the changes that have been made.
So, trunk-based development is an extension of what was discussed yesterday with regard to continuous integration. This is the next step. This is the target that projects should aim for. Continuous integration on steroids.
Trunk-based development is the idea that branches are only in existence for as long as it takes to write and debug a piece of code. At most a day. The difference I see between the two is that in Continuous Integration you have short lived branches, but the trunk may not be in a stable state to be release ready even after the branch has been merged. You have two pieces of code that have changed but one that hasn’t and unless that piece changes the application will crash.
In trunk-based development you can take the source code in your repository and deploy it to any environment, even production, and know that everything is going to work as expected. You can do this at any time. At 9:00 AM and then again at 2:34 PM. It doesn’t matter. What is in the trunk will work and can be deployed.
It’s a strange thought, that the code that you are actively writing, the feature that you are two thirds of the way completing, may be deployed, at any moment to production and the application will still work as expected.
I saw a presentation the other day that said that Amazon deployed to Production environments ever 11.2 seconds (on average during the weekday) and that each deployment was to a mean of 10,000 servers. Now imagine all of the changes that are going on. You can’t be worried about integration issues if you are changing production every 11.2 seconds. Integration issues need to be a thing of the past.
How is this accomplished? There are literally dozens of ways, but one of the most common is through the use of Feature Flags. Code doesn’t run unless the feature flag is turned on. So you can have code that is going to die in your production application because it is never going to execute until you are ready for it to execute. This provides a huge amount of opportunity for the application team as fixes can be deployed to the existing application at the same time that new features are being built out. And no one knows the difference.
This requires discipline, it is not something that you can start doing with a team of sixty people without advance planning, both in architectural design and, more importantly, project planning. But the benefits are worth it. Overall you achieve a higher quality application with better responsiveness to business requests.
Need some changes to a page? That will go in with the next release in two months. These words will never need to be spoken again. Instead the answer is going to be “Is this afternoon too late for you?“