For more than a decade CI (Continuous Integration)
helps us to deliver better code in quicker and saver manner. There are a lot of
aspects and rules how to do it right and you can find a lot of information on
the Internet.
Before sharing with you how things are being done at PicScout we thought it would be a great idea to give an overview of possible solutions for what is common to be called a feature bit.
In this post I will introduce a flavor called “Feature Toggles (Bits)”:
Before sharing with you how things are being done at PicScout we thought it would be a great idea to give an overview of possible solutions for what is common to be called a feature bit.
In this post I will introduce a flavor called “Feature Toggles (Bits)”:
A few words about the CI:
Why do we need it?
Generally, we want:
Generally, we want:
- Prevent integration problems, referred to as "integration hell" and stop spending nights while trying to release a new version to production
- Always work on latest code
- Detect problems early and not during integration/deployment
- Be almost 100% sure about current code
- Sleep good in the night…
How can we do it?
- Commit early – small changes
- Work on main trunk
- Update your code from Code repository at least once a day.
- All commits should be RFD - “Ready for deployment”. This means, all unit/integration/acceptance tests are green. Commits could be executed in regular way or in two-phase (pre-tested) approach.
- Many more…
Okay, let's say we've worked hard to implement CI/CD recommendations.
That's obviously great, but imagine that now we introduce a new piece of code to our code base.
This code could be:
- Safe. (Could be deployed without affecting various system components)
- Internal algorithm/behavior was changed.
- Column or table was created
- Some internal bug was fixed
- Dependent
- Could be deployed only after making changes in other system components
This new code deployment can be done by using “Feature Toggle (Bit)”.
The main idea is: New code should be
enabled/disabled using feature bits.
if (FeatureBitSettings.BitEnabled("ScanPdf"))
{
// enable new behavior
}
else
{
// old behavior
}
If you develop code, which is part of different components, feature bits should be added everywhere.
(Note: “if” – is one of the code smells, but for sake of save deployment it could be used).
(Note: “if” – is one of the code smells, but for sake of save deployment it could be used).
Additionally, new tests with/without feature bits should be
added/adjusted.
Feature bits stay in configuration files.
true false
How it should work? Feature bits life cycle:
1.
Develop new code with
feature bits.
2.
Test it: with feature bits On/Off.
3.
Set feature bits Off.
4.
Deploy it.
5. Everything is fine? Enable feature bits to On (by
changing configuration) in right order (if there are dependencies between
components).
6.
In the case of problems you
can do the rollback quickly by setting bits to Off.
7.
After running for some time
(days/weeks) code declared safe.
8.
Remove feature bits from the
code. Leave only the “On” code.
9.
Deploy it.
10.
Remove redundant feature
bits from configuration.
As we might see, feature bits allow us handle different
integration/deployment issues quickly and safely.
