The Death of Continuous Integration

Recorded at:

Summary
Steve Smith compares and contrasts different types of Feature Branching and Trunk Based Development, and explains why Continuous Delivery without Continuous Integration is not working.

Bio
Steve Smith is an Agile consultant and Continuous Delivery specialist at Always Agile Consulting Ltd. Steve is a co-author of the Continuous Delivery and DevOps book “Build Quality In“, a co-organizer of the monthly London Continuous Delivery meetup group, a co-organizer of the annual PIPELINE conference, and a regular speaker at conferences such as Agile On The Beach and QCon New York.

Agile Tour London conference is a part of the Global Agile Tour. Since 2008, it has become a hugely successful worldwide event spanning 30 countries, creating a world-wide network of agile events open to everyone: from Confirmed Agile Practitioner to Agile Newbie. The 2nd London edition again allowed participants to increase their knowledge about Agile and discuss best practices.

Sponsored Content

Key Takeaways

Many teams now implicitly discard Continuous Integration due to ever-easier Feature Branching and an under-appreciation of Trunk Based Development

5:40 With release feature branching, developers would commit their changes to a long-lived shared branch of a source code repository. It was scary because it was complex, risky, unpredictable and would probably cause defects

6:20 Release feature branching example: fictional company account service team are doing release feature branching over a period of some time

6:30 Advantage: Four different epics and the only advantage of this style of work was that if a build failure happened then the other branches could continue unimpeded.

6:50 Problems: 4 different epics merging in at 4 different times and when you do it’s not possible to predict how difficult it’s going to be to actually get Trunk to work after that production release.

7:16 Very little refactoring ever happened and that was simply out of self-preservation.

7:32 Not a lot of collaboration happening: 2 developers working on 2 different branches will have a design diverge in 2 different directions. In this style of work it’s impossible to achieve continuous integration.

Trunk based development

9:00 In the early – mid 2000 Trunk based development was clearly a rival to this style of feature branching

9:10 Trunk based development was and is a version control strategy where developers commit their changes directly onto Trunk in small incremental steps that minimize merge complexity and always preserve a releasable code base.

9:25 Developers are committed to Trunk multiple times a day. Testing happens from Trunk and production releases ideally happen from Trunk.

9:31 You might use a release branch for risk mitigation reasons if a production defect is found.

9:45 Trunk based development is equally applicable to centralized version control systems and distributed version control systems. It’s entirely independent of any particular tool.

10:01 Example: Company Accounts Service – a period of a couple of weeks working on several specific features.

10:16 When 2 features start in proximity to one another in terms of time and region of the codebase with Trunk Based Development there has to be a conversation, you can’t avoid this problem of people treading on one another’s toes.

10:40 What is likely to come out of that conversation, is a decision to conceal one of these features and in the case of a new feature, you would conceal it with something called a 'feature toggle', which is essentially just a runtime configuration parameter.

11:28 With Trunk based development, a build failure is a quite big deal, there is no place to hide. A build failure stops everyone in their tracks.

13:58 Everyone has a shared mental state of the codebase so there can be a very high degree of collaboration.

14:33 Feature toggle and branch by abstraction have operational and business benefits

15:45 Trunk based development is entirely compatible with continuous integration

16:25 Trunk based development requires a big investment in development practices, in automated testing. It requires every member of the team to re-architect, redesign and re-communicate their changes every single day. It can be much harder with a legacy code.

16:55 It feels like you are moving slower, but it means you are spending more time working on something until it’s developer complete.

17:08 If everyone is moving through the code base at the same pace, then you are less likely to have to go into some kind of costly re-architecture or some redesign.

22:30 With Build Feature Branching developers commit to their changes in their individual remote feature branches that were intended to last for a day or so before they emerged back into Trunk for testing and release into production.

28:18 There are 3 key assumptions that will not hold water for any team for length of time: Assumption #1 - feature branches will always be short-lived. Assumption #2 - reviews will always be timely and assumption #3 - builds will always be well-monitored.

28:33 Assumption #1 - feature branches are always be short-lived. Feature branches last longer than a day and that’s because the only constraint upon feature branch duration is developer discipline. When this happens to one developer on the team, you’ve lost continuous integration.

29:46 Assumption #2 - reviews are always be timely. Reviews last as long as it takes for 2 people who are working on orthogonal tasks to actually come together and share responsibility for a single outcome.

30:50 Reviews might take hours or days because the right person is not available at the right time. To make continuous integration work you have to sacrifice code reviews, if they are not timely enough.

31:18 Assumption #3 - builds are always be well-monitored. Builds will be slower in this style of version control because build feature branching is predisposed towards asynchronous integration.

31:41 James Shore describes synchronous integration as when a developer commits their changes to Trunk and they wait for the build to finish before they move on to the next task and asynchronous integration as when a developer commits their changes to Trunk and they immediately move on to the next task, without waiting for the build to complete.

35:26 Why is continuous integration dying? Stackoverflow survey – 16k developers responded to a question about version control and 69% of them said that they use Git as their version control tool of choice

37:14 GitHub – very popular tool. In July 2015 they reported 26m repositories and 10m users

37:57 How the team behind Build Feature Branching, the team behind GitHub are able to use Build Feature Branching to accomplish continuous integration

38:59 Build Feature Branching is rocketing in popularity and that means that continuous integration is dying. Continuous delivery is going to be very difficult to attain

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.