Article

8min read

Alpha vs. Beta Testing: What are the Differences?

Prior to the launch of a product, a number of tests are usually run to ensure that a software is ready for release and provides a good user experience. The purpose of these tests would be to validate the software before going ahead with a final release to your end-users.

These sorts of tests are essential to make sure that the software you’re releasing is free of bugs and meets the quality and requirements expected by your customers.

Among such tests are alpha and beta tests. These tests are conducted towards the end of the software development life cycle (SDLC) to test releases outside the development team to help uncover any issues that would otherwise not show up in previous tests that are run in more controlled environments.

What is alpha testing?

Alpha testing is typically run on internal users by the QA team (Quality Assurance) to make sure that the software meets all expectations and is working as it should. Thus, it represents an opportunity to evaluate the performance and functionality of a product release as well as obtain feedback from technical users.

In other words, the main purpose of this test is to uncover any bugs or issues to resolve them before the final product is released to users. It helps ensure bug-free functionality by carrying out tasks that a typical user may perform.

This test is usually performed when your product is nearly complete towards the end of the software development cycle in a staging environment, which attempts to mimic an actual production environment as closely as possible, but before beta testing, which we’ll get to later.

It seeks to answer the question whether your product actually works.

Alpha testing involves two main phases:

  • The first phase is run by software developers using debugging tools or software to catch bugs quickly.
  • The second phase is performed by the QA team and may involve ‘white box’ and ‘black box’ testing. A white box test will test the software system’s design and internal structure allowing QA testers to ‘look inside’ the product. A black box test, meanwhile, will test the system’s input and output functionality. 

 

The advantages of this type of testing are clear.
 

It allows teams to locate bugs and issues that managed to escape previous tests so that they may be fixed before they reach your end-users. 

Up until that point, tests were focused on testing specific parts of the software but alpha testing, on the other hand, looks to see if the software as a whole functions correctly.

In other words, it enables teams to validate the quality and functionality of their releases before it is released to customers. Put simply, Alpha testing opens up the application to receive initial feedback.

This results in improved software quality as the software is tested in an environment that is a very close replica of the environment it will eventually be used in, hence creating realistic testing conditions. This also allows the QA team to understand how the software will behave when it is later released to end-users.

To sum up, alpha testing provides an opportunity to put your product in real user environments but with technical users who are more adept at identifying and discovering bugs before conducting beta tests with actual real-world users.

However, conducting alpha testing may prolong the test execution cycle thereby delaying the release of the product to your end-users. Also, keep in mind that since the software is still in the development stage, alpha testing doesn’t provide in-depth testing of the functionality of the software.

Now, we will move on to the next testing phase, beta testing.

What is beta testing?

Beta testing involves releasing the software to a limited number of real users external to the organization. As a result, this type of testing is done in a production environment.

These users will then be asked to provide their feedback on the release, also named “beta version”. Beta testing, then, is an opportunity that allows users to test out the product to uncover any bugs or issues related to user experience (UX) before it is rolled out to the rest of your users.

In other words, it represents the final stage of testing before releasing the product to a wider audience. 

It also enables teams to run security and reliability tests as those tests cannot be conducted in a staging or lab environment.

There are many ways to implement beta testing. For example, often, companies will ask a select number of users to willingly op-in to get early access to the software. The advantage of this is that these users will be aware that the beta version may not be very stable and so they are more forgiving of any potential bugs and are happy to provide the feedback you need to optimize your product.

To be more specific, you may go for a closed or open beta test. In an open test, anyone can use the product but users are given a clear indication that the product is a beta version so they know that it’s still a work in progress. 

Meanwhile, in a closed test, as in the example given above, the testing is limited to a specific set of users, which would be by invite only. These users would be composed of early adopters, current customers or even paid beta testers.

Such exclusivity is one way to build close relationships with specific users as you are demonstrating that you value their opinion in particular before doing a wider release.

The advantage of this testing is clear. It is the first chance to test how the software will behave in real-world settings and observe how your end-users interact with it and what the user experience looks like.

Product managers, in particular, can make use of the feedback received to collect ideas and suggestions when planning future releases.

Beta testing is a way these managers can observe usage behavior and analytics to confirm that users are interacting with the product as expected. They may also run experiments and A/B tests of features to decide which one to choose for a general release. 

This, in turn, allows developers to uncover any bugs in real production and less controlled environments so that they may be fixed before a full launch.

Many bugs may have been discovered during alpha testing by your internal users but nothing can truly simulate real world users, which is why beta testing is necessary after alpha testing.

However, as we’ve seen, beta testing is conducted in real environments as opposed to controlled environments during alpha testing and so the former is more difficult to control.

Feature flags and beta testing: safer testing in production

During beta testing, you are essentially testing in production, which doesn’t come without its risks but luckily there is a way to mitigate those risks: by using feature flags.

A feature flag is a software development tool that helps decouple deployment from release, giving you full control over the release process. With feature flags, you can perform beta tests by enabling features for certain users and turning them off for everyone else.

Feature flags also act as a kill switch so that you can gradually roll out features to users to test performance and if something goes wrong, you can just as easily roll it back or turn off the buggy feature.

Feature flags are a great way for all teams within an organization to carry out beta testing as using feature flags for beta testing means even non-technical users such as product and marketing teams can turn on features for specific users, which means they’re not so reliant on development teams anymore.

Alpha vs beta testing

The major advantage of such types of testing is that it helps the development team to identify issues in advance before it goes to launch, allowing them to fix these issues early on before going for a full release. 

However, as already alluded to in above sections, there are still major differences between these two types of testing, some of which are summarized in the table below.

 Alpha αBeta ÎČ
TestersInternal employeesEnd-users or customers not part of the organization
Environment Requires a specific environment for testingDoes not require a testing environment
What’s testedFunctionality and usability are tested while security and reliability tests are not carried out in depthReliability, security and stability tests are key aspects of a beta test
Testing techniqueUses both white and black box testing techniquesFocuses mainly on black box testing 
WhenRun before the product officially launches to the marketRun after the product is launched
PurposeTest that the product is working as it should to evaluate product qualityUnderstand how real users interact with the product and to evaluate customer satisfaction 
DurationLong execution cycleShort process usually only lasting a few weeks
Post-test actionsAny bugs or issued discovered will be immediately rectifiedMost issues identified and feedback received will be implemented as improvements future versions of the product

Conclusion

Clearly, testing is important to ensure the delivery of high quality, bug-free releases. There are a number of tests carried out throughout a software’s life cycle, each of which serves a unique purpose. 

Read more: all about test environments and the type of tests that may be run as the software is being developed.

Here we looked at two important ones that occur towards the end of a software’s life cycle: alpha and beta testing.

Both alpha and beta tests are an important part of the testing process as they provide a valuable means to highlight crucial issues with your releases and provide user feedback, both internally and externally.

Alpha testing helps validate the quality of your software while beta testing allows you to obtain real-world feedback to ensure you’re building products that your customers actually like.

Therefore, in the testing lifecycle, both alpha and beta testing are essential.

Article

9min read

Flutter for Mobile App Development: Overview and Benefits

As mobile usage has increased and spread widely all over the world, mobile apps, as a result, have also risen in popularity. This means it’s important for app developers to stay current on the latest development tools in order to build high quality apps.

There are now many tools out there and if you’ve been keeping up with the mobile development world, you’ve probably already come across Flutter, which has generated a lot of buzz since its release in 2017.

What is Flutter?

Flutter is a free and open-source UI software development kit created by Google. It is used to develop natively compiled, multi-platform applications for mobile, web, and desktop from a single codebase and programming language.

This has greatly contributed to Flutter’s appeal and why it’s become so popular today.

It has been designed to support mobile apps that run on both Android and iOS allowing you to build apps on different platforms from the same codebase. This means, for example, that the code you used to publish your Android app can also be deployed on iOS, the web or desktop with little change.

Moreover, Flutter’s support for desktop devices means you can scale your app to Windows, Linux and Mac and hence reach more users on these platforms’ app stores.

Put simply, Flutter essentially provides a widget-based UI library, including UI elements such as text boxes, buttons and image blocks that can be used to create and personalize your app. 

To give a better visual of the coding process when writing your first app in Flutter, the below image gives a glimpse of a code for a basic Flutter app-everything in the code is a widget:

Source

We will come back to Flutter widgets in a bit but for a deeper understanding of Flutter, it is worth taking a look at its architecture first to understand the concepts that form its design.

Flutter architecture

Flutter consists of two major parts- a framework with a UI library based on widgets, which contains various reusable UI elements, such as sliders, buttons, text inputs, and others, and a software development kit (SDK)- the tools that help develop apps i.e., to compile code into native machine code for the use of iOS and Android.

The following image shows the major components of Flutter, which are organized around layers. This layered, extensible system exists as a series of independent libraries that each depend on the underlying layer.

Flutter Architecture Diagram

The three main architectural layers of Flutter consist of:

  • Framework: Developers interact with Flutter primarily through the Flutter framework, a modern reactive framework written in the Dart language. This framework provides a rich set of libraries that are divided into layers: basic foundational classes, rendering layer, widgets layer and Material and Cupertino libraries. 
  • Engine: In the diagram above, we can see that the next level of Flutter is an Engine written in C++ and which provides low-level implementation of Flutter’s core APIs.
  • Embedder: This platform-specific embedder provides an entry point and coordinates with the underlying operating system to access services such as accessibility, rendering surfaces, and input. The embedder is written in a platform-specific language such as Java and C++ for Android, Objective-C/Objective-C++ for iOS and macOS, and C++ for Windows and Linux.

Flutter uses Dart, also created by Google, for writing code. Dart is a client-optimized language for developing fast apps on any platform with the goal of offering the most productive programming language for multi-platform development.

You can look at Flutter as the front-end UI that you use to develop the app and Dart as the backend code that is automatically generated.

Dart compilers and runtimes support the combination of both just-in-time (JIT) compilation, which provides a faster development cycle and allows for hot reloads of the Flutter app, as well as ahead-of-time (AOT) compilation. AOT compiled programs usually run quicker as they are compiled before execution while JIT programs are executed at or just before runtime. 

Therefore, Dart combines the advantages of both JIT and AOT compilation: fast development cycles, and fast execution and startup times.

Everything on Flutter is a widget

In Flutter, basically everything is a widget, which is the core concept of the framework. Widgets are the building blocks of a Flutter’s app user interface and represent an immutable declaration of part of the user interface. In other words, they declare how a UI should look.

Thus, to build any app in Flutter, you start with a widget. The main underlying idea is that you build your UI out of widgets. Widgets describe what their view should look like given their current configuration and state. It includes a text widget, row widget, column widget, container widget, and many more.

To be more precise, Flutter draws its own widgets and uses the Skia library for rendering UI instead of relying on platform-specific components, which reduces communication between the Flutter apps and the mobile platforms. In other words, as Flutter uses its own rendering engine, UI built in Flutter can be launched on virtually any platform. This ensures consistency of the application interface across all platforms. 

As far as their layout, the widgets within a Flutter app form a hierarchy where a widget is a composition of other widgets and each widget inherits properties from its parent. Widgets, then, are arranged into a tree and nested inside of each other to parent and child widget.

The image below illustrates how the UI is built using widgets:

Flutter has a rich library of pre-built widgets, which speeds up and simplifies the process of creating a UI/UX. It’s also possible to create custom widgets.

There are primarily two types of widgets in Flutter: stateless, whose properties don’t change over time such as Icon, IconButton, and Text, and stateful, which are dynamic in nature such as Checkbox, Radio, Slider, InkWell and Form. 

Furthermore, Flutter has specific widgets specific to a particular platform – Material Design for Android or Cupertino style for iOS.

Benefits

  • Hot reload

Flutter enables faster app development using its hot reload which allows developers to view code changes as soon as they are saved. The changed code can then be reloaded immediately while the app is running and without losing the current application state, which means that developers can make quick changes and see the outcome immediately.

It also makes it easier to test out new ideas and experiment with new features helping boost creativity.

Reload in action

  • Enhanced performance

Unlike other cross-platform frameworks, there isn’t any kind of bridge converting Flutter widgets into the native components, which would slow things down and cause performance issues. Instead, Flutter’s core graphic machine, Skia (a 2D graphics rendering library), compiles the UI to native code without the need for any additional software as the user interacts with the app.

React Native, for example, uses JavaScript as a programming language to build an application and it uses a bridge to communicate with native components, which would affect the overall performance of the app.

As Flutter doesn’t need this bridge, apps built using Flutter run faster than apps developed with React Native.

  • Easy to learn and use

Compared to React Native or Java, Flutter is much easier to learn and use.

As discussed previously, Flutter uses widgets which makes the UI easy to use providing you with all the features you need to build your app.

The language Flutter uses, Dart, is also easy to learn especially for those who have already worked with other popular languages such as Java and C#.

  • Faster development and release time to market

One of the most prominent features of Flutter is its hot reload, as mentioned above. Hot reload allows developers to see changes to their codes almost instantly. In other words, with the Flutter framework, there is no need to recompile the code every time you make a change. This is what largely makes Flutter app development time faster than others.

Furthermore, since developers are working with one code base for both iOS and Android apps, this means they don’t have to write a platform-specific code. Any 2D-based UI can be implemented in Flutter without interacting with a native application counterpart.

Therefore, using a single code base, you can develop one UI design for both iOS and Android, which helps save time and resources.

  • Open to everyone

Flutter is open source and free to use and it also provides extensive documentation and community support in case any issues arise. Because of its rising popularity, Flutter has a fast-growing community of developers who are always ready to share their knowledge and experience so there’s a lot of support out there to help you get set up with the tool.

Flutter vs other app development frameworks

As we’ve seen, Flutter offers many advantages that arguably make it a superior choice to other hybrid development frameworks such as React Native.

There are many things that sets Flutter apart from React Native- things we’ve already mentioned such as the fact that the latter’s programming language, Javascript, requires a bridge to communicate with different native components while in Flutter no bridge is needed and so this ensures faster app development.

Also, the great thing about Flutter that also sets it apart is that it has UI widgets packaged within itself without relying on any third-party tools like React Native, which could affect app performance. In other words, within the Flutter framework, you have everything you need for developing mobile apps. Not to mention that Flutter provides a unified UI experience across all platforms.

Flutter is also ideal if you’re looking to build a minimum viable product (MVP) if you’re short on time using its expansive widget collection.

Many major companies today have used Flutter to develop their apps including:

Google Ads, Alibaba, Hamilton Musical as well as Reflectly (who provide their own take on why they decided to switch from React Native to Flutter). 

To sum it all up


Flutter is a great choice for mobile app development projects of any size. Because it’s easy to learn and comes with clear and detailed documentation, developers can become acquainted with the Flutter framework quite quickly.

You can even integrate a feature flag solution inside your Flutter app, which will give you more control over your app releases by targeting certain user groups as well as allowing you to easily roll back releases in case anything goes wrong with minimal impact.

Feature flags will allow you to bypass app store validation as with remote config implemented through feature flags, any changes can be made instantly and remotely and then released to a small subset of users to get feedback before releasing it to everyone else. Therefore, you can upgrade your app continuously in real-time based on feedback from your users without waiting on app store approval.

With AB Tasty, you can easily get your Flutter app up and running on our feature flagging platform using our client library with preconfigured methods to implement the Decision API.

Article

13min read

What Are the Best Git Branching Strategies

In modern software development, speed and agility are crucial when it comes to developing and releasing software. However, when you have a large team of developers working simultaneously, branching and merging code can become messy fast. 

Therefore, teams need to have a process in place to implement multiple changes at once. This is where having an efficient branching strategy becomes a priority for these teams.

If you’re looking to enhance your team’s development workflow and streamline release processes, book a free demo to see how AB Tasty can help.

What is a branching strategy?

Branches are primarily used as a means for teams to develop features giving them a separate workspace for their code. These branches are usually merged back to a master branch upon completion of work. In this way, features (and any bug and bug fixes) are kept apart from each other allowing you to fix mistakes more easily.

This means that branches protect the mainline of code and any changes made to any given branch don’t affect other developers.

A branching strategy, therefore, is the strategy that software development teams adopt when writing, merging and deploying code when using a version control system.

It is essentially a set of rules that developers can follow to stipulate how they interact with a shared codebase.

Such a strategy is necessary as it helps keep repositories organized to avoid errors in the application and the dreaded merge hell when multiple developers are working simultaneously and are all adding their changes at the same time

Such merge conflicts would eventually deter shipping code quickly and thus hindering from creating and maintaining an efficient DevOps process as the whole purpose of DevOps is creating a fast workflow that would allow for the release of small batches of code.  

Thus, adhering to a branching strategy will help solve this issue so that developers can work together without stepping on each other’s toes. In other words, it enables teams to work in parallel to achieve faster releases and fewer conflicts by creating a clear process when making changes to source control.

When we talk about branches, we are referring to independent lines of code that branch off the master branch, allowing developers to work independently before merging their changes back to the code base.

In this post, we will outline some of the branching strategies that teams use in order to organize their workflow where we will look at their pros and cons and which strategy you should choose based on your needs, objectives and your team’s capabilities.

Why you need a branching strategy

As mentioned above, having a branching strategy is necessary to avoid conflicts when merging and to allow for the easier integration of changes into the master trunk.

A branching strategy aims to:
  • Enhance productivity by ensuring proper coordination among developers
  • Enable parallel development
  • Help organize a series of planned, structured releases
  • Map a clear path when making changes to software through to production
  • Maintain a bug-free code where developers can quickly fix issues and get these changes back to production without disrupting the development workflow


In short, implementing effective Git branching strategies is crucial for streamlined collaboration. Complementing this with robust Feature Experimentation allows teams to test and deploy features confidently, ensuring optimal performance across all channels

Git branching

Branches are not just exclusive to Git. However, in this article we focus on Git due to the many advantages this model of branching offers.

Consequently, before we delve into the various branching strategies out there, including Git branching strategies, we will take a look at how Git actually handles branches and why it’s a standout among other VCS tools.

Put simply, Git and other version control tools allow developers to track, manage and organize their code.

Git branches allow developers to diverge from the main branch by creating separate branches to isolate code changes. The default branch in Git is the master branch. 

The biggest advantage of a Git branch is that it’s ‘lightweight’, meaning that data consists of a series of snapshots so with every commit you make, Git takes a picture of what your files look like at that moment and stores a reference to that snapshot. This means that these branches aren’t just copies of the file system but simply a pointer to the latest commit. 

Meanwhile, other VCS tools store information as a list of file-based changes which may slow things down and use up significant space. 

In Git, a branch is essentially a reference or a pointer to the latest commit in a given context; it’s not a container for commits. As you create new commits in the new branch, Git creates new pointers to track the changes. Git branches, then, can be seen as a pointer to a snapshot of your changes. 

The images below illustrate this concept, where the top image shows the master branch and a pointer pointing to the last commit and the image right below it shows what happens when you create a new branch called ‘dev’- a new pointer now points to the latest commit.

Master Branch Illustration

To sum up, the Git branching model is lightweight compared to other version control systems; this is why it’s so easy and cheap to create branches in Git, as the whole code doesn’t need to be copied to the branch creating a large amount of duplicate files, as opposed to other VCS tools.

What are some common Git branching strategies?

GitFlow

Considered to be a bit complicated and advanced for many of today’s projects, GitFlow enables parallel development where developers can work separately from the master branch on features where a feature branch is created from the master branch.

Afterwards, when changes are complete, the developer merges these changes back to the master branch for release.

This branching strategy consists of the following branches:

  • Master 
  • Develop
  • Feature- to develop new features that branches off the develop branch 
  • Release- help prepare a new production release; usually branched from the develop branch and must be merged back to both develop and master
  • Hotfix- also helps prepare for a release but unlike release branches, hotfix branches arise from a bug that has been discovered and must be resolved; it enables developers to keep working on their own changes on the develop branch while the bug is being fixed.

The main and develop branches are considered to be the main branches, with an infinite lifetime, while the rest are supporting branches that are meant to aid parallel development among developers, usually short-lived.

Git Branching Illustration
Author: Vincent Driessen
source
License: Creative Commons BY-SA

GitFlow pros and cons

Perhaps the most obvious benefit of this model is that it allows for parallel development to protect the production code so the main branch remains stable for release while developers work on separate branches.

Moreover, the various types of branches make it easier for developers to organize their work. This strategy contains separate and straightforward branches for specific purposes though for that reason it may become complicated for many use cases. 

It is also ideal when handling multiple versions of the production code.

However, as more branches are added, they may become difficult to manage as developers merge their changes from the development branch to the main. Developers will first need to create the release branch then make sure any final work is also merged back into the development branch and then that release branch will need to be merged into the main branch.

In the event that changes are tested and the test fails, it would become increasingly difficult to figure out where the issue is exactly as developers are lost in a sea of commits.

Indeed, due to GitFlow’s complexity, it could slow down the development process and release cycle. In that sense, GitFlow is not an efficient approach for teams wanting to implement continuous integration and continuous delivery. 

Thus, in that case a much simpler workflow such as GitHub Flow is recommended.

GitHub Flow

GitHub Flow is a simpler alternative to GitFlow ideal for smaller teams as they don’t need to manage multiple versions.

Unlike GitFlow, this model doesn’t have release branches. You start off with the main branch then developers create branches, feature branches that stem directly from the master, to isolate their work which are then merged back into main. The feature branch is then deleted.

The main idea behind this model is keeping the master code in a constant deployable state and hence can support continuous integration and continuous delivery processes.

Git Branching Illustration

GitHub Flow pros and cons

Github Flow focuses on Agile principles and so it is a fast and streamlined branching strategy with short production cycles and frequent releases. 

This strategy also allows for fast feedback loops so that teams can quickly identify issues and resolve them.

Since there is no development branch as you are testing and automating changes to one branch which allows for quick and continuous deployment.

This strategy is particularly suited for small teams and web applications and it is ideal when you need to maintain a single production version.

Thus, this strategy is not suitable for handling multiple versions of the code.

Furthermore, the lack of development branches makes this strategy more susceptible to bugs and so can lead to an unstable production code if branches are not properly tested before merging with the master-release preparation and bug fixes happen in this branch. The master branch, as a result, can become cluttered more easily as it serves as both a production and development branch.

A further disadvantage is as this model is more suited to small teams and hence, as teams grow merge conflicts can occur as everyone is merging to the same branch and there is a lack of transparency meaning developers cannot see what other developers are working on.

GitLab Flow

GitLab Flow is a simpler alternative to GitFlow that combines feature-driven development and feature branching with issue tracking.

With GitFlow, developers create a develop branch and make that the default while GitLab Flow works with the main branch right away.

GitLab Flow is great when you want to maintain multiple environments and when you prefer to have a staging environment separate from the production environment. Then, whenever the main branch is ready to be deployed, you can merge back into the production branch and release it.

Thus, this strategy offers propers isolation between environments allowing developers to maintain several versions of software in different environments.

While GitHub Flow assumes that you can deploy into production whenever you merge a feature branch into the master, GitLab Flow seeks to resolve that issue by allowing the code to pass through internal environments before it reaches production, as seen in the image below.

Therefore, this method is suited for situations where you don’t control the timing of the release, such as an iOS app that needs to go through the App store validation first or when you have specific deployment windows.

Trunk-based development

Trunk-based development is a branching strategy that in fact requires no branches but instead, developers integrate their changes into a shared trunk at least once a day. This shared trunk should be ready for release anytime.

The main idea behind this strategy is that developers make smaller changes more frequently and thus the goal is to limit long-lasting branches and avoid merge conflicts as all developers work on the same branch. In other words, developers commit directly into the trunk without the use of branches.

Consequently, trunk-based development is a key enabler of continuous integration (CI) and continuous delivery (CD)  since changes are done more frequently to the trunk, often multiple times a day (CI) which allows features to be released much faster (CD).

This strategy is often combined with feature flags. As the trunk is always kept ready for release, feature flags help decouple deployment from release so any changes that are not ready can be wrapped in a feature flag and kept hidden while features that are complete can be released to end-users without delay. 

Trunk-based development pros and cons

As we’ve seen, trunk-based development paves the way for continuous integration as the trunk is kept constantly updated.

It also enhances collaboration as developers have better visibility over what changes other developers are making as commits are made directly into the trunk without the need for branches. This is unlike other branching methods where each developer works independently in their own branch and any changes that occur in that branch can only be seen after merging into the main branch.

Because trunk-based development does not require branches, this eliminates the stress of long-lived branches and hence, merge conflicts or the so-called ‘merge hell’ as developers are pushing small changes much more often. This also makes it easier to resolve any conflicts that may arise.

Finally, this strategy allows for quicker releases as the shared trunk is kept in a constant releasable state with a continuous stream of work being integrated into the trunk which results in a more stable release.

However, this strategy is suited to more senior developers as this strategy offers a great amount of autonomy which non-experienced developers might find daunting as they are interacting directly with the shared trunk. Thus, for a more junior team whose work you may need to monitor closely, you may opt for a Git branching strategy. 

Additionally, in fast-paced environments using trunk-based development, feature flags can provide the flexibility needed to ship incomplete features safely.

How to choose the best branching strategy for your team

When first starting out, it’s best to keep things simple and so initially GitHub Flow or Trunk-based development may work best. They are also ideal for smaller teams requiring only a single version of a release to be maintained. 

GitFlow is great for open-source projects that require strict access control to changes. This is especially important as open-source projects allow anyone to contribute and so with Git Flow, you can check what is being introduced into the source code.

However, GitFlow, as previously mentioned, is not suitable when wanting to implement a DevOps environment. In this case, the other strategies discussed are a better fit for an Agile DevOps process and to support your CI and CD pipeline.

The following table summarizes the strategies discussed in this article and which strategy is appropriate in which context:

Product type and its release methodTeam sizeCollaboration maturityApplicable mainstream branch mode
AllSmall teamHighTrunk-Based Development (TBD)
Products that support continuous deployment and release, such as SaaS productsMiddleModerateGitHub-Flow and TBD
Products with a definite release window and a periodic version release cadence, such as iOS appsMiddleModerateGit-Flow and GitLab-Flow with release branch
Products that are demanding for product quality and support continuous deployment and release, such as basic platform productsMiddleModerateGitLab-Flow
Products that are demanding for product quality and have a long maintenance cycle for released versions, such as 2B basic platform productsLargeModerateGit-Flow

To sum up, there is no such thing as the perfect strategy. The strategy you choose will depend on your team and the nature and complexity of your project and so this should be evaluated on a case-by-case basis.

It’s also fine to start off with one strategy and adapt it over time according to your needs. Needless to say, whatever strategy you end up choosing should aim to increase your team’s productivity by giving them a clear and consistent strategy to organize their work.

? Pro Tip: Want to personalize developer experiences across branches or environments? Explore our Personalization Guide for insights.

Article

11min read

Test Environments: Differences Between Dev, Staging, Preprod…

During software development, software goes through a series of stages. Testing, for its part, is a critical stage of the software development life cycle as it can determine the quality of the software that is to be released to live production environments.

In this article, we will be focusing on test environments and the types of testing that can be run in such environments and why test environments are an important part of your software pre-release strategy.

What is a test environment?

Once software tests are designed, they need an interface where they can be run or executed; this is what is referred to as a test environment.

A test environment is basically a combination of hardware, software, data and configurations in order to run tests.

Test environments need to be configured according to the needs of the software being tested and must be set to ensure that the software operates in the right conditions. In other words, there is no one-size-fits-all solution as it is the code that dictates the environment’s setup.

Thus, no two test environments are the same as they require a different setup to test different parts of the code- the parts that make the whole.

Certain test cases may also require the environment to be prepared according to a particular set of data. This is what is referred to as a test bed. Thus, a test bed is a test environment prepared with test data to help you identify cases requiring a particular data setup.

The main purpose of such environments is to allow QA teams to check system components and uncover errors and issues so the environment must closely replicate real user conditions. Once issues are detected, they can be fixed without affecting real users and negatively impacting their experience.

The elements of a test environment include the following:

  • The software to be tested
  • Test data
  • Network configuration
  • Device on which the software is to be tested
  • Database server

Types of environments

Before we delve deeper into test environments, we will first discuss the types of environments that precede and follow test environments. In this context, environments refer to the server location of the application or software, which are divided according to the state of the software.

Generally speaking, there are four types of environments in software development:

  • Development
  • Testing
  • Staging
  • Production

We will briefly go through each of these environments to better understand how they are linked to distinct stages in the release process.

Development environment

As the name suggests, this is where the development of the software takes place. It is the first environment where developers write the first lines of code and do all the code updates.

This environment usually consists of a server that is shared by several developers working together on the same project.

Therefore, when multiple developers are involved, a developer would have a copy of the source code on their own machine and then changes are submitted to the repository which are then integrated into the trunk or branch.

A number of preliminary testing takes place at this stage before moving on to the next stages.

For example, if developers have adopted a continuous integration methodology for their software development process then several changes daily would be committed to the trunk.

Testing environment

The testing environment allows QA engineers to test new and changed code whether via automated or non-automated techniques.

Development environments are ever-changing as developers keep adding new functionalities which makes it difficult for QA teams to run time-consuming tests so a testing environment is where they can execute more complex and time-consuming tests.

The code at this stage usually goes through more than one QA environment where unit tests are first conducted and the code is moved to further test environments.

Thus, you can either run tests one after the other or you can create several testing environments that allow for parallel testing to take place, depending on the sophistication of your testing environment.

More details about the different types of software tests will be discussed in the next sections.

Nonetheless, the focus here is testing individual components rather than the entire application, to check the compatibility between old and new code, the system’s performance and so on.

If there is a test failure, the faulty code can be removed in this environment. Thus, testers can ensure the quality of the code by finding any bugs and reviewing all bug fixes. However, if all tests pass, the test environment can automatically move the code to the next deployment environment.

Staging environment

This environment is a nearly exact replica of the production environment so it seeks to mirror an actual production environment as closely as possible to ensure the software works correctly.

The staging environment is often restricted to a small number of selected users and so it is limited to certain IPs and developer teams.

The purpose of this environment is to test on a near-production level but in a non-production environment to verify that the application will behave correctly after deployment. Thus, it represents a safe space away from the public eye to make sure everything works as expected; it is kept invisible from end-users.

The focus here is to test the application or software as a whole. In other words, staging environments are where you can conduct tests to ensure that no problems come up in production and limit negative impact on users there so that when the software is deployed to the production environment, there will be fewer errors to fix.

Examples of the kind of test that can be run in this environment include smoke testing and in particular load testing since it can be difficult to replicate high volumes of traffic in a staging environment to test the software or application under stress.

However, keep in mind that a staging environment is not meant to be a substitute for a real-world production environment.

To ensure your product works as it should, you need both a testing and staging environment, where the testing environment makes sure that every component does its job while the staging environment ensures that your software would behave correctly in an environment almost exactly the same as production.

While you can run many tests in a staging environment, the best way to truly determine how a feature performs is to test it on users in real-time, for example, through testing in production.

Production environment

This is where the software is produced and is running on a production server. It has officially gone live to real users.

When deploying a new release to production, rather than immediately deploying to all users, the release can be deployed in phases to a segment of your users first to see how it performs to catch and fix any additional bugs before deploying to the rest of your users.

In other words, just because you’re in the production environment, it doesn’t mean tests have to end here. You can and should still be testing in production. This can be done with the help of feature flags, which allow you to safely test in production on a pre-selected number of users.

Now that we’ve covered the main environments a software progresses through in its lifecycle, we will turn back to test environments and the type of testing that can be conducted in that particular environment.

Why is software testing required?

While we’re big advocates of testing in production, we acknowledge that some cases require dedicated test environments before moving forward onto production environments.

Before we move further to the types of software tests, it is important to shed light on why software testing is an essential modern software development practice. Choosing to skip this process is not advisable and may end up negatively impacting your products and business.

Before we move further to the types of software tests, it is important to shed light on why software testing is an essential modern software development practice. Choosing to skip this process is not advisable and may end up negatively impacting your products and business.

Below are just some of the reasons why software testing is so imperative nowadays:

  • Cost effective– testing your software will end up saving you money in the long run as testing the software will allow you to uncover bugs early on when it would cost less to fix them.
  • Security– software testing ensures that the software you’re releasing is free of any issues and thus you can guarantee your customers that your products are trust-worthy and safe to use.
  • Product quality-as software goes through continuous and diversified levels of testing, this ensures that bugs are detected along the software’s development process resulting in higher quality products.
  • Customer satisfaction– one of the main reasons tests are conducted are to ensure they provide the best user experience possible by making sure that the releases are stable and without any issues thereby achieving customer satisfaction.
  • Continuous delivery– an efficient setup of software testing would allow developers to push code changes into a CI/CD pipeline to go through the various levels of testing. If the code passes the tests, it can be automatically into production and if it fails it would notify developers so that they fix the issue. In other words, setting up automated testing allows you to maintain continuous delivery and to deliver higher-quality releases to end-users quickly.

Meanwhile, having a test environment to run these tests is essential as it provides you with a dedicated environment where you can isolate the code and verify the behavior of the application so it provides you with accurate feedback about the quality and performance of the software you’re testing.

Types of software testing

There are different types of tests that help analyze various elements of the software such as performance, security and user experience.

While a staging environment allows teams to replicate real testing conditions, tests will still need to be run beforehand to test its individual components to make sure that it all works well together to satisfy quality assurance requirements.

Below, we will highlight some of the most common tests which can be run during the software’s lifecycle:

Performance testing

These tests measure how fast an application responds to an interaction and so various aspects of the application such as page load speeds, stability and reliability are tested so that developers can make improvements as needed.

System integration testing

The main purpose of this testing is to ensure that all modules of an application work together smoothly and can communicate with each other. The interaction with the database is also tested.

Thus, it is all about making sure that the individual parts can function together as a whole.

User acceptance testing (UAT)

This testing is conducted to ensure that the application meets the business requirements of users and to ensure that functionalities of the application achieves customer satisfaction. UAT requires the whole application to be up and running and so usually represents the final stage of testing.

This type of testing also usually requires a staging environment- identical to a production environment but not accessible to end-users.

Alpha testing

After user acceptance testing is carried out within the development and product teams, testing can be expanded to include other kinds of users.

During Alpha testing, the release is tested outside of the teams involved in the project. It is typically conducted on internal users or employees within the organization and is usually followed by beta testing.

This test helps identify any bugs or issues before finally releasing the software to the end-user.

It attempts to simulate a real user environment by carrying out the same tasks and operations that the actual user will perform within the release to make sure it satisfies all of its functionalities.

Beta testing

In this testing environment, the software is released to a limited number of real-world users outside the organization to obtain their feedback which is then forwarded back to developers to optimize and improve the release as needed before releasing to all users.

It also tests the application or software under stress, where such load testing will help uncover any bugs that were not previously spotted.

Read more: Difference between alpha and beta testing

Test environments best practices

As we’ve seen, testing is an essential part of the software development life cycle and so test environments must be efficient and reliable to ensure the quality of your products and they must be well-managed.

In this section, we’ll highlight some of the essential best practices for test environment management:

First, it is important you start testing early on in the development process. In other words, don’t wait too long to run tests on every commit.

Otherwise, when teams don’t test early, they end up with a number of bugs later on and at that point fixing these bugs would require a lot of time, cost and effort.

Second, try to reduce manual processes by introducing more automation as that will save you time and resources while your team can dedicate their time to building and improving the product instead of tedious manual tasks.

Furthermore, before creating yet another new test environment, verify if it’s possible to use an existing one. If you already have an existing infrastructure, then that will go a long way in saving you time and money.

Another thing to verify is that you actually have all the required software and hardware, which includes physical servers, licenses, operating systems, etc.

It also goes without saying that you need to consider how to ensure the maintenance of the test environment such as who’s responsible for its maintenance and how to ensure the reliability of the environment.

The main takeaway here should be to


Test, test and then test some more starting early on in the software development process.

To reiterate, test environments represent an efficient and a safe space to conduct all your essential and most basic tests.

However, don’t forget that just because you think you have run a sufficient number of tests in your test environment that you should discard testing in production altogether.

Yes, test environments are great for ruling out bugs early on but they are not an actual production environment. The best way to guarantee the quality of your products is to test them on a segment of your users during production, i.e in the production environment.

You can now do this safely with feature flags, which allow you to test on a small segment of users and disable any buggy features instantly.

Find out how AB Tasty leverages the power of feature flags to safely test new features in production by signing up for a free trial now.

Article

6min read

Best Resources on Feature Flags: Our Top Picks

The topic of feature flags is gaining popularity with developers and marketers alike using these flags to test and deploy safely in production among other many uses.

In this article, we’ve decided to compile our top picks of the best content out there on feature flags for your reading pleasure. 

Whether your team has already been using feature flags to safely release new software or whether you’re just tentatively dipping your toes and looking to get more information on this powerful software development tool, you’re bound to find something in our selection that best suits your needs.

So, without further ado and in no particular order, here are our top picks:

1. Feature Toggles (aka Feature Flags)

By: Pete Hodgson (Twitter; LinkedIn)

This is certainly one of the most popular articles about feature flags. Indeed, a quick Google search will always include an article from Martin Fowler and his many articles written by him or by colleagues on the software development life cycle and how to build software effectively.

Why we picked it:

It’s a no-brainer. This article, one of the oldest out there first published back in 2016, is a classic and explains in great detail and clarity the topic of feature toggles or flags from their birth to their different categories and implementation techniques.

In our opinion, this is a great article especially for those trying to become more acquainted with this topic. It also uses simplified figures for easier understanding.

2. Feature Flag, What? Why? How?

By: Hicham Bouissoumer & Nicolas Giron

Why we picked it:

This is another great article that breaks down the complexity of feature flags from what they are to their importance and the different ways to implement them.

It’s a good starting point for anyone who’s just embarking on their feature flag learning journey.

3. How we ship code faster and safer with feature flags

By: Alberto Gimeno

GitHub, a provider of internet hosting for software development, provides excellent resources to help developers build and develop software, among which highlight the topic of feature flags.

Why we picked it:

We always think the best way to truly understand something is by providing concrete and practical examples. This is what this article from a company in the industry does. 

This article paints a clear picture of the uses and benefits of feature flags by illustrating how GitHub reaps the benefits of these flags in its deployment processes. It explains in great detail how feature flags have allowed them to efficiently work on new features and to test these features, thereby inviting developers to embrace this software development methodology in their own releases.

4. Feature Flags are Valuable for Managers as Well as Developers

By: Micaël Paquier  

Why we picked it:

We’ve often heard about how developers use feature flags as they are the ones coding them. However, product and marketing teams have long started to recognize the benefits of using feature flags themselves to test out their ideas on customers. A sophisticated feature flagging platform, in particular, allows different teams to access and control flags (and not just developers). 

Therefore, the author argues that feature flags are a major win not only for developers but also product managers by boosting productivity and reducing the stress of new releases. The article also weighs in on the infamous build vs buy decision. 

5. Feature Flags: Be Truly Agile

By: Kevin Ghadyani (Twitter; LinkedIn) 

Why we picked it:

This article really lays out the value behind feature flags by depicting how each team within an organization utilizes them to solve many issues that usually come up in development, making life much easier for these teams. 

Much like the previous article, it highlights the importance of feature flags and how they have revolutionised the Agile development process.

6. The Many Uses of Feature Flags to Control Your Releases

By: our very own team at AB Tasty

We have carefully crafted a platform to suit both development and product teams and equip them with the right tools to safely deploy code into production and eliminate the risk of new releases. 

Why we picked it:

At the risk of tooting our own horn, we think that this article on our blog covers a wide range of use cases that could be implemented using feature flags from preparing for launch to other scenarios where such flags could come in handy, targeted towards both product and development teams.

7. Remote Feature Flags Do Not Always Come for Free

By: Josef Raska (Twitter; LinkedIn)

Why we picked it:

This article provides an interesting discussion on the benefits of feature flags while acknowledging their potential costs and listing the requirements that should be put in place to carefully manage these flags to avoid the build-up of heavy costs over time. Among such requirements include documenting when a flag is introduced and setting an owner for each flag to be able to make the decision to remove the flag when it is no longer needed.

8. Introducing Piranha: An Open Source Tool to Automatically Delete Stale Code

By: Murali Krishna Ramanathan, Lazaro Clapp, Rajkishore Barik, & Manu Sridharan

Why we picked it:

You might have already come across the dreaded ‘technical debt’. In this article, the engineering team at Uber tackles the dark side of feature flags and how they developed a tool in order to deal with the issue of removing stale feature flags to prevent accumulation of this debt.

Piranha is an open-source tool but it’s currently only available for Objective-C, Swift, and Java programs. 

Nonetheless, we think that this article provides a detailed look into the issue of technical debt and why it’s important to keep track of feature flags, particularly stale ones, in your code.

Conclusion

And there it is: our non-exhaustive list of our favorite posts that cover the ever-expanding and fascinating topic of feature flags! 

Why not sign up for a free trial and start your feature flag journey with us today?

Article

11min read

Best Feature Management Tools

Feature management tools have become valuable for modern development teams. With such tools, teams now have a way to push releases safely and quickly with more confidence than ever before.

These tools provide a safe and efficient way to toggle features on and off targeting a specific set of users while fixing bugs without any disruption to users.

Furthermore, many of these tools provide an easy-to-use dashboard that can be used by all teams, even the less technical product teams, allowing them to release features at their own pace without relying too much on development teams to do it for them.

Feature management softwares, in that sense, pave the way for feature testing enabling product teams to experiment and test their ideas so that they may deliver high quality software that customers actually want.

Undoubtedly, with the many benefits that come with such tools, there are many options to choose from that you may find yourself at a loss at which one to opt for.

In this post, we will list the many tools out there and their main features so that you can decide which is best suited for your organization and unique needs.

What is feature management?

First, we will start off with what exactly we mean by the term ‘feature management’ before we move onto our list.

The term feature management encompasses software development tools that allow teams to better manage the rollout and roll back of features.

These tools provide a framework for feature flag-driven development meaning that teams can use flags on a wide scale to manage features across a wide variety of use cases.

Teams that implement such tools see higher productivity and an increase in software quality as they enable continuous testing of releases through gradual roll out of these releases to subsets of users.

As already mentioned, this allows teams, particularly product teams, to continuously test out their ideas through techniques such as A/B testing and experimentation and optimize products accordingly.

The core of feature management: Feature flags

Just as a quick recap of feature flags: feature flags are basically if-else statements that decouple deployment from release providing teams with full control over which users see which features.

When you’re just starting out, you’ll implement a feature flag from a config file with an easy on/off toggle to test and roll out new features.

However, at some point, things may become more complicated as your use cases evolve making flags harder to manage.

As you start to realize the value of feature flags in your experimentation roadmap, adopting the right feature management tool will help you manage hundreds, if not thousands, flags across several teams. Eventually, you will need to retire some of these flags, lest they accumulate into technical debt

The key to managing all these active flags in your system is to opt for a more comprehensive feature flag management tool.

Feature flag management tools: Our top picks

Without further ado, we will present you with a list of tools that are worth looking into. Note that there is no particular order to this list.

Instead, we will lay out the tools highlighting their main features (and when they might come particularly handy) so you can decide which one best suits your objectives and teams’ capabilities.

LaunchDarkly

Launchdarkly is a feature management platform that is jam-packed with features for safe testing in production. The platform is made to integrate seamlessly into your existing software development workflow.

Some of the features you can expect from the platform:

  • Target specific users based on built-in user attributes
  • Run sophisticated A/B/n tests for data-driven product decisions
  • Integrate with other tools to enhance monitoring and collaboration
  • A number of SDKs that can be used for a variety of programming languages and platforms 

The platform was built with developers in mind so that they may ship code whenever they want but is also suited for all teams across an organization so that they can also control and release software. It’s a good choice for those looking for advanced feature management capabilities to run more sophisticated experiments.

Pricing

The platform offers 3 tiers of pricing based on team size with basic functionality on the starter plan and more advanced functionalities at the enterprise level. They come with a 14-day free trial period. However, the payment is distributed per number of seats so you are limited to the number of seats per account and reach is capped at a maximum of 1000 client-side monthly active users (MAUs) in the cheaper plans.

Split

Split is a feature delivery platform ‘built by developers for developers’. The platform can be easily adapted to your workflow allowing teams to set up and manage flags to streamline deployment of features and maximize business impact throughout the feature delivery lifecycle.

Some of the core features of this platform include:

  • Provides instant alerts for performance issues with any features released
  • Comes with a kill switch to disable a faulty feature
  • Allows for user targeting through percentage rollouts to minimize blast radius
  • Pairs with a number of data pipelines to measure impact of each feature
  • Scales across multiple teams and environments

This solution is ideal for engineering teams that want to deliver features quickly and safely through ‘impact-driven development’. By helping to reduce the engineering cycle duration, this frees up engineering teams to solve business and customer problems.

It is also suited for teams working in more ‘sensitive’ industries that are looking to have extra security to protect and have control of the data that is sent to the platform.

Pricing

Split offers a free plan that accommodates up to 10 seats and a Platform Edition plan based on the number of Monthly Tracked Keys (MTKs) evaluated by the platform. It includes 25 seats and a 30 day trial.

Optimizely

Optimizely Rollouts

Optimizely is a digital experience platform that provides teams with insights to personalized experiences. Although it’s not primarily a feature management tool, it provides these teams with feature management capabilities to test features. These include feature flags that allow you to run A/B tests, staged rollouts and target rollouts by audience.

Among the features you can find in this platform include:

  • Manages all features in one place within a single interface
  • Ability to switch off features without redeploying code
  • Offers a Stats Engine that deviates from traditional statistical methods for more accurate and actionable results that is a better fit for digital data
  • Provides a marketer-friendly UI for marketing teams to manage features and tests independently

This platform is suitable for teams looking for a full stack experimentation platform beyond feature management. It is particularly suited to product and marketing teams so that they can run advanced A/B tests across all customer touchpoints to uncover insights for better decision-making.

Pricing

While pricing is not revealed (it must be requested), there are 3 plans that companies can consider, among which include the Intelligence Cloud plan which offers feature management capabilities. Optimizely also offers free feature flagging as part of Optimizely Rollouts, on top of the paid Optimizely Full Stack, which comes with unlimited seats and feature flags.

CloudBees

Cloudbees feature flags

CloudBees is a software delivery platform whose purpose is to enable automation so that developers can focus on creating and delivering software. The platform also comes with a feature management solution that allows for progressive delivery of features with advanced user testing based on any criteria in your database.

Other notable features that come with the feature management solution include:

  • Percentage rolling releases that provides feedback from live users
  • Customer data security-locally available attributes for targeting are not transmitted back to the platform
  • Kill switch without redeploying when a feature doesn’t work as expected 
  • Developer-friendly workflows allowing developers to edit flags without using dashboards
  • Visibility of feature flag usage across all teams

This tool is ideal for large organizations with multiple teams seeking to improve visibility and governance across these teams in order to enhance collaboration and speed of software delivery.

Pricing

CloudBees’ feature management solution comes with the usual 3 plans other tools have adopted, beginning with a free Community plan for up to 15 users user followed by Team, up to a maximum of 25 users, and Enterprise plans for more than 25 users.

Harness

Harness feature flag platform

Harness is a software delivery platform that also provides feature flags as part of its product, which was designed for developers to be used as a simple and scalable feature management solution. 

Some features that come with this platform include:

  • End-to-end visibility from build to release
  • Native integration with CI/CD
  • Integrates to existing developer workflow tools such as Jira and Slack
  • Reusable feature templates that can be standardized across different features

This tool is ideal for developers looking to automate their processes including flag life cycle management for future feature releases. It is also suited for teams wanting to manage all their processes in a single, integrated pipeline.

Pricing

Harness feature flags comes with 3 plans, starting with the free plan with just 2 developer licenses and up to 25K client-side MAUs followed by the Team, limited to 50 developer licenses and Enterprise plans that comes with a 14-day free trial.

AB Tasty

Flagship - Feature Management Platform

Last but not certainly not least is our own feature flagging platform to safely turn features on or off but that’s not all it is. AB Tasty is your one-stop solution for all your experimentation needs that was made with not only developers in mind but also to satisfy your product and marketing needs. It also comes with dedicated support to help you get set up.

Our server-side solution is designed for modern teams to deploy releases faster multiple times a day and reduce the risk that usually comes with testing in production.

The platform comes packed with features, which include:

  • Update flags without the need to change code or redeploy
  • User targeting and progressive rollouts based on user attributes- time-based deployment and gradual percentage rollout
  • Ready-to-use templates to speed up workflows
  • Kill switch in case an issue comes up
  • Visual dashboard to comfortably analyze feature performance, set goals and track them with real-time reports
  • Full visibility over all flags to easily create and manage flags
  • Server-side A/B tests with deep-level modifications beyond cosmetic changes
  • Option of rollback KPI to automatically turn off a feature/flag if metric crosses a certain threshold

Our feature flagging platform is particularly great for product teams wanting to delve into more advanced server-side A/B testing and experimentation as the easy-to-use dashboard can be used by all teams across an organization without any fuss. 

The platform basically allows you to designate who has access to the platform determined by ‘role’ so that people across your team can track the different flags for easier and more efficient management. 

Pricing

When it comes to pricing, there is a Premium plan and a custom-priced Enterprise plan based on the number of monthly active users. Unlike most other tools’ pricing plans, the plans come with a longer, 30-day free trial period to get a taste of AB Tasty and what it can do for you.

Our feature management solution comes with a host of features to help you advance your experimentation capabilities to release your software quickly and safely. 

But don’t just take our word for it, sign up for your 30-day trial and see for yourself what our solution can do for you and find out how we stack up against our competitors.

Which is the best tool for you?

That depends. All the tools listed offer teams great capabilities, most prominent is releasing features safely and quickly through progressive delivery. If this will be the main focus for you, then opting for a simple solution focusing on toggling flags on or off is a good option.

However, if you’re looking for more advanced features, specifically for product and marketing teams to be able to test various releases across the full software stack, particularly on the server-side, and monitor their performance by tracking KPIs then going for a platform that offers deeper experimentation options is the best way to go.

All in all, it will ultimately depend on where you are in your experimentation roadmap and how far you want to delve into it.

Article

8min read

Release Management with Jira Software

As organizations increasingly adopt an Agile methodology into their software development processes, this means that teams are now releasing more frequently in smaller batches.

Therefore, changes are being merged into the mainline multiple times a day making it difficult to determine when changes are actually being rolled out.

The developers usually aren’t the only ones who need to know about the release of new changes or features. Product teams are also just as involved in the release process. 

As we’ve seen in our release management guide, the product manager is the one who plans releases and will oversee the feature or product as it moves through the different stages of the software development life cycle.

With such frequent releases, things can become highly stressful. Fortunately, nowadays, teams can automate these processes, freeing them up to focus on more important and less repetitive tasks.

One such software is the Jira platform that can contribute to better, more efficient releases.

In this article, we will look into just how you can incorporate Jira software into your release management process to help improve collaboration and communication between your teams.

Jira software overview

First, we will start with a quick overview of Jira software. Created by Atlassian, this software helps you plan, track and release software in software development projects. 

It is one of the most popular tools used by Agile teams to manage their releases by offering all team members full visibility over the release process, enhancing collaboration between engineering and product teams to plan and track releases and increase productivity across the organization.

Initially, this software was developed to track issues and bugs and has since evolved into a work management tool for a wide range of use cases.

When it comes to product management, Jira can be used to build roadmaps for each project allowing teams to track and share their progress for the roadmap.

Jira takes a customer-centric approach when it comes to designing projects and it’s highly customizable making it a popular tool among Agile teams to incorporate into software development processes.

Getting started with Jira

You will start by creating a project, where you will pick a template depending on your team’s requirements. You can choose from scrum, kanban and bug tracking. For every project, Jira creates a board to help you see a visual representation of your work. 

Before you create a project, consider how you will organize your projects. The best way to do so is to organize your projects according to how your company runs; whether, for example, you’d rather organize by product if you’re constantly releasing software or if you’d rather organize by team.

To manage releases in Jira, the first step is to create a version.

Jira release management software

To do so, click on ‘Releases’ as can be seen in the image above, where you will be prompted to create name, start & end dates and description. 

You can then assign any issue type to the releases to track their statuses throughout their life cycle. 

The release could contain tasks with different statuses such as in progress or closed.

Better release management with Jira

Jira issues

An issue is a work item that can be tracked throughout its life cycle. It can, for example, be a product feature or software; issues are essentially the building blocks of your Jira software project. It can also be referred to as a task, request or ticket.

Jira issue allows you to track individual pieces of work that should be completed. Thus, it notifies your team of any updates by allowing them to track the issue and lets them know if there are any comments or of any change in update status.

Jira workflows

Jira provides a way to customize the way issues transition through the development phases, also referred to as workflows. These can be customized to suit the needs of your project.

Since the Jira platform is flexible, you can add more statuses to track which issues are included in a specific release.

The default Jira platform has three default statuses:

Jira workflows

A few more statuses can be added to help teams track the status of their work more precisely. Thus, more statuses can be added such as:

  • Awaiting release
  • Ready to merge 

Once your team becomes more comfortable with the basic workflow, optimize it by creating statuses for each type of work in the process. Build, design, development, code and test can all, for example, be individual statuses, which can then be shared with the rest of the organization.

Roadmaps in Jira

In our release management guide, we mentioned how essential a product roadmap is to ensure the success of your products. 

Roadmaps in Jira help teams see the bigger picture when it comes to their work and how they’re contributing to larger business goals.

Thus, a roadmap will help illustrate your team’s strategic vision to all relevant stakeholders. It gives your team a single, shared source of truth that outlines the direction and progress of a product or team over time to ease cross-team communication and help release more predictably.

Advanced Roadmaps in Jira loads your Jira issues into your plan and suggests releases you can work with, allowing you to track the progress of your releases and determine if they’ll be completed on time.

Tracking releases

You can run a release report in Jira at any time. This report will show you how many total issues there are in the release broken down by how many are in progress or completed.

Jira and feature flags

It is possible to apply feature flags to Jira issues. There, you would be able to monitor your flag’s rollout status from your Jira issue. You would even be able to roll out a feature to a certain subset of users.

Feature flags at their simplest level are if/else statements that allow you to decouple deployment from release giving you more control over the release process so that you can ship changes in code confidently and safely.

Using Jira for feature flags has many advantages, primarily allowing teams full visibility over what features have been released or in the process of being released, all from a single place. Thus, it fosters collaborations so that teams can work together efficiently.

Connecting Jira to feature flags gives your team immediate insight into the status of releases once they are deployed. Teams then would be able to see which feature flag has been turned on and which percentage of users have access to it.

Therefore, you can create a workflow around feature flagging to track the state of each flag. This means that each time a flag is created, an issue in Jira is automatically created and as the flag is rolled out, the issue in Jira automatically moves through the workflow as can be seen in the image below: 

Jira software feature flags

Data from Jira issues allows teams to see if there are any bugs in the feature so that they may be immediately fixed before rolling out the feature to the rest of your users.

Additionally, Jira helps reduce technical debt as it enables you to develop rules of governance for feature flags so that your team knows once a flag is rolled out to 100% so that it may be removed from the system.

In other words, whenever a new feature is added to the codebase, you can assign cleanup tickets to engineering or product teams.

Conclusion

The automation capabilities that Jira brings to your releases is essential especially when it comes to managing multiple complex projects.

With feature flags, developers can have even more control over their releases so that they may launch new features quicker than ever before while receiving direct insights from their releases.

Jira as a whole allows you to manage releases according to your unique needs and objectives. It also facilitates an Agile methodology within your organization by creating Agile workflows to help release high quality software faster.

Overall, using releases in Jira significantly improves your tracking and reporting allowing you to have better coordination and planning across your releases.

Article

5min read

Top 6 Release Management Tools

In this article, we will highlight some release management tools that are essential to the success of your release with heightened velocity. A release manager will need to be familiar with at least some of these tools in order to create automated processes that result in high quality releases.

These tools help to increase speed of software delivery while reducing risk and errors. The following are our top picks to help you deploy faster and more efficiently, some of which are either open source or premium paid tools.

But before we start, here is a quick reminder about what is release management.

Release management process

In our release management guide, we mentioned what release management is, its different phases as well as the different deployment strategies to release new features to production.

As a quick recap, release management basically outlines the different phases involved in the release process of a feature from its inception to its launch. It is the process of planning and controlling software builds throughout its entire life cycle.

As organizations transition from more traditional practices of Waterfall to an Agile methodology, the goal of the release management process is now to move software builds through the various phases quicker and more frequently.

Without further ado, here is the list of our favorite release management tools.

Ansible

Ansible is an open source configuration management and application deployment tool. It has the advantage of being simple and easy to use, hence creating a collaborative environment.

This tool also enhances productivity as it eliminates repetitive tasks so that your team can focus on other more important tasks and strategic work.

Other features:

  • Comes with an agentless architecture
  • Allows you to orchestrate your app lifecycle 
  • Doesn’t require any special coding skills

Jenkins

Jenkins is one of the most popular tools currently available. A leading open source automation server, it provides hundreds of plugins to support building, automating and deploying your projects. 

This tool is easy to set up and configure and integrates with practically any tool and can be distributed across multiple machines.

It is also extensible and so can be used for continuous integration and continuous delivery.

Other features:

  • Easy to install
  • Detects failures early on
  • Helps organize releases and keep deployments on schedule
Jenkins - Release Management Software

Plutora

Plutora, a value stream management platform, improves time-to-value and improves your digital transformation journey by scaling Agile and DevOps across your organization.

The platform also gives you full visibility and control over the release process enhancing productivity and allowing different teams to see what they’re doing.

This transparency over the software delivery process allows you to increase efficiency and reduce time-to-value to deliver better software faster.

Other features:

  • Increases delivery speed through automation and streamlined processes
  • Improves collaboration to ensure fast workflows between development and test teams
  • Provides release insights to make sure high-quality releases are delivered on time
Plutora - Value Stream Management platform

Chef

Chef helps to facilitate a culture of DevSecOps (Development, Security and Operations) by allowing effective collaboration through software automation. 

Chef helps teams build, deploy and secure your releases as well as enabling them to scale continuous delivery across different applications.

Other features:

  • Facilitates cross-team collaboration with actionable insights for configuration
  • Provides operational visibility for all your teams in one place
  • Provides a single source of truth for all environments
Chef - Release management software automation

Clarive

Clarive helps make application delivery easier through a unified workflow. This release management tool drives application changes from development all the way to production.

This tool also allows you to choose a template that fits your organization’s unique workflow and delivery mode.

Other features:

  • Provides a Kanboard board to create a deployment.
  • Allows you to track your release progress through the different stages
  • Provides an end-to-end delivery
Clarive - Release Management Tool

Spinnaker

Spinnaker is an open source, multi-cloud continuous delivery platform. Created by Netflix, this platform allows for fast and safe deployments across multiple cloud providers including AWS EC2, Kubernetes and Microsoft Azure.

Its deployment features enable teams to construct and manage continuous delivery workflows.

Other features:

  • Provides role-based access control so that access can be restricted to projects or accounts leading to heightened security
  • Allows you to restrict execution of stages to certain times; for example, when the right people are on hand to access the rollout
  • Requires manual judgements (a manual approval) prior to a release

Ultimately, the release management tool you choose will depend on a number of factors including: company size, amount of projects (i.e. whether you have a large number of simultaneous projects) and ease of use.

In the end, whatever tool you end up choosing, to ensure a smooth release management process, it’s imperative to build consistent workflows and foster an environment of collaboration.

Choosing the right tools will allow teams to efficiently build, manage and deploy new features without much hassle.

Article

6min read

Fun with Flags: Short vs Long-lived Feature Flags

In the previous addition to our Fun with Flags series, we discussed how to store feature flags based on the category of flags they belong to.

We also discussed how flags are broken down into categories based on their dynamism and longevity. 

In this post, we will explore the differences between short- and long-lived flags and which to choose depending on the use-case. We already touched upon this difference in the previous post but here we will go into more details. 

Feature flag longevity

First, we will briefly define what we mean by longevity. This concept refers to how long the decision logic for a flag will remain in a codebase.

Feature flags, or features toggles, can be broken down into the following categories. Each of these categories serve a different purpose and thus should be managed differently.

Feature toggles can be categorized as the following:

  • Release toggles– these are short-lived toggles that help developers in writing new features. They are usually on/off switches that control whether a feature is enabled or not. They are usually removed after the feature is released.
  • Operational toggles– these are used to control operational aspects of your system. They are usually used to turn features off. They can be short-lived but it’s not uncommon to have longer-lived ones that serve as kill switches.
  • Experiment toggles– these are used to perform A/B or multivariate tests. They will usually stay in the system for the duration necessary to generate statistically significant results from the feature testing so could be anywhere from a few weeks to months.
  • Permission toggles-these toggles are usually longer-lived compared to the other categories of toggles, sometimes remaining in your system for years. They are used for user segmenting or, in other words, to make features available to certain subsets of users.

As we’ve seen so far, there are different types of flags, each used for different purposes and could stay in your system from days to months, even years, depending on how they are deployed.

Being aware of the longevity of a flag is crucial for a few reasons.

First of all, it is important when it comes to implementing the flag. For example, for short-lived flags, usually an if/else statement is sufficient but for flags that are meant to stay for a longer period of time will require more sophistication to support these flags and their associated use cases.

The second reason is to avoid the accumulation of technical debt, which will be explained in further detail in the next section.

Short vs long-term feature flags

This brings us to the key differences between short- and long-lived flags.

From the above, we can conclude that short-lived flags have a limited time span, meaning that they should be removed from your system as soon as they have served their purpose.

Long-lived or, in some cases, permanent flags are used for an extended period of time, sometimes beyond the release of a feature.

Long-lived flags become part of your regular software operations and infrastructure so you create it with the intention of keeping it in your system for an indefinite period of time.

It is crucial, therefore, to constantly review the flags you have in your flags.

Why is this important?

Flags must be checked at regular intervals to avoid the accumulation of technical debt. This debt might take a toll on your system, causing major disruptions and even resulting in a total breakdown, if you don’t keep careful track of it. The more flags you add to your system, the higher this cost becomes.

Thus, the best way to minimize this cost is to conduct a regular clean-up of your flags. Remove any stale, unused flags that you no longer use; otherwise, you might end up with hundreds, or even thousands, of unused flags.

However, this may not be as simple as it sounds. Often, when flag adoption increases, many organizations could find it difficult to determine which flags are still active so this process might become time-consuming and challenging the further you are in your feature flag journey.

Let’s take a look at how to overcome this challenge…

You will need to have a process in place in which feature flags are regularly reviewed and removed from your codebase.

For short-term flags, check to see if the feature has been rolled out to all users or no users and for more long-lived flags, you should determine if the flag is still needed for one reason or another.

You should also consider setting up access control, lest someone mistakenly ends up deleting a permanent flag that you’re still very much using! Thus, consider setting up permissions for each flag to assign who can delete certain flags.

Additionally, adhering to naming conventions, which indicate the flag’s longevity is a great way to keep track of the many flags you have in your system.

An advanced feature flagging platform can give you full visibility over all the flags you have in your system.

In particular, the Flag Tracking Dashboard and enhanced Git integration give you the ability to manage tech debt and see where your flags are being used. It also gives you the ability to reference your codebase and all your AB Tasty Flags, allowing you to quickly locate the flags that you are no longer using.

To sum up…

To review what we’ve seen so far, the following table lists each category of flag and its longevity:

Category Longevity
Release From days to weeks (until the feature is rolled out)
Experiment From weeks to months, depending on how long it takes to gather statistically significant results/Temporary 
Operational From months to years, depending on their use case. 
Permissioning Usually long-lasting/Permanent
  • Are you creating this flag for purposes of testing, rollout or feature releases? These flags are usually temporary (days to weeks) and should be removed once the feature is deployed.
  • Are you conducting an A/B test? This must remain long enough to gather sufficient data but no longer than that.
  • Are you using this flag to manage entitlements? This is when you give access to a feature to a certain segment of users. These are often long-lived or permanent flags.

As a final note: Review your flags often

In conclusion, make sure to review the flags you have in your system, particularly the short-lived ones, so that you can ensure they’re deleted as soon as possible.

The expected life-span of a flag will depend on the purpose it was created for so everyone in the team needs to have a clear understanding of the purpose of each flag in your system.

With that said, the most important takeaway is to make sure to schedule regular clean-ups to keep technical debt in check. As already mentioned, a third-party service will make the process less daunting by giving you full visibility of all your flags so that you can identify which flags need to be removed.

Article

7min read

Fun with Flags: Where to Store Feature Flags

So far, in our Fun with Flags series, we have looked at some important best practices when it comes to feature flags including naming conventions and access control.

In this part of our series, we will be looking at the different ways feature flags can be stored based on which category they belong to.

Let’s start with a simple definition of feature flags. A feature flag is a software development practice that allows you to decouple code deployment from release, enabling quicker and safer releases.

They allow you to enable or disable functionality remotely without changing code. At its most basic, a feature flag is a file separate from your code file.

For a more comprehensive overview of feature flags, read our definitive guide to feature flags.

Configuration files

You could start off deploying feature flags using a configuration file. This is the simplest implementation method. A config file is usually used to store application settings and some flags just fall into this category. 

However, this might be time-consuming as developers may need to redeploy the application after each value update to reflect the changed value. Redeploying can take some time and if your changes are mission critical you may lose some reactivity. Configuration files also don’t allow you to make context-specific decisions, meaning that flags will either be on or off for all users (only hold one specific value at a time).

This makes the most sense when you’re just starting out your feature flag journey and you wish to experiment with feature flags at a smaller scale. Additionally, this could be a viable option for static flags like a release toggle, which are feature flags that enable trunk-based development to support dev teams as they write new features.

For example, a developer may need for a kill switch to work instantaneously to kill off a buggy feature while the flipping time for a release toggle from off to on can take longer.

Such static flags, as their name implies, will be relatively static and will only change through code or configuration file changes.

To better understand how feature flag values should be stored, it’s best to start with the different categories of flags, which are based on longevity and dynamism.

Short vs long lived flags

Longevity of a feature flag, as the name suggests, refers to how long a flag will remain in your code. 

Some types of flags are short-lived such as release toggles while others such as kill switches are long-lived; they will stay in your codebase often for years.

This distinction between short- and long-lived flags will influence how you go about implementing its toggle point. The longer the lifetime of a flag, the more careful you’ll need to be in choosing about choosing the toggle point location.

Keep reading: Short vs Long-lived Feature Flags (Fun with Flag series)

Dynamic vs static flags

There are obviously different types of flags, which means these different flags cannot be managed and configured the same way. Dynamism refers to how much we need to modify a flag in its lifetime.

Therefore, feature flags can be broken down into two categories depending on how they are hosted:

  • Static flags-as already mentioned, these are usually hosted by a file that only changes when you want it to. These flags get hard-coded into the app at build time so the flag configuration is stored in the actual code.
  • Dynamic flags-usually hosted by a service that will change the value of the flag depending on the values you send with the request. This type of flag can be changed at runtime allowing for dynamic control of code execution on a user-by-user or session-by-session basis.

This means that the configuration for some types of flags needs to be more dynamic than others. For example, if you want to change a value based on a shared attribute among groups of users. 

Alternative storage method: database

As an alternative to config files, feature flags can be stored in some sort of database. It is a convenient place to store your settings and they can often be easily updated.

So if you see the number of flags in your system and you need more granular controls, you might opt to deploy your flags via a database. This would allow you to target features to individual users. 

Moreover, having flags in a database means that not only your developers can change values assigned to flags but also your product teams, thereby reducing dependency. This assumes that some kind of dashboard or management system is in place for other people to easily interact with the database. You’ll also probably want to keep track of changes to this database.

However, you still wouldn’t be able to do gradual rollouts or targeting users based on IDs or attributes or monitor metrics. In other words, it limits the extent of your user segmetting. 

Consequently, while config files and databases are quick solutions, when you’re just starting out, they are not good in the long-term if you’re looking to scale or use more dynamic flags.

You might then consider a feature flag open source solution, which allows for simple user segmentation and controlled rollouts. Nevertheless, such solutions wouldn’t allow you to track who made changes or limit access and they are generally language specific. This could be a problem if your application uses multiple languages so you would need to deploy multiple solutions.

Feature management services

The most dynamic flags are those whose state depends on the current user. Dynamic flags need to be hosted by a service rather than a static file mentioned previously. This is because feature flag services allow you to serve different values to different types of users at runtime.

In that sense, you would target values based on user IDs or according to percentage, i.e. a feature can be seen by x% of users, or according to a certain group the users belong to, using some user traits as targeting criteria.

This also works if you’re experimenting with features, with a traditional A/B testing approach, and you need to randomly put users in different groups so the user’s ID would be sent to the service to place in a group accordingly.

Such IDs (that could be stored in cookies or localStorage
) are also useful when testing internally where a feature is turned on for internal users as detected via a special ID value. Developers would then turn these features on for themselves to make sure it’s working as it should and test directly in production.

In such situations, you would opt for a third party service to fetch values of the feature flags.

Such feature flag services would, therefore, also allow you to to choose values for each flag depending on specific attributes such as the country users are from.

For example, AB Tasty’s flagging functionality allows you to assign specific flag values to different user segments. So, internal users would be served one value and would then see the new feature while external users will be served another value.

For example, in the image below from the AB Tasty dashboard, the value that is fetched will be IOS in Scenario 1 and ANDROID in Scenario 2 so only the users matching this value will be exposed to the feature. 

This is extremely useful if you want to do gradual rollouts and testing in production and for generally more advanced use-cases.

Conclusion

For advanced use-cases, it would make sense to opt for a third party solution to help you manage and implement the different types of flags in your system.

These solutions offer features such as a UI for managing configuration with access control to limit who does what as well as audit logs to determine which changes were made by whom.

Therefore, sophisticated feature management solutions like AB Tasty are built to scale and include role-based and access controls to execute more complex use-cases.