The need for high-quality, secure software is greater than ever. Customers and regulators alike demand speed, confidence, security and accountability in software delivery. Keeping a steady flow of changes through to production, while ensuring safety and reliability is paramount.
Feature branches are a popular way of increasing the speed of feature flow by making it possible to develop multiple features in parallel. This allows you to isolate the development work associated with specific features while not affecting your main ‘production’ branch.
Modern CI tools (such as gitlab or github actions) allow you to run CI tests on feature branches. And you can then create rules that enforce a successful Continuous Integration (CI) run before merging is allowed. This ensures that a new feature won’t break the rest of your software.
Feature branches are therefore a popular model. They enable many developers to work independently on features simultaneously and then merge them safely once the changes are verified.
While feature branching sounds in theory like a good move, it can however introduce delays and breakage unintentionally. Why? Because despite their name, even feature branches often aren’t merged quickly enough to trunk – often due to delays in reviewing pull requests (PR). This can back up and lead to a combination of changes not being tested often enough. Additionally, if our CI test suites are either too lean or too slow – then feedback can come too late to allow confidence merging and potentially introduce untested bugs into production.
Consider the workflow below. CI runs on a schedule because tests take too long. Feature branches require PRs to be reviewed before merging can occur. Sometimes this means you need to run tests in your feature branch multiple times because of other changes being committed to main. Long-running tests and waiting for PRs to be approved (not to mention the review process itself) are areas where time is being wasted.
Feature Branches and Pull Requests are slowing you down
An increasingly popular alternative to feature branching and pull requests is to use Trunk-Based Development (TBD). This is where all developers check in directly to trunk. This comes with its own risks, but these can be offset by the use of solid code design and architecture, coupled with good testing and automation techniques. The implementation of Test Driven Development (Red, Green, Refactor) and writing tests before writing the actual code may also help when it comes to increasing quality and increasing your throughput of customer value.
While using TDD may feel slower at the time, it’s actually faster.
So, if despite using features branches, you feel that the flow of features and bug fixes is too slow and you’re suffering quality problems and outages, then try changing things up. You can go about this transformation in the following ways. These tips are valid whatever branching strategy you follow, but the result could mean you benefit from feature branches.
- If you don’t know already, find out your code coverage (percentage of unit test covers your code). You can use a tool such as gcov or lcov for C++ or IntelliJ tools or JaCoco for Java. You can implement code coverage in your CI pipeline and push up the results to a service such as codecov. There is no hard-and-fast rule for coverage but anything over 50% is ok and 80% is considered very good.
- If your coverage is low, then try to improve this by adding more tests. Focus also on the speed of your tests. Aim to get above 50% coverage but for your full test suite to run as quickly as possible. The faster your test suite runs (ideally as part of your CI) the quicker you can integrate changes reliably. If your CI build runs infrequently or overnight, then what can you do to make it provide feedback faster?
- Ensure that you’re running static code analysis, linting (for compiler hints and warnings) as well as SAST (Static Application Security Testing) tools against your main branch at least once a day. For speed you don’t need to run these all the time – keep you main CI quick and lean and focussed on running unit tests.
- Consider Test Driven Development in combination with Pairing or Mobbing to improve software quality and throughput.
- Stop using PRs as your quality gate. Instead, focus on more comprehensive and faster tests.
Depending on your required release cadence, taking the responsibility away from developers to manually review Pull Requests doesn’t come cheaply – you will need to invest in automated tests and increased coverage. But the investment will be paid back in terms of speed of delivery of new features, and simplicity without blocking – plus you can still run your more in-depth CI and/or linting/end-to-end testing processes on a schedule if it is still required.
