The Order Book now has a new way: The order list comes from the web API, there is a Blazor page, and the data lives in Azure SQL. Nobody will switch that on for everyone on a Monday. Ms. Aydin and two colleagues try it first, then dispatch, then the whole company, and with any problem the old way has to be back within minutes, without anyone reinstalling a program.
For that there are switches that you flip per person or group. This lesson builds them with the library that Microsoft offers for the purpose, sets the stages of the release and says how you can tell whether the next stage may come. How to roll out a new version of a program in stages (deployment stages, environments, pipeline) is covered in K3, module 3.7; here the subject is a feature that is already part of a version but does not apply to everyone.
Two kinds of switches
Rolling out a version and enabling a feature are two decisions. They are easily confused, and then the right move is missing when something goes wrong:
| Ship a version | Enable a feature (feature switch) | |
|---|---|---|
| Question | Which code runs? | Which way does the code take for this person? |
| Applies to | everyone who has this version | per person, group or percentage |
| Fallback | ship the old version again (minutes to hours) | flip the switch (seconds to minutes) |
| Who decides | pipeline and operations | the business side and the project, together |
| Lifetime | until the next version | until the end of the migration, then the switch is deleted |
The last point is the most important. A switch for the migration is debt with a due date: Every switch doubles the number of paths that somebody would have to test, and a switch that is still in the code after the old program has been switched off leads to dead code with meaning. For every switch, write down when it disappears; in lesson M6.5 you clean them up.