As developers, we spend countless hours building new features and having them pass through rigorous QA tests. However, despite experience and all preparations made, there's always that dreaded feeling you get in the pit of your stomach when you know it's time for deployment. What if something goes wrong in production and your feature doesn't function as expected?
As software engineers, we are constantly faced with a variety of challenges. These challenges range from developing innovative features based on constantly changing requirements, to deploying these features to production and releasing them to users with the hopes that they work as intended.
Anyone that has been actively involved in software development is familiar with the stress and anxiety that is caused by deployment and feature release. There's always the constant worry over whether things will go smoothly as planned when these changes are pushed to users.
That’s why the most important investment a team can make in a company is helping engineers overcome this constant fear of failure associated with feature releases.
The Anxiety and Pain of Traditional Big Bang Feature Releases
In the past, deployments were done using what's known as a big-bang approach, where all features are released in one go. This results in a single major release with lots of changes and feature releases bundled into it, which is problematic in at least two ways:
Bundling up lots of changes and new features into one big bang release makes the release more complicated. The complexity of such a release opens up a lot of possibilities for release failure since things could go wrong in a lot of ways. As a result, most engineers and everyone involved in the process in such organizations or companies don't like release day due to the risks and anxiety that come along with it.
Secondly, another problem with this big bang release approach is that most organizations are typically structured to have a fixed release schedule that is infrequent, such as one in every 3 months or thereabouts. This makes delivering changes, fixes, and new feature updates to customers slower, which results in users of the service not being able to access new features or improvements quickly enough. This could negatively impact the user experience of the service.
Overall, traditional big bang feature releases are much slower and riskier because there is a lot more at stake with each deployment if things don't go as planned, which causes greater anxiety and fear of failure for anyone involved in the process.
Separating Code Deployment from Feature Releases with Feature Flags
Releasing feature updates comes with many risks, so it would be prudent to try to minimize these risks by separating deployments from feature releases. This approach allows for a safer and more flexible release strategy, as it is typically safer to make these release changes incrementally.
This incremental strategy means that the risks associated with traditional deployments and feature releases are minimal and better managed. Also, priority features can get delivered as soon as they become available for user consumption.
However, the question you might have if you are new to the world of modern DevOps is what is the difference between deployment and feature release as these terms are often used interchangeably.
Deployment typically involves moving software changes from one controlled environment to another, usually from a development environment to a live or production environment. The fact that these changes are in the user's environment does not necessarily mean they are available to the user.
Feature releases describe the rollout of features and updates to users. In other words, a release gives users access to these new changes and features by making them available to the users.
One of the most effective and easiest ways to separate your deployments from your feature releases is by using feature flags.
Feature flags determine whether a piece of code or functionality wrapped within it is active or not. Like conditional if/then statements, you can put your updates and features behind a feature flag that hides them after deployment until it’s ready to be released. This means you can continually ship value while avoiding unnecessary risks and anxieties.
The Benefits of Using Feature Flags
Whenever you are releasing new features and updating your product, it is easier to have a continuous delivery pipeline which allows you to push these updates incrementally as quickly as possible while also safeguarding your customers in the event that any unexpected issue arises. You should be able to roll these updates back out of production as quickly as possible to avoid negatively impacting users.
With feature flags, it is possible to create a continuous delivery pipeline that allows for both feature addition and risk reduction. Feature flags allow deployments of features to be decoupled from their releases. As a result, you can easily roll out new features without releasing them immediately to the public and easily roll back these features if the need arises.
Fortunately, there are several feature flag management services such as ConfigCat that offer feature flags as a service. A good feature flag configuration management service comes equipped with key feature flag functionalities and tools to help you and your team leverage the power of feature flags such as:
User Segmentation: Feature flags can be used to segment your users into subgroups and to test and release features to them based on attributes assigned to different user segments such as location, geography, gender, etc.
A/B Testing: By using Feature Flags, you or your Product/Marketing teams can test alternative ideas on your users before proceeding to final implementation based on the feedback from these tests. By doing this you are able to offer the most satisfying customer experience by pushing only the most performant ideas to your users.
Progressive Delivery: Feature flags enable you to implement your feature releases gradually to help minimize the negative effects of continuous product iteration. The advantage of releasing in smaller chunks regularly is that it's much easier to observe the effect of each change, and if anything goes wrong, quickly roll back the changes.
Kill Switch for Easy Rollback: In the event that your feature release doesn't work correctly in production, the change can be rolled back immediately from production via a kill switch option.
Intuitive UI Dashboard: Remotely manage all of your feature flags from an intuitive dashboard without having to redeploy code when changes need to be made to the flags' configuration.
SDK Integration: Simple SDK for easy integrations with various apps and platforms.
Summary
In today's rapidly changing world, if you don't improve, you get worse. The success of a development team ultimately depends on how frequent and successful their releases are. However, traditional deployment comes with a lot of release anxiety from the fact that release day is made into a major event.
Feature flags play a prominent role in making releases as uneventful as possible by providing key functionalities that give you fine-tune control over the exposure of your feature releases. By using feature flags, you can decouple your feature releases from deployment to create a continuous delivery pipeline that enables you to continuously ship value without risking unnecessary exposure.
For more information on feature flags and how they help ease deployment-related anxiety, follow ConfigCat on Facebook, Twitter and LinkedIn.
Top comments (0)