DevOps Concepts
Feature Branch
The Feature Branch is a development practise that requires every task or feature to be developed in its own branch, separate from the main trunk.
When code is completed in the Feature Branch, it is integrated back into the main trunk.
This is useful as it ensures that the code being developed does not interfere with the main trunk.
However, it also has the disadvantage that the longer a feature branch stays away from the main trunk, the more painful it becomes to merge back to the main trunk.
To avoid this issue with long lived branches, branching with feature flags enables DevOps to effectively prevent long living branches.
Feature Flags
Reference URL: https://featureflags.io/feature-flags-vs-branching/
Feature Flags (also know as Feature Toggle or Feature Switch) compliments Feature Branch and is a technique that allows turning on a feature during deployment, or even at runtime.
It makes Feature Branching even more powerful and faster by separating feature release management from code deployment.
It requires that when writing code, developers make use of conditional statements to enable functionality related to a feature.
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 roll-outs separately from code deployments.
It allows developers to take control of feature life-cycles without depending on code deployments.
The credits for introducing this concept goes to Martin Fowler and Facebook’s development team.
According to Martin Fowler, feature flags can be classified as:
Release toggles: These toggles are used to hide incomplete features from users.
Experiment toggles: Which is employed for A/B testing.
Ops toggles: These toggles are used to control the operational aspects of a system.
Permissioning toggles: These toggles are used to manage what features are available for which group of users.
CI/CD Automation
Continuous Integration, Continuous Delivery and Continuous Deployment come in many different forms as shown in the two examples above.
A typical CI/CD pipeline consists of multiple automated steps
In the detailed example above, there are multiple steps in the Build and Continuous Integration portions. Its also possible that Automated Testing may consists of multiple steps that are not shown above.
Another example of Continuous Integration and Delivery Pipeline
In this example above, the pipeline steps are slightly different, depending on the needs of IT and business.
Continuous Delivery
Continuous Delivery is the ability to get changes of all types - new features, configuration changes, bug fixes and experiments into production and or into the hands of the users in a safe, quick and sustainable way.
This is only possible if all the steps from commit to deployment is completely automated.
Continuous Deployment
However, if the automation is all the way up to deployment to production, then we have Continuous Deployment!
Canary Release
A canary release is a new version of an application that is meant to replace the beta version in the future. Only a small fraction of users hit the canary version to see how it behaves before rolling out to all users.
A canary release last minutes or hours and never more than half a day.
A/B Tests
A/B testing is a method for comparing two versions of a feature (usually in the user interface) against each other to determine which works better.
A/B tests last for a few days to provide users and testers enough time to better identify which version is more suitable.
Smoke Tests
Smoke tests are a subset of integration/acceptance tests that are executed against production servers after a deployment, but before being made available to users.
It purpose is to ensure that the main functions in the newly deployed application(s) are working properly.