Practice of deploying more than one variant of a feature or a web-site. Purpose is to collecting real-life information on what variant that performs best according to a defined metric, e.g. click-through-rate.
The tasks/activities that is required in order to build the software. Examples of the tasks in a build pipeline are unit test, OWASP tests and integration tests.
Practice of deploying a new feature to a limited number of users, e.g. 1% of the users. Soon as the feature is proven stable with the selected number of users, the feature is made available with a greater number of users, e.g. 10%. Eventually all users gets access to the new feature. Purpose of this practice is to limited the impact of issues not identified during testing while allowing decreased time-to-market. In the Unleash-hosted management UI this practice is known as GradualRollout strategy.
Continuous deployment (CD)
A software engineering practice that focuses on deploying small increments to productions at a high pace. The practice depends on high level of automation of the build and deploy -pipeline.
Continuous integration (CI)
A software engineering practice to merging multiple developers effort into a single branch of the source repository. The CI practices automates various steps to ensure the correctness of the code before merging a change into the main source repository.
The process of taking the code from the source repository to the production. An important element for the deploy pipeline, is to automate as much as possible. The deploy pipeline usually consists of an integration, test and deployment stages.
A wrapper around a section of the code that decouples release to production from release to the customer. Feature flags are also known as Feature toggles.
A practice focusing on enabling new features to the customers considering both technical as well as business matters. This is done by separating release to production from release to customer. An important part of feature management is consider what features shall be available to what customers when. Separating the release to production from release to customer these questions can be handled separately from the development teams urge to do continuous deployment.
Same as feature flag
A kill switch is an operational feature flag that disables a section of the code. The purpose of a kill switch is to quickly ensure that the section of the code is removed from execution in a situation of instability. Usually a kill switch is introduced for unstable parts of the software, e.g. 3rd party integrations.
Operational feature flag
Long(er) lived feature flags. Usually introduced for operational purposes, e.g. to disable unstable parts of the source code. One common example of operational feature flag is kill switch.