Feature Branches vs. End-of-Release Branches: Which Approach Works Best?

The Question

Someone recently asked me:

What's the possibility/risk of just using one dev branch and multiple developers working in there, then just merge to main when a release/artifact is generated? Good Practice? Bad Practice? Thoughts?

Risky Business

The Big Bang Branch. The Monolithic Merge. Call it what you will—I've seen several teams use this kind of process over the years. This approach relies on a shared DEV environment where all developers work together on one or more features. At the end of the sprint, changes are exported and later propagated to other environments (e.g., TEST, QA, PROD).

While it's technically possible—and may even be the most practical approach in some cases—there are risks to consider:

1. Lost Context for Custom DML

Imagine your team has completed multiple tickets and is ready to cut a release. Early in the sprint, a developer made a data model change that required a custom DML statement (e.g., create a new column, populate it with data from other columns, then make the column NOT NULL). The developer wrote the DDL and DML for DEV but forgot to commit the DML before moving on to the next task.

At the end of the release, the team uses project export and project stage to generate the DDL for state transitions—but what about the DML? SQLcl Projects can’t generate DML that’s required to execute the operation correctly. If you're lucky, an error will pop up during testing, hinting at the missing statement(s). If not, you might end up with a broken release, and the developer—weeks removed from the original work—may struggle to recall the exact fix.

2. Decreased Code Review

Without an iterative review process at the feature or bug level, code review often falls by the wayside. If changes aren’t reviewed and approved before merging, they’re unlikely to be reviewed at all. By the time the release is ready, the focus shifts to getting it out the door—not analyzing individual commits for potential issues.

3. Delayed Shipping to Test

When you wait until the end of a release to propagate changes to other environments, testing is put on hold. The TEST environment is often used for more comprehensive tests that aren't typically run in DEV, such as:

• End-to-end testing

• Integration testing

• Load testing

By postponing these tests until the release is complete, you risk discovering major issues late in the cycle, potentially delaying the entire release.

But Context Matters

While feature branching is generally preferred, the "right" approach depends on:

1. The team’s current process – If a team is already following an end-of-release approach but isn’t using Liquibase or SQLcl Projects, introducing these tools could help streamline versioning and set the stage for a smoother transition to feature branches in the future.

2. The nature of the project – A targeted departmental app with a short lifespan may not justify the additional overhead of feature branching. An enterprise-wide critical application, on the other hand, benefits from a structured branching strategy.

3. Budget – Feature branching requires more time, tooling, and process enforcement, which might not be feasible for every team or project.

Conclusion

At its core, the choice between feature branches and end-of-release branches is a development process decision—not just a SQLcl Projects decision.

Feature branching is preferable when possible because it promotes better version control, more frequent testing, and iterative code review. However, end-of-release branching can still make sense for less critical applications where simplicity and speed outweigh the risks.

In the end, the best approach is the one that aligns with your team’s needs, project complexity, and operational constraints.