Back Arrow Icon
Go Back

The DevOps Dictionary

So what does all of this mean?!

There’s a lot of terminology to keep track of in the world of DevOps and feature management. And, admittedly, some teams use different terms to refer to the exact same thing (feature flags = feature toggles = feature switches, etc)

Hopefully this DevOps dictionary simplifies things, even just a little bit:

A/Bn testing: 

ABn testing is a type of A/B testing where you deploy a new feature or update to a subset of users. This approach can help you gather feedback about the new feature or update before deploying it to all users. The “n” in A/Bn testing simply denotes that more than two features could be tested.

Access Control: 

Access control is a security measure that allows you to restrict access to certain areas of your application to certain users. This can help prevent unauthorized end-users from accessing sensitive data or areas of your code. 

Agile Development:

Agile development is a software development methodology that emphasizes iterative development, team collaboration, and customer feedback. Agile development teams typically ship new features and updates in short cycles, which helps them move faster and respond to changes more quickly. Feature flags can help agile development by allowing developers to test and ship new features to users without having to wait for a complete release.


A unique or standardized variable used to target users. 

Beta Tester:

A beta tester is a user who tests software before it is released to the general public. Beta testers provide feedback about the product to the development team, which helps improve the quality of the final product.

Canary Launch:

A canary launch is a method of releasing a new software feature to a very small subset of users before making it available to everyone. Canary launches help development teams test new features in production and gather feedback before releasing to the entire user base.

Continuous Delivery:

A method of software development where code is automatically delivered to a production or testing environment upon completion. It still has to go through testing in this stage, so will not yet be deployed to your end users.

Continuous Deployment:

Continuous Deployment goes one step further than continuous delivery. If the code has successfully passed automated testing in your production/testing environment, it will be automatically deployed to your end users.

Continuous Integration: 

Frequently integrating small changes to the code base to ensure that there are no errors in any of the code. This helps the team identify any problems early on. 

(In sum, you achieve a CI/CD pipeline by 1. Continuously integrating small changes into your code base, 2. Continuously delivering that code to your production/testing environments, and 3. Continuously deploying code that has passed the automated testing to your users.)

Feature Flag: 

A conditional statement that you wrap your code in to either enable or disable a feature in software. Feature flags are used to control the visibility and release of new features in software, and ship new features to users without having to wait for a complete release.

Feature Management: 

Feature management is a process that ensures that new features are deployed and released to users in a strategic and controlled manner. Beyond feature releases, effective feature management processes benefit teams at an organizational level by keeping deployment risks & costs low, and helping them release more frequently to end users.

Kill Switch:

A software development technique that allows devs to instantly disable code that isn’t performing as expected. When the code is disabled, users will revert to the default experience.

Multivariate flag:

Unlike a boolean flag that has just two variations i.e. true and false–or on and off–a multivariate flag has more than two variations available. For example, a flag that varies based on region.

Ops flag:

Ops flags are used when releasing features with unknown performance implications to ensure the safety of your systems during the deployment of the feature.

Percentage rollout:

Also called “gradual rollouts.” Teams can gradually roll out a feature to a percentage of users (i.e. starting with only 25% on day 1 and working up 100% of users on day 4). This allows devs to monitor the performance of a feature on a smaller subset of users before it’s released to the entire user base. 

Permission flag:

Permission flags are a type of feature flag that allows developers to control which users have access to specific features. This can be used to restrict access to features that are still in development or to give beta testers early access to new features.

Personally Identifiable Information (PII):

Any information that could be used to identify an individual or user. 

Private Attribute:

User information that is not publicly available, and is sometimes PII. DevCycle users can use this type of information to aid in user targeting, but DevCycle’s platform itself never collects nor stores this information. 

Progressive Delivery:

With progressive delivery, new features are first made available to a small group of users, and then gradually rolled out to a larger group of users over time. This approach allows developers to gather feedback and make changes to the new feature before it is made available to everyone.


A release is when you make changes available to a small group of users first, and then gradually roll out the changes to a larger group of users over time. In contrast, a deploy is when you push changes to a program that are then live for everyone.

Release Flag:

A release flag is a conditional statement that allows you to specify whether a piece of code should be included in a release or not. This can be useful for ensuring that code is only included in a release when it is ready and has been tested.

Ring Deployment: 

Ring deployments are a type of deployment where code is first deployed to a small group of users (known as a "ring"), and then gradually rolled out to more users as it is verified to be working correctly. This allows for a more controlled and gradual rollout of new code, which can be helpful in avoiding disruptions. (Similar to progressive delivery, gradual rollouts)


A rollback is a process of undoing changes to a piece of software or code. This can be useful if a new change introduces bugs or problems. Similar to gradual rollouts, you can gradually rollback a piece of code to undo a feature/revert to the default experience slowly. 

Roll forward:

Rolling forward is the process of taking a new change and applying it to an existing system. This can be useful for quickly fixing a problem or for testing a new change before deploying it to a live system.


User segmentation is the process of dividing users into groups based on certain criteria. This can be useful for targeting different groups of users with different messages or for providing different levels of access to different groups of users.

Targeting Rule:

A targeting rule is a statement that defines which users should be included in a particular group. 

Testing in Production: 

The process of running tests on a live system–on a live user base–rather than testing in only a staging environment. This allows you to find and fix problems before they impact a larger number of users. 

Time bomb

A piece of code that is designed to cause problems at a specific time. This can be used to test a system's ability to handle problems or to cause problems in order to test a system's recovery procedures.


A feature toggle is synonymous with a feature flag. Used to enable or disable features. 

Trunk-based development: 

Trunk based development is a software development strategy where engineers merge smaller changes into the main codebase. One benefit of this is that it helps avoid any major issues when releasing a software product. 

Waterfall development:

Waterfall development is a traditional development methodology where each phase of the project is completed before moving on to the next phase. This can often lead to delays and missed deadlines as a result of having to wait for one dev to complete their portion of the project before the next.