In this episode, Edith and Paul discuss the steps that a startup can take for successful organizational scaling. They bring up important questions including: What roles should your team members play as your company grows? How do you prioritize resources? Is Paul a good coder? This is episode #26 in the To Be Continuous podcast series all about continuous delivery and software development.
In this episode, Edith and Paul are joined by Scott Raney, Partner at Redpoint Ventures. Edith, and Paul hear from Scott why continuous delivery matters in modern software development. This is episode #21 in the To Be Continuous podcast series all about continuous delivery and software development.
Feature branching allows developers to effectively collaborate around a central code base by keeping all changes to a specific feature in its own branch. With the addition of feature flags, feature branching becomes even more powerful and faster by separating feature release management from code deployment.
The Pains of Long-Lived Branching
Traditionally, new development has been done via branching. These branches typically live for months at a time, with silos of developers attempting to work in parallel. Long-lived branches often become the “I owe you” of Gitflow: “I promise to address these merge conflicts… later.” The pain points that Git was supposed to address — merge conflicts, missing dependencies, and duplicate code — gradually emerge the longer a branch lasts. We then concentrate all the pain of reworks and conflict remedies until the end, which arguably makes the pain much worse. To avoid these long-lived branching issues, branching with feature flags enables devs to effectively manage short-lived feature branches and continuously deliver better software.
To help coordinate development, engineering teams have adopted distributed version control systems (like GitHub and BitBucket). These systems allow developers to collaborate within a central codebase and use branches to make updates or develop new features. Feature branching, therefore, has become a staple of modern development cycles because they allow developers to function without encroaching on each other’s progress.
One of the shortcomings of feature branching is that feature release management is still tied to code deployments. In isolation, feature branching forces engineers to manage software delivery within the confines of their version control system. Non-technical users can’t (and shouldn’t) manage feature visibility and distribution for customers from GitHub. It is currently not possible for developers to turn features on or off in real-time, as a way to manage risk or gradually introduce a new feature.
This diagram illustrates how developers create feature branches to manage feature development, ensuring that the current build is always in a deployable state. While every company’s branching structure will be different, the basic premise is that you branch from a repository to make a new feature.
Feature Branching Using Feature Flags
This is where the introduction of feature flags makes feature branching exceptionally powerful. Feature flagging allows developers to take full control of their feature lifecycles independent of code deployments. Application features can be enabled or disabled without requiring code to be reverted or redeployed.
This process is called feature flag driven development, where continuous delivery teams manage feature rollouts separate from code deployments.
Feature flagging allows developers to take full control of their feature lifecycles without depending on code deployments. When you merge a feature branch into master (production), it is already wrapped in a feature flag. This allows you to deploy the feature “off” and then gradually roll it out to users. It also allows you to quickly “kill” the feature if it is not working well, without having to redeploy. Other benefits include:
- Better team communication
- Developers continuously collaborate on new releases, coordinate efforts, and ensure that everyone is moving forward in tandem.
- Logical deployments to prevent blocking
- Deploy code in logical chunks without resorting to long-lived branching. Even if a feature is not fully ready, it can be flagged ‘off’, but still deployed.
- Exposed dependencies
- Short-lived branching allows you to manage dependencies by removing the ones that are unnecessary.
- Faster development
- Spend less time addressing merge conflicts and refactoring old code. Spend more time delivering features that users want.
- Risk mitigation
- A feature can be flagged throughout the entire development process, from local, QA, staging, and production. This means that it can be toggled on or off in isolation, without impacting other development environments.
- Manageable code reviews
- Because you are merging more often, code reviews become less tedious and merge conflicts less onerous.
Modern DVCS combines the benefits of short-lived branches and feature flags. Tools like GitHub and Bitbucket enable continuous delivery and short-lived branching, while feature flags help make branching faster, less risky, and more manageable.
Therefore, feature flagging does not replace branching, it is complementary and makes it more powerful. Feature branching provides the flexibility to decide when and what to release, while feature flagging lets you take full control of the release itself. Together, branching and flagging help you maintain and integrate short-lived branches faster and with less risk.
LaunchDarkly now supports .NET!
We’ve just released the first supported version of our .NET SDK. Like all our other SDKs (we support Ruby, Python, Node.js, Java, Go, and more), it’s open source— check out the code on GitHub. We’ve also published a brand new .NET reference guide to help you dig in and integrate LaunchDarkly into your .NET application today.