davidbgk
/
larlet-fr-david-cache
Слідкувати 1
В обрані 0
Форк 0
Код Релізи 0 Активність
A place to cache linked articles (think custom and personal wayback machine)
Ви не можете вибрати більше 25 тем Теми мають розпочинатися з літери або цифри, можуть містити дефіси (-) і не повинні перевищувати 35 символів.
169 Коміти
1 Гілка
Дерево: df9a5c5108
Гілки Теги
${ item.name }
Створити гілку ${ searchTerm }
з 'df9a5c5108'
${ noResults }
larlet-fr-david-cache/cache/7c569b2880bd3ed844e039a322b.../index.html

index.html 71KB
Неформатований Blame Історія

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620 
  1. <!doctype html><!-- This is a valid HTML5 document. -->

  2. <!-- Screen readers, SEO, extensions and so on. -->

  3. <html lang=fr>

  4. <!-- Has to be within the first 1024 bytes, hence before the <title>

  5.   See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->

  6. <meta charset=utf-8>

  7. <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->

  8. <!-- The viewport meta is quite crowded and we are responsible for that.

  9.   See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->

  10. <meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">

  11. <!-- Required to make a valid HTML5 document. -->

  12. <title>Feature Toggles (aka Feature Flags) (archive) — David Larlet</title>

  13. <!-- Generated from https://realfavicongenerator.net/ such a mess. -->

  14. <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">

  15. <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">

  16. <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">

  17. <link rel="manifest" href="/manifest.json">

  18. <link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">

  19. <link rel="shortcut icon" href="/static/david/icons/favicon.ico">

  20. <meta name="apple-mobile-web-app-title" content="David Larlet">

  21. <meta name="application-name" content="David Larlet">

  22. <meta name="msapplication-TileColor" content="#da532c">

  23. <meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">

  24. <meta name="theme-color" content="#f0f0ea">

  25. <!-- That good ol' feed, subscribe :p. -->

  26. <link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  27. 

  28.   <meta name="robots" content="noindex, nofollow">

  29.   <meta content="origin-when-cross-origin" name="referrer">

  30.   <!-- Canonical URL for SEO purposes -->

  31.   <link rel="canonical" href="https://martinfowler.com/articles/feature-toggles.html">

  32. 

  33. <style>

  34. /* http://meyerweb.com/eric/tools/css/reset/ */

  35. html, body, div, span,

  36. h1, h2, h3, h4, h5, h6, p, blockquote, pre,

  37. a, abbr, address, big, cite, code,

  38. del, dfn, em, img, ins,

  39. small, strike, strong, tt, var,

  40. dl, dt, dd, ol, ul, li,

  41. fieldset, form, label, legend,

  42. table, caption, tbody, tfoot, thead, tr, th, td,

  43. article, aside, canvas, details, embed,

  44. figure, figcaption, footer, header, hgroup,

  45. menu, nav, output, ruby, section, summary,

  46. time, mark, audio, video {

  47.   margin: 0;

  48.   padding: 0;

  49.   border: 0;

  50.   font-size: 100%;

  51.   font: inherit;

  52.   vertical-align: baseline;

  53. }

  54. /* HTML5 display-role reset for older browsers */

  55. article, aside, details, figcaption, figure,

  56. footer, header, hgroup, menu, nav, section { display: block; }

  57. body { line-height: 1; }

  58. blockquote, q { quotes: none; }

  59. blockquote:before, blockquote:after,

  60. q:before, q:after {

  61.   content: '';

  62.   content: none;

  63. }

  64. table {

  65.   border-collapse: collapse;

  66.   border-spacing: 0;

  67. }

  68. 

  69. /* http://practicaltypography.com/equity.html */

  70. /* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */

  71. /* https://www.filamentgroup.com/lab/js-web-fonts.html */

  72. @font-face {

  73.   font-family: 'EquityTextB';

  74.   src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),

  75.        url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');

  76.   font-weight: 300;

  77.   font-style: normal;

  78.   font-display: swap;

  79. }

  80. @font-face {

  81.   font-family: 'EquityTextB';

  82.   src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),

  83.        url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');

  84.   font-weight: 300;

  85.   font-style: italic;

  86.   font-display: swap;

  87. }

  88. @font-face {

  89.   font-family: 'EquityTextB';

  90.   src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),

  91.        url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');

  92.   font-weight: 700;

  93.   font-style: normal;

  94.   font-display: swap;

  95. }

  96. 

  97. @font-face {

  98.   font-family: 'ConcourseT3';

  99.   src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),

  100.        url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');

  101.   font-weight: 300;

  102.   font-style: normal;

  103.   font-display: swap;

  104. }

  105. 

  106. 

  107. /* http://practice.typekit.com/lesson/caring-about-opentype-features/ */

  108. body {

  109.   /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */

  110.   font-family: "EquityTextB", Palatino, serif;

  111.   background-color: #f0f0ea;

  112.   color: #07486c;

  113.   font-kerning: normal;

  114.   -moz-osx-font-smoothing: grayscale;

  115.   -webkit-font-smoothing: subpixel-antialiased;

  116.   text-rendering: optimizeLegibility;

  117.   font-variant-ligatures: common-ligatures contextual;

  118.   font-feature-settings: "kern", "liga", "clig", "calt";

  119. }

  120. pre, code, kbd, samp, var, tt {

  121.   font-family: 'TriplicateT4c', monospace;

  122. }

  123. em {

  124.   font-style: italic;

  125.   color: #323a45;

  126. }

  127. strong {

  128.   font-weight: bold;

  129.   color: black;

  130. }

  131. nav {

  132.   background-color: #323a45;

  133.   color: #f0f0ea;

  134.   display: flex;

  135.   justify-content: space-around;

  136.   padding: 1rem .5rem;

  137. }

  138.   nav:last-child {

  139.     border-bottom: 1vh solid #2d7474;

  140.   }

  141.   nav a {

  142.     color: #f0f0ea;

  143.   }

  144.   nav abbr {

  145.     border-bottom: 1px dotted white;

  146.   }

  147. 

  148. h1 {

  149.   border-top: 1vh solid #2d7474;

  150.   border-bottom: .2vh dotted #2d7474;

  151.   background-color: #e3e1e1;

  152.   color: #323a45;

  153.   text-align: center;

  154.   padding: 5rem 0 4rem 0;

  155.   width: 100%;

  156.   font-family: 'ConcourseT3';

  157.   display: flex;

  158.   flex-direction: column;

  159. }

  160.   h1.single {

  161.     padding-bottom: 10rem;

  162.   }

  163.   h1 span {

  164.     position: absolute;

  165.     top: 1vh;

  166.     left: 20%;

  167.     line-height: 0;

  168.   }

  169.     h1 span a {

  170.       line-height: 1.7;

  171.       padding: 1rem 1.2rem .6rem 1.2rem;

  172.       border-radius: 0 0 6% 6%;

  173.       background: #2d7474;

  174.       font-size: 1.3rem;

  175.       color: white;

  176.       text-decoration: none;

  177.     }

  178. h2 {

  179.   margin: 4rem 0 1rem;

  180.   border-top: .2vh solid #2d7474;

  181.   padding-top: 1vh;

  182. }

  183. h3 {

  184.   text-align: center;

  185.   margin: 3rem 0 .75em;

  186. }

  187. hr {

  188.   height: .4rem;

  189.   width: .4rem;

  190.   border-radius: .4rem;

  191.   background: #07486c;

  192.   margin: 2.5rem auto;

  193. }

  194. time {

  195.   display: bloc;

  196.   margin-left: 0 !important;

  197. }

  198. ul, ol {

  199.   margin: 2rem;

  200. }

  201. ul {

  202.   list-style-type: square;

  203. }

  204. a {

  205.   text-decoration-skip-ink: auto;

  206.   text-decoration-thickness: 0.05em;

  207.   text-underline-offset: 0.09em;

  208. }

  209. article {

  210.   max-width: 50rem;

  211.   display: flex;

  212.   flex-direction: column;

  213.   margin: 2rem auto;

  214. }

  215.   article.single {

  216.     border-top: .2vh dotted #2d7474;

  217.     margin: -6rem auto 1rem auto;

  218.     background: #f0f0ea;

  219.     padding: 2rem;

  220.   }

  221.   article p:last-child {

  222.     margin-bottom: 1rem;

  223.   }

  224. p {

  225.   padding: 0 .5rem;

  226.   margin-left: 3rem;

  227. }

  228.   p + p,

  229.   figure + p {

  230.     margin-top: 2rem;

  231.   }

  232. 

  233. blockquote {

  234.   background-color: #e3e1e1;

  235.   border-left: .5vw solid #2d7474;

  236.   display: flex;

  237.   flex-direction: column;

  238.   align-items: center;

  239.   padding: 1rem;

  240.   margin: 1.5rem;

  241. }

  242.   blockquote cite {

  243.     font-style: italic;

  244.   }

  245.   blockquote p {

  246.     margin-left: 0;

  247.   }

  248. 

  249. figure {

  250.   border-top: .2vh solid #2d7474;

  251.   background-color: #e3e1e1;

  252.   text-align: center;

  253.   padding: 1.5rem 0;

  254.   margin: 1rem 0 0;

  255.   font-size: 1.5rem;

  256.   width: 100%;

  257. }

  258.   figure img {

  259.     max-width: 250px;

  260.     max-height: 250px;

  261.     border: .5vw solid #323a45;

  262.     padding: 1px;

  263.   }

  264. figcaption {

  265.   padding: 1rem;

  266.   line-height: 1.4;

  267. }

  268. aside {

  269.   display: flex;

  270.   flex-direction: column;

  271.   background-color: #e3e1e1;

  272.   padding: 1rem 0;

  273.   border-bottom: .2vh solid #07486c;

  274. }

  275.   aside p {

  276.     max-width: 50rem;

  277.     margin: 0 auto;

  278.   }

  279. 

  280. /* https://fvsch.com/code/css-locks/ */

  281. p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {

  282.   font-size: 1rem;

  283.   line-height: calc( 1.5em + 0.2 * 1rem );

  284. }

  285. h1 {

  286.   font-size: 1.9rem;

  287.   line-height: calc( 1.2em + 0.2 * 1rem );

  288. }

  289. h2 {

  290.   font-size: 1.6rem;

  291.   line-height: calc( 1.3em + 0.2 * 1rem );

  292. }

  293. h3 {

  294.   font-size: 1.35rem;

  295.   line-height: calc( 1.4em + 0.2 * 1rem );

  296. }

  297. @media (min-width: 20em) {

  298.   /* The (100vw - 20rem) / (50 - 20) part

  299.      resolves to 0-1rem, depending on the

  300.      viewport width (between 20em and 50em). */

  301.   p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {

  302.     font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );

  303.     line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );

  304.     margin-left: 0;

  305.   }

  306.   h1 {

  307.     font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );

  308.     line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );

  309.   }

  310.   h2 {

  311.     font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );

  312.     line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );

  313.   }

  314.   h3 {

  315.     font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );

  316.     line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );

  317.   }

  318. }

  319. @media (min-width: 50em) {

  320.   /* The right part of the addition *must* be a

  321.      rem value. In this example we *could* change

  322.      the whole declaration to font-size:2.5rem,

  323.      but if our baseline value was not expressed

  324.      in rem we would have to use calc. */

  325.   p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {

  326.     font-size: calc( 1rem + .6 * 1rem );

  327.     line-height: 1.5em;

  328.   }

  329.   p, li, pre, details {

  330.     margin-left: 3rem;

  331.   }

  332.   h1 {

  333.     font-size: calc( 1.9rem + 1.5 * 1rem );

  334.     line-height: 1.2em;

  335.   }

  336.   h2 {

  337.     font-size: calc( 1.5rem + 1.5 * 1rem );

  338.     line-height: 1.3em;

  339.   }

  340.   h3 {

  341.     font-size: calc( 1.35rem + 1.5 * 1rem );

  342.     line-height: 1.4em;

  343.   }

  344.   figure img {

  345.     max-width: 500px;

  346.     max-height: 500px;

  347.   }

  348. }

  349. 

  350. figure.unsquared {

  351.   margin-bottom: 1.5rem;

  352. }

  353.   figure.unsquared img {

  354.     height: inherit;

  355.   }

  356. 

  357. 

  358. 

  359. @media print {

  360.   body { font-size: 100%; }

  361.   a:after { content: " (" attr(href) ")"; }

  362.   a, a:link, a:visited, a:after {

  363.     text-decoration: underline;

  364.     text-shadow: none !important;

  365.     background-image: none !important;

  366.     background: white;

  367.     color: black;

  368.   }

  369.   abbr[title] { border-bottom: 0; }

  370.   abbr[title]:after { content: " (" attr(title) ")"; }

  371.   img { page-break-inside: avoid; }

  372.   @page { margin: 2cm .5cm; }

  373.   h1, h2, h3 { page-break-after: avoid; }

  374.   p3 { orphans: 3; widows: 3; }

  375.   img {

  376.     max-width: 250px !important;

  377.     max-height: 250px !important;

  378.   }

  379.   nav, aside { display: none; }

  380. }

  381. 

  382. ul.with_columns {

  383.   column-count: 1;

  384. }

  385. @media (min-width: 20em) {

  386.   ul.with_columns {

  387.     column-count: 2;

  388.   }

  389. }

  390. @media (min-width: 50em) {

  391.   ul.with_columns {

  392.     column-count: 3;

  393.   }

  394. }

  395. ul.with_two_columns {

  396.   column-count: 1;

  397. }

  398. @media (min-width: 20em) {

  399.   ul.with_two_columns {

  400.     column-count: 1;

  401.   }

  402. }

  403. @media (min-width: 50em) {

  404.   ul.with_two_columns {

  405.     column-count: 2;

  406.   }

  407. }

  408. 

  409. .gallery {

  410.   display: flex;

  411.   flex-wrap: wrap;

  412.   justify-content: space-around;

  413. }

  414.   .gallery figure img {

  415.     margin-left: 1rem;

  416.     margin-right: 1rem;

  417.   }

  418.   .gallery figure figcaption {

  419.     font-family: 'ConcourseT3'

  420.   }

  421. 

  422. footer {

  423.   font-family: 'ConcourseT3';

  424.   display: flex;

  425.   flex-direction: column;

  426.   border-top: 3px solid white;

  427.   padding: 4rem 0;

  428.   background-color: #07486c;

  429.   color: white;

  430. }

  431.   footer > * {

  432.     max-width: 50rem;

  433.     margin: 0 auto;

  434.   }

  435.   footer a {

  436.     color: #f1c40f;

  437.   }

  438.   footer .avatar {

  439.     width: 200px;

  440.     height: 200px;

  441.     border-radius: 50%;

  442.     float: left;

  443.     -webkit-shape-outside: circle();

  444.     shape-outside: circle();

  445.     margin-right: 2rem;

  446.     padding: 2px 5px 5px 2px;

  447.     background: white;

  448.     border-left: 1px solid #f1c40f;

  449.     border-top: 1px solid #f1c40f;

  450.     border-right: 5px solid #f1c40f;

  451.     border-bottom: 5px solid #f1c40f;

  452.   }

  453. </style>

  454. 

  455. <h1>

  456.   <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>

  457.   Feature Toggles (aka Feature Flags) (archive)

  458.   <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>

  459. </h1>

  460. <section>

  461.   <article>

  462.     <h3><a href="https://martinfowler.com/articles/feature-toggles.html">Source originale du contenu</a></h3>

  463.     <p>"Feature Toggling" is a set of patterns which can help a team to deliver new

  464.     functionality to users rapidly but safely. In this article on Feature Toggling we'll

  465.     start off with a short story showing some typical scenarios where Feature Toggles are

  466.     helpful. Then we'll dig into the details, covering specific patterns and practices

  467.     which will help a team succeed with Feature Toggles.</p>

  468. 

  469. <p>Feature Toggles are also refered to as Feature Flags, Feature Bits, or Feature Flippers.

  470.     These are all synonyms for the same set of techniques. Throughout this article I'll use 

  471.     feature toggles and feature flags interchangebly.</p>

  472. 

  473. <div id="ATogglingTale"><hr class="topSection"/>

  474. <h2>A Toggling Tale</h2>

  475. 

  476. <p>Picture the scene. You're on one of several teams working on a sophisticated town

  477.       planning simulation game. Your team is responsible for the core simulation engine.

  478.       You have been tasked with increasing the efficiency of the Spline Reticulation

  479.       algorithm. You know this will require a fairly large overhaul of the implementation

  480.       which will take several weeks. Meanwhile other members of your team will need to

  481.       continue some ongoing work on related areas of the codebase. </p>

  482. 

  483. <p>You want to avoid branching for this work if at all possible, based on previous

  484.       painful experiences of merging long-lived branches in the past. Instead, you decide

  485.       that the entire team will continue to work on trunk, but the developers working on

  486.       the Spline Reticulation improvements will use a Feature Toggle to prevent their work

  487.       from impacting the rest of the team or destabilizing the codebase.</p>

  488. 

  489. <div id="TheBirthOfAFeatureFlag">

  490. <h3>The birth of a Feature Flag</h3>

  491. 

  492. <p>Here's the first change introduced by the pair working on the algorithm:</p>

  493. 

  494. <p class="code-label">before

  495. </p>

  496. 

  497. <pre class="code">  function reticulateSplines(){

  498.     // current implementation lives here

  499.   }</pre>

  500. 

  501. 

  502. 

  503. <p class="code-label">after

  504. </p>

  505. 

  506. <pre class="code">  function reticulateSplines(){

  507.     var useNewAlgorithm = false;

  508.     // useNewAlgorithm = true; // UNCOMMENT IF YOU ARE WORKING ON THE NEW SR ALGORITHM

  509. 

  510.     if( useNewAlgorithm ){

  511.       return enhancedSplineReticulation();

  512.     }else{

  513.       return oldFashionedSplineReticulation();

  514.     }

  515.   }

  516. 

  517.   function oldFashionedSplineReticulation(){

  518.     // current implementation lives here

  519.   }

  520. 

  521.   function enhancedSplineReticulation(){

  522.     // TODO: implement better SR algorithm

  523.   }</pre>

  524. 

  525. <p>The pair have moved the current algorithm implementation into an

  526.         <code>oldFashionedSplineReticulation</code> function, and turned

  527.         <code>reticulateSplines</code> into a <b>Toggle Point</b>. Now if someone is

  528.         working on the new algorithm they can enable the "use new Algorithm"

  529.         <b>Feature</b> by uncommenting the <code>useNewAlgorithm = true</code>

  530.         line.</p>

  531. </div>

  532. 

  533. <div id="MakingAFlagDynamic">

  534. <h3>Making a flag dynamic</h3>

  535. 

  536. <p>A few hours pass and the pair are ready to run their new algorithm through some

  537.         of the simulation engine's integration tests. They also want to exercise the old

  538.         algorithm in the same integration test run. They'll need to be able to enable or

  539.         disable the Feature dynamically, which means it's time to move on from the clunky

  540.         mechanism of commenting or uncommenting that <code>useNewAlgorithm = true</code>

  541.         line:</p>

  542. 

  543. <pre class="code">function reticulateSplines(){

  544.   if( featureIsEnabled("use-new-SR-algorithm") ){

  545.     return enhancedSplineReticulation();

  546.   }else{

  547.     return oldFashionedSplineReticulation();

  548.   }

  549. }

  550. </pre>

  551. 

  552. <p>We've now introduced a <code>featureIsEnabled</code> function, a <b>Toggle

  553.         Router</b> which can be used to dynamically control which codepath is live.

  554.         There are many ways to implement a Toggle Router, varying from a simple in-memory

  555.         store to a highly sophisticated distributed system with a fancy UI. For now we'll

  556.         start with a very simple system:</p>

  557. 

  558. <pre class="code">function createToggleRouter(featureConfig){

  559.   return {

  560.     setFeature(featureName,isEnabled){

  561.       featureConfig[featureName] = isEnabled;

  562.     },

  563.     featureIsEnabled(featureName){

  564.       return featureConfig[featureName];

  565.     }

  566.   };

  567. }

  568. </pre>

  569. 

  570. 

  571. 

  572. <p>We can create a new toggle router based on some default configuration - perhaps

  573.         read in from a config file - but we can also dynamically toggle a feature on or

  574.         off. This allows automated tests to verify both sides of a toggled feature:</p>

  575. 

  576. <pre class="code">describe( 'spline reticulation', function(){

  577.   let toggleRouter;

  578.   let simulationEngine;

  579. 

  580.   beforeEach(function(){

  581.     toggleRouter = createToggleRouter();

  582.     simulationEngine = createSimulationEngine({toggleRouter:toggleRouter});

  583.   });

  584. 

  585.   it('works correctly with old algorithm', function(){

  586.     // Given

  587.     toggleRouter.setFeature("use-new-SR-algorithm",false);

  588. 

  589.     // When

  590.     const result = simulationEngine.doSomethingWhichInvolvesSplineReticulation();

  591. 

  592.     // Then

  593.     verifySplineReticulation(result);

  594.   });

  595. 

  596.   it('works correctly with new algorithm', function(){

  597.     // Given

  598.     toggleRouter.setFeature("use-new-SR-algorithm",true);

  599. 

  600.     // When

  601.     const result = simulationEngine.doSomethingWhichInvolvesSplineReticulation();

  602. 

  603.     // Then

  604.     verifySplineReticulation(result);

  605.   });

  606. });

  607. </pre>

  608. </div>

  609. 

  610. <div id="GettingReadyToRelease">

  611. <h3>Getting ready to release</h3>

  612. 

  613. <p>More time passes and the team believe their new algorithm is feature-complete.

  614.         To confirm this they have been modifying their higher-level automated tests so

  615.         that they exercise the system both with the feature off and with it on. The team

  616.         also wants to do some manual exploratory testing to ensure everything works as

  617.         expected - Spline Reticulation is a critical part of the system's behavior, after

  618.         all. </p>

  619. 

  620. <p>To perform manual testing of a feature which hasn't yet been verified as ready

  621.         for general use we need to be able to have the feature Off for our general user

  622.         base in production but be able to turn it On for internal users. There are a lot

  623.         of different approaches to achieve this goal:</p>

  624. 

  625. <ul>

  626. <li>Have the Toggle Router make decisions based on a <b>Toggle Configuration</b>,

  627.           and make that configuration environment-specific. Only turn the new feature on in a

  628.           pre-production environment.</li>

  629. 

  630. <li>Allow Toggle Configuration to be modified at runtime via some form of admin UI. Use

  631.           that admin UI to turn the new feature on a test environment.</li>

  632. 

  633. <li>Teach the Toggle Router how to make dynamic, per-request toggling decisions.

  634.           These decisions take <b>Toggle Context</b> into account, for example by looking for a special cookie

  635.           or HTTP header. Usually Toggle Context is used as a proxy for identifying the user making the request.</li>

  636. </ul>

  637. 

  638. <p>(We'll be digging into these approaches in more detail later on, so don't worry if some

  639.         of these concepts are new to you.)</p>

  640. 

  641. 

  642. 

  643. <p class="clear"/>

  644. 

  645. <p>The team decides to go with a per-request Toggle Router since it gives them a lot of

  646.         flexibility. The team particularly appreciate that this will allow them to test their new algorithm without needing

  647.         a separate testing environment. Instead they can simply turn the algorithm on in their

  648.         production environment but only for internal users (as detected via a special cookie). The

  649.         team can now turn that cookie on for themselves and verify that the new feature performs

  650.         as expected.</p>

  651. </div>

  652. 

  653. <div id="CanaryReleasing">

  654. <h3>Canary releasing</h3>

  655. 

  656. <p>The new Spline Reticulation algorithm is looking good based on the exploratory

  657.         testing done so far. However since it's such a critical part of the game's

  658.         simulation engine there remains some reluctance to turn this feature on for all

  659.         users. The team decide to use their Feature Flag infrastructure to perform a

  660.         <a href="/bliki/CanaryRelease.html"><b>Canary Release</b></a>, only turning the new

  661.         feature on for a small percentage of their total userbase - a "canary" cohort.

  662.         </p>

  663. 

  664. <p>The team enhance the Toggle Router by teaching it the concept of user cohorts -

  665.         groups of users who consistently experience a feature as always being On or Off. A

  666.         cohort of canary users is created via a random sampling of 1% of the user base -

  667.         perhaps using a modulo of user ID. This canary cohort will consistently have the

  668.         feature turned on, while the other 99% of the user base remain using the old

  669.         algorithm. Key business metrics (user engagement, total revenue earned, etc) are

  670.         monitored for both groups to gain confidence that the new algorithm does not

  671.         negatively impact user behavior. Once the team are confident that the new feature has no

  672.         ill effects they modify their Toggle Configuration to turn it on for the entire user

  673.         base.</p>

  674. </div>

  675. 

  676. <div id="AbTesting">

  677. <h3>A/B testing</h3>

  678. 

  679. <p>The team's product manager learns about this approach and is quite excited. She

  680.         suggests that the team use a similar mechanism to perform some A/B testing. There's been a 

  681.         long-running debate as to whether modifying the crime rate algorithm to take

  682.         pollution levels into account would increase or decrease the game's playability.

  683.         They now have the ability to settle the debate using data. They plan to roll out a

  684.         cheap implementation which captures the essence of the idea, controlled with a

  685.         Feature Flag. They will turn the feature on for a reasonably large cohort of

  686.         users, then study how those users behave compared to a "control" cohort. This approach will allow

  687.         the team to resolve contentious product debates based on data, rather than <a href="http://www.forbes.com/sites/derosetichy/2013/04/15/what-happens-when-a-hippo-runs-your-company/">HiPPOs</a>.</p>

  688. </div>

  689. 

  690. <p>This brief scenario is intended to illustrate both the basic concept of Feature

  691.     Toggling but also to highlight how many different applications this core capability

  692.     can have. Now that we've seen some examples of those applications let's dig a little

  693.     deeper. We'll explore different categories of toggles and see what makes them

  694.     different. We'll cover how to write maintainable toggle code, and finally share

  695.     practices to avoid some of pitfalls of a feature-toggled system.</p>

  696. </div>

  697. 

  698. <div id="CategoriesOfToggles"><hr class="topSection"/>

  699. <h2>Categories of toggles</h2>

  700. 

  701. <p>We've seen the fundamental facility provided by Feature Toggles - being able to

  702.       ship alternative codepaths within one deployable unit and choose between them at

  703.       runtime. The scenarios above also show that this facility can be used in various

  704.       ways in various contexts. It can be tempting to lump all feature toggles into the

  705.       same bucket, but this is a dangerous path. The design forces at play for different

  706.       categories of toggles are quite different and managing them all in the same way can

  707.       lead to pain down the road. </p>

  708. 

  709. <p>Feature toggles can be categorized across two major dimensions: how long the

  710.       feature toggle will live and how dynamic the toggling decision must be. There are

  711.       other factors to consider - who will manage the feature toggle, for example - but I

  712.       consider longevity and dynamism to be two big factors which can help guide how to manage

  713.       toggles.</p>

  714. 

  715. <p>Let's consider various categories of toggle through the lens of these two

  716.       dimensions and see where they fit.</p>

  717. 

  718. <div id="ReleaseToggles">

  719. <h3>Release Toggles</h3>

  720. 

  721. <div class="soundbite">

  722. <p>

  723.         Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.

  724.     </p>

  725. </div>

  726. 

  727. <p>These are feature flags used to enable trunk-based development for teams practicing

  728.     Continuous Delivery. They allow in-progress features to be checked into a shared

  729.     integration branch (e.g. master or trunk) while still allowing that branch to be deployed to production at

  730.     any time. Release Toggles allow incomplete and un-tested codepaths to be shipped to

  731.     production as <a href="http://www.infoq.com/news/2009/08/enabling-lrm">latent code</a> which may

  732.     never be turned on. </p>

  733. 

  734. <p>Product Managers may also use a product-centric version of this same approach to

  735.     prevent half-complete product features from being exposed to their end users. For

  736.     example, the product manager of an ecommerce site might not want to let users see a

  737.     new Estimated Shipping Date feature which only works for one of the site's shipping

  738.     partners, preferring to wait until that feature has been implemented for all shipping

  739.     partners. Product Managers may have other reasons for not wanting to expose features

  740.     even if they are fully implemented and tested. Feature release might be being

  741.     coordinated with a marketing campaign, for example. Using Release Toggles in this way

  742.     is the most common way to implement the Continuous Delivery principle of "separating

  743.     [feature] release from [code] deployment."</p>

  744. 

  745. <div class="figure " id="chart-1.png"><img src="feature-toggles/chart-1.png"/>

  746. <p class="photoCaption"/>

  747. </div>

  748. 

  749. <p class="clear"/>

  750. 

  751. <p>Release Toggles are transitionary by nature. They should generally not stick around

  752.     much longer than a week or two, although product-centric toggles may need to remain in

  753.     place for a longer period. The toggling decision for a Release Toggle is

  754.     typically very static. Every toggling decision for a given release version will be the

  755.     same, and changing that toggling decision by rolling out a new release with a toggle

  756.     configuration change is usually perfectly acceptable.</p>

  757. </div>

  758. 

  759. <div id="ExperimentToggles">

  760. <h3>Experiment Toggles</h3>

  761. 

  762. <p>Experiment Toggles are used to perform multivariate or A/B testing. Each user of

  763.       the system is placed into a cohort and at runtime the Toggle Router will

  764.       consistently send a given user down one codepath or the other, based upon which

  765.       cohort they are in. By tracking the aggregate behavior of different cohorts we can

  766.       compare the effect of different codepaths. This technique is commonly used

  767.       to make data-driven optimizations to things such as the purchase flow of an

  768.       ecommerce system, or the Call To Action wording on a button.</p>

  769. 

  770. <div class="figure " id="chart-2.png"><img src="feature-toggles/chart-2.png"/>

  771. <p class="photoCaption"/>

  772. </div>

  773. 

  774. <p class="clear"/>

  775. 

  776. <p>An Experiment Toggle needs to remain in place with the same configuration long

  777.       enough to generate statistically significant results. Depending on traffic patterns

  778.       that might mean a lifetime of hours or weeks. Longer is unlikely to be useful, as

  779.       other changes to the system risk invalidating the results of the experiment. By

  780.       their nature Experiment Toggles are highly dynamic - each incoming request is likely

  781.       on behalf of a different user and thus might be routed differently than the last.

  782.       </p>

  783. </div>

  784. 

  785. <div id="OpsToggles">

  786. <h3>Ops Toggles</h3>

  787. 

  788. <p>These flags are used to control operational aspects of our system's behavior.

  789.       We might introduce an Ops Toggle when rolling out a new feature which has unclear

  790.       performance implications so that system operators can disable or degrade that

  791.       feature quickly in production if needed. </p>

  792. 

  793. <p>Most Ops Toggles will be relatively short-lived - once confidence is gained in

  794.       the operational aspects of a new feature the flag should be retired. However it's

  795.       not uncommon for systems to have a small number of long-lived "Kill Switches" which

  796.       allow operators of production environments to gracefully degrade non-vital system

  797.       functionality when the system is enduring unusually high load. For example, when

  798.       we're under heavy load we might want to disable a Recommendations panel on our home

  799.       page which is relatively expensive to generate. I consulted with an online retailer

  800.       that maintained Ops Toggles which could intentionally disable many non-critical

  801.       features in their website's main purchasing flow just prior to a high-demand product

  802.       launch. These types of long-lived Ops Toggles could be seen as a manually-managed

  803.       <a href="/bliki/CircuitBreaker.html">Circuit Breaker</a>.</p>

  804. 

  805. <div class="figure " id="chart-3.png"><img src="feature-toggles/chart-3.png"/>

  806. <p class="photoCaption"/>

  807. </div>

  808. 

  809. <p class="clear"/>

  810. 

  811. <p>As already mentioned, many of these flags are only in place for a short while, but a few

  812.       key controls may be left in place for operators almost indefinitely. Since the

  813.       purpose of these flags is to allow operators to quickly react to production

  814.       issues they need to be re-configured extremely quickly - needing to roll out a

  815.       new release in order to flip an Ops Toggle is unlikely to make an Operations person happy.</p>

  816. </div>

  817. 

  818. <div id="PermissioningToggles">

  819. <h3>Permissioning Toggles</h3>

  820. 

  821. <div class="soundbite">

  822. <p>turning on new features for a set of internal users [is a] Champagne Brunch - an early opportunity to drink your own champagne</p>

  823. </div>

  824. 

  825. <p>These flags are used to change the features or product experience that certain

  826.       users receive. For example we may have a set of "premium" features which we only

  827.       toggle on for our paying customers. Or perhaps we have a set of "alpha" features

  828.       which are only available to internal users and another set of "beta" features which

  829.       are only available to internal users plus beta users. I refer to this technique of

  830.       turning on new features for a set of internal or beta users as a Champagne Brunch -

  831.       an early opportunity to "<a href="http://www.cio.com/article/122351/Pegasystems_CIO_Tells_Colleagues_Drink_Your_Own_Champagne">drink your own

  832.       champagne</a>".

  833.       </p>

  834. 

  835. <p>A Champagne Brunch is similar in many ways to a Canary Release. The distinction

  836.       between the two is that a Canary Released feature is exposed to a randomly selected

  837.       cohort of users while a Champagne Brunch feature is exposed to a specific set of

  838.       users.</p>

  839. 

  840. 

  841. 

  842. <p class="clear"/>

  843. 

  844. <p>When used as a way to manage a feature which is only exposed to premium users a

  845.       Permissioning Toggle may be very-long lived compared to other categories of Feature

  846.       Toggles - at the scale of multiple years. Since permissions are user-specific the toggling

  847.       decision for a Permissioning Toggle will always be per-request, making this a very dynamic toggle.</p>

  848. </div>

  849. 

  850. <div id="ManagingDifferentCategoriesOfToggles">

  851. <h3>Managing different categories of toggles</h3>

  852. 

  853. <p>Now that we have a toggle categorization scheme we can discuss how those two

  854.       dimensions of dynamism and longevity affect how we work with feature flags of different

  855.       categories.</p>

  856. 

  857. <div id="StaticVsDynamicToggles">

  858. <h4>static vs dynamic toggles</h4>

  859. 

  860. 

  861. 

  862. <p class="clear"/>

  863. 

  864. <p>Toggles which are making runtime routing decisions necessarily need more

  865.           sophisticated Toggle Routers, along with more complex configuration for those

  866.           routers.</p>

  867. 

  868. <p>For simple static routing decisions a toggle configuration can be a simple On 

  869.           or Off for each feature with a toggle router which is just responsible for relaying that

  870.           static on/off state to the Toggle Point. As we discussed earlier, other

  871.           categories of toggle are more dynamic and demand more sophisticated toggle

  872.           routers. For example the router for an Experiment Toggle makes routing

  873.           decisions dynamically for a given user, perhaps using some sort of consistent

  874.           cohorting algorithm based on that user's id. Rather than reading a static toggle

  875.           state from configuration this toggle router will instead need to read some sort of

  876.           cohort configuration defining things like how large the experimental cohort and

  877.           control cohort should be. That configuration would be used as an input into the

  878.           cohorting algorithm. </p>

  879. 

  880. <p>We'll dig into more detail on different ways to manage this toggle

  881.           configuration later on.</p>

  882. </div>

  883. 

  884. <div id="Long-livedTogglesVsTransientToggles">

  885. <h4>Long-lived toggles vs transient toggles</h4>

  886. 

  887. 

  888. 

  889. <p class="clear"/>

  890. 

  891. <p>We can also divide our toggle categories into those which are essentially

  892.         transient in nature vs. those which are long-lived and may be in place for years.

  893.         This distinction should have a strong influence on our approach to implementing 

  894.         a feature's Toggle Points. If

  895.         we're adding a Release Toggle which will be removed in a few days time then we can

  896.         probably get away with a Toggle Point which does a simple if/else check on a

  897.         Toggle Router. This is what we did with our spline reticulation example

  898.         earlier:</p>

  899. 

  900. <pre class="code">function reticulateSplines(){

  901.   if( featureIsEnabled("use-new-SR-algorithm") ){

  902.     return enhancedSplineReticulation();

  903.   }else{

  904.     return oldFashionedSplineReticulation();

  905.   }

  906. }

  907. </pre>

  908. 

  909. <p>However if we're creating a new Permissioning Toggle with Toggle Points which

  910.         we expect to stick around for a very long time then we certainly don't want to

  911.         implement those Toggle Points by sprinkling if/else checks around

  912.         indiscriminately. We'll need to use more maintainable implementation

  913.         techniques.</p>

  914. </div>

  915. </div>

  916. </div>

  917. 

  918. <div id="ImplementationTechniques"><hr class="topSection"/>

  919. <h2>Implementation Techniques</h2>

  920. 

  921. <p>Feature Flags seem to beget rather messy Toggle Point code, and these Toggle

  922.       Points also have a tendency to proliferate throughout a codebase. It's important to

  923.       keep this tendency in check for any feature flags in your codebase, and critically

  924.       important if the flag will be long-lived. There are a few implementation patterns

  925.       and practices which help to reduce this issue.</p>

  926. 

  927. <div id="De-couplingDecisionPointsFromDecisionLogic">

  928. <h3>De-coupling decision points from decision logic</h3>

  929. 

  930. <p>One common mistake with Feature Toggles is to couple the place where a toggling

  931.         decision is made (the Toggle Point) with the logic behind the decision (the Toggle

  932.         Router). Let's look at an example. We're working on the next generation of our

  933.         ecommerce system. One of our new features will allow a user to easily cancel an

  934.         order by clicking a link inside their order confirmation email (aka invoice email). We're using

  935.         feature flags to manage the rollout of all our next gen functionality. Our

  936.         initial feature flagging implementation looks like this:</p>

  937. 

  938. <p class="code-label">invoiceEmailer.js

  939. </p>

  940. 

  941. <pre class="code">  const features = fetchFeatureTogglesFromSomewhere();

  942. 

  943.   function generateInvoiceEmail(){

  944.     const baseEmail = buildEmailForInvoice(this.invoice);

  945.     if( features.isEnabled("next-gen-ecomm") ){ 

  946.       return addOrderCancellationContentToEmail(baseEmail);

  947.     }else{

  948.       return baseEmail;

  949.     }

  950.   }

  951. </pre>

  952. 

  953. <p>While generating the invoice email our

  954.         InvoiceEmailler checks to see whether the <code>next-gen-ecomm</code> feature is enabled. If

  955.         it is then the emailer adds some extra order cancellation content to the

  956.         email.</p>

  957. 

  958. <p>While this looks like a reasonable approach, it's very brittle. The decision on

  959.         whether to include order cancellation functionality in our invoice emails is wired

  960.         directly to that rather broad <code>next-gen-ecomm</code> feature - using a magic string, no less. Why should

  961.         the invoice emailling code need to know that the order cancellation content is

  962.         part of the next-gen feature set? What happens if we'd like to turn on some parts

  963.         of the next-gen functionality without exposing order cancellation? Or vice versa?

  964.         What if we decide we'd like to only roll out order cancellation to certain users?

  965.         It is quite common for these sort of "toggle scope" changes to occur as features

  966.         are developed. Also bear in mind that these toggle points tend to proliferate

  967.         throughout a codebase. With our current approach since the toggling decision logic

  968.         is part of the toggle point any change to that decision logic will require

  969.         trawling through all those toggle points which have spread through the

  970.         codebase.</p>

  971. 

  972. <p>Happily, <a href="https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering">any

  973.         problem in software can be solved by adding a layer of indirection</a>. We can

  974.         decouple a toggling decision point from the logic behind that decision like

  975.         so:</p>

  976. 

  977. <p class="code-label">featureDecisions.js

  978. </p>

  979. 

  980. <pre class="code">  function createFeatureDecisions(features){

  981.     return {

  982.       includeOrderCancellationInEmail(){

  983.         return features.isEnabled("next-gen-ecomm");

  984.       }

  985.       // ... additional decision functions also live here ...

  986.     };

  987.   }

  988. </pre>

  989. 

  990. <p class="code-label">invoiceEmailer.js

  991. </p>

  992. 

  993. <pre class="code">  const features = fetchFeatureTogglesFromSomewhere();

  994.   const featureDecisions = createFeatureDecisions(features);

  995. 

  996.   function generateInvoiceEmail(){

  997.     const baseEmail = buildEmailForInvoice(this.invoice);

  998.     if( featureDecisions.includeOrderCancellationInEmail() ){

  999.       return addOrderCancellationContentToEmail(baseEmail);

  1000.     }else{

  1001.       return baseEmail;

  1002.     }

  1003.   }

  1004. </pre>

  1005. 

  1006. <p>We've introduced a <code>FeatureDecisions</code> object, which acts as a collection point

  1007.         for any feature toggle decision logic. We create a decision method on this object

  1008.         for each specific toggling decision in our code - in this case "should we include

  1009.         order cancellation functionality in our invoice email" is represented by the

  1010.         <code>includeOrderCancellationInEmail</code> decision method. Right now the decision "logic"

  1011.         is a trivial pass-through to check the state of the <code>next-gen-ecomm</code> feature, but

  1012.         now as that logic evolves we have a singular place to manage it. Whenever we want

  1013.         to modify the logic of that specific toggling decision we have a single place to

  1014.         go. We might want to modify the scope of the decision - for example which specific

  1015.         feature flag controls the decision. Alternatively we might need to modify the

  1016.         reason for the decision - from being driven by a static toggle configuration to being

  1017.         driven by an A/B experiment, or by an operational concern such as an outage in

  1018.         some of our order cancellation infrastructure. In all cases our invoice emailer

  1019.         can remain blissfully unaware of how or why that toggling decision is being

  1020.         made.</p>

  1021. </div>

  1022. 

  1023. <div id="InversionOfDecision">

  1024. <h3>Inversion of Decision</h3>

  1025. 

  1026. <p>In the previous example our invoice emailer was responsible for asking the

  1027.         feature flagging infrastructure how it should perform. This means our invoice emailer has one

  1028.         extra concept it needs to be aware of - feature flagging - and an extra module it

  1029.         is coupled to. This makes the invoice emailer harder to work with and think about

  1030.         in isolation, including making it harder to test. As feature flagging has a

  1031.         tendency to become more and more prevalent in a system over time we will see more

  1032.         and more modules becoming coupled to the feature flagging system as a global

  1033.         dependency. Not the ideal scenario.</p>

  1034. 

  1035. <p>In software design we can often solve these coupling issues by applying

  1036.         Inversion of Control. This is true in this case. Here's how we might decouple our

  1037.         invoice emailer from our feature flagging infrastructure:</p>

  1038. 

  1039. <p class="code-label">invoiceEmailer.js

  1040. </p>

  1041. 

  1042. <pre class="code">  function createInvoiceEmailler(config){

  1043.     return {

  1044.       generateInvoiceEmail(){

  1045.         const baseEmail = buildEmailForInvoice(this.invoice);

  1046.         if( config.includeOrderCancellationInEmail ){

  1047.           return addOrderCancellationContentToEmail(email);

  1048.         }else{

  1049.           return baseEmail;

  1050.         }

  1051.       },

  1052. 

  1053.       // ... other invoice emailer methods ...

  1054.     };

  1055.   }</pre>

  1056. 

  1057. <p class="code-label">featureAwareFactory.js

  1058. </p>

  1059. 

  1060. <pre class="code">  function createFeatureAwareFactoryBasedOn(featureDecisions){

  1061.     return {

  1062.       invoiceEmailler(){

  1063.         return createInvoiceEmailler({

  1064.           includeOrderCancellationInEmail: featureDecisions.includeOrderCancellationInEmail()

  1065.         });

  1066.       },

  1067. 

  1068.       // ... other factory methods ...

  1069.     };

  1070.   }</pre>

  1071. 

  1072. <p>Now, rather than our <code>InvoiceEmailler</code> reaching out to <code>FeatureDecisions</code> it

  1073.         has those decisions injected into it at construction time via a <code>config</code> object.

  1074.         <code>InvoiceEmailler</code> now has no knowledge whatsoever about feature flagging. It just

  1075.         knows that some aspects of its behavior can be configured at runtime. This also

  1076.         makes testing <code>InvoiceEmailler</code>'s behavior easier - we can test the way that it

  1077.         generates emails both with and without order cancellation content just by passing

  1078.         a different configuration option during test:</p>

  1079. 

  1080. <pre class="code">describe( 'invoice emailling', function(){

  1081.   it( 'includes order cancellation content when configured to do so', function(){

  1082.     // Given 

  1083.     const emailler = createInvoiceEmailler({includeOrderCancellationInEmail:true});

  1084. 

  1085.     // When

  1086.     const email = emailler.generateInvoiceEmail();

  1087. 

  1088.     // Then

  1089.     verifyEmailContainsOrderCancellationContent(email);

  1090.   };

  1091. 

  1092.   it( 'does not includes order cancellation content when configured to not do so', function(){

  1093.     // Given 

  1094.     const emailler = createInvoiceEmailler({includeOrderCancellationInEmail:false});

  1095. 

  1096.     // When

  1097.     const email = emailler.generateInvoiceEmail();

  1098. 

  1099.     // Then

  1100.     verifyEmailDoesNotContainOrderCancellationContent(email);

  1101.   };

  1102. });

  1103. </pre>

  1104. 

  1105. <p>We also introduced a <code>FeatureAwareFactory</code> to centralize the creation of these

  1106.         decision-injected objects. This is an application of the general Dependency

  1107.         Injection pattern. If a DI system were in play in our codebase then we'd probably

  1108.         use that system to implement this approach.</p>

  1109. </div>

  1110. 

  1111. <div id="AvoidingConditionals">

  1112. <h3>Avoiding conditionals</h3>

  1113. 

  1114. <p>In our examples so far our Toggle Point has been implemented using an if

  1115.         statement. This might make sense for a simple, short-lived toggle. However point

  1116.         conditionals are not advised anywhere where a feature will require several Toggle Points, or

  1117.         where you expect the Toggle Point to be long-lived. A more maintainable

  1118.         alternative is to implement alternative codepaths using some sort of Strategy

  1119.         pattern:</p>

  1120. 

  1121. <p class="code-label">invoiceEmailler.js

  1122. </p>

  1123. 

  1124. <pre class="code">  function createInvoiceEmailler(additionalContentEnhancer){

  1125.     return {

  1126.       generateInvoiceEmail(){

  1127.         const baseEmail = buildEmailForInvoice(this.invoice);

  1128.         return additionalContentEnhancer(baseEmail);

  1129.       },

  1130.       // ... other invoice emailer methods ...

  1131. 

  1132.     };

  1133.   }</pre>

  1134. 

  1135. <p class="code-label">featureAwareFactory.js

  1136. </p>

  1137. 

  1138. <pre class="code">  function identityFn(x){ return x; }

  1139. 

  1140.   function createFeatureAwareFactoryBasedOn(featureDecisions){

  1141.     return {

  1142.       invoiceEmailler(){

  1143.         if( featureDecisions.includeOrderCancellationInEmail() ){

  1144.           return createInvoiceEmailler(addOrderCancellationContentToEmail);

  1145.         }else{

  1146.           return createInvoiceEmailler(identityFn);

  1147.         }

  1148.       },

  1149. 

  1150.       // ... other factory methods ...

  1151.     };

  1152.   }</pre>

  1153. 

  1154. <p>Here we're applying a Strategy pattern by allowing our invoice emailer to be

  1155.         configured with a content enhancement function. <code>FeatureAwareFactory</code> selects a

  1156.         strategy when creating the invoice emailer, guided by its <code>FeatureDecision</code>. If

  1157.         order cancellation should be in the email it passes in an enhancer function which

  1158.         adds that content to the email. Otherwise it passes in an <code>identityFn</code> enhancer -

  1159.         one which has no effect and simply passes the email back without

  1160.         modifications.</p>

  1161. </div>

  1162. </div>

  1163. 

  1164. <div id="ToggleConfiguration"><hr class="topSection"/>

  1165. <h2>Toggle Configuration</h2>

  1166. 

  1167. <div id="DynamicRoutingVsDynamicConfiguration">

  1168. <h3>Dynamic routing vs dynamic configuration</h3>

  1169. 

  1170. <p>Earlier we divided feature flags into those whose toggle routing decisions are

  1171.         essentially static for a given code deployment vs those whose decisions vary

  1172.         dynamically at runtime. It's important to note that there are two ways in which a

  1173.         flag's decisions might change at runtime. Firstly, something like a

  1174.         Ops Toggle might be dynamically <i>re-configured</i> from On to Off in response to a

  1175.         system outage. Secondly, some categories of toggles such as Permissioning Toggles

  1176.         and Experiment Toggles make a dynamic routing decision for each request based on

  1177.         some request context such as which user is making the request. The former is

  1178.         dynamic via re-configuration, while the later is inherently dynamic. These

  1179.         inherently dynamic toggles may make highly dynamic <b>decisions</b> but still have a

  1180.         <b>configuration</b> which is quite static, perhaps only changeable via

  1181.         re-deployment. Experiment Toggles are an example of this type of feature flag - we

  1182.         don't really need to be able to modify the parameters of an experiment at runtime.

  1183.         In fact doing so would likely make the experiment statistically invalid.</p>

  1184. </div>

  1185. 

  1186. <div id="PreferStaticConfiguration">

  1187. <h3>Prefer static configuration</h3>

  1188. 

  1189. <p>Managing toggle configuration via source control and re-deployments is

  1190.         preferable, if the nature of the feature flag allows it. Managing toggle configuration

  1191.         via source control gives us the same benefits that we get by using source control

  1192.         for things like infrastructure as code. It can allows toggle configuration

  1193.         to live alongside the codebase being toggled, which provides a really big win:

  1194.         toggle configuration will move through your Continuous Delivery pipeline in the

  1195.         exact same way as a code change or an infrastructure change would. This enables

  1196.         the full the benefits of CD - repeatable builds which are verified in a consistent

  1197.         way across environments. It also greatly reduces the testing burden of feature flags.

  1198.         There is less need to verify how the release will perform with both a toggle Off

  1199.         and On, since that state is baked into the release and won't be changed (for less

  1200.         dynamic flags at least). Another benefit of toggle configuration living

  1201.         side-by-side in source control is that we can easily see the state of the toggle

  1202.         in previous releases, and easily recreate previous releases if needed.</p>

  1203. </div>

  1204. 

  1205. <div id="ApproachesForManagingToggleConfiguration">

  1206. <h3>Approaches for managing toggle configuration</h3>

  1207. 

  1208. <p>While static configuration is preferable there are cases such as Ops Toggles where a more dynamic approach is required. Let's look at some options for managing toggle configuration, ranging from approaches which are simple but less dynamic

  1209.     through to some approaches which are highly sophisticated but come with a lot of

  1210.         additional complexity.</p>

  1211. </div>

  1212. 

  1213. <div id="HardcodedToggleConfiguration">

  1214. <h3>Hardcoded Toggle Configuration</h3>

  1215. 

  1216. <p>The most basic technique - perhaps so basic as to not be considered a Feature

  1217.         Flag - is to simply comment or uncomment blocks of code. For example:</p>

  1218. 

  1219. <pre class="code">function reticulateSplines(){

  1220.   //return oldFashionedSplineReticulation();

  1221.   return enhancedSplineReticulation();

  1222. }

  1223. </pre>

  1224. 

  1225. <p>Slightly more sophisticated than the commenting approach is the use of a

  1226.         preprocessor's <code>#ifdef</code> feature, where available.</p>

  1227. 

  1228. <p>Because this type of hardcoding doesn't allow dynamic re-configuration of a

  1229.         toggle it is only suitable for feature flags where we're willing to follow a pattern of

  1230.         deploying code in order to re-configure the flag.</p>

  1231. </div>

  1232. 

  1233. <div id="ParameterizedToggleConfiguration">

  1234. <h3>Parameterized Toggle Configuration</h3>

  1235. 

  1236. <p>The build-time configuration provided by hardcoded configuration isn't flexible

  1237.         enough for many use cases, including a lot of testing scenarios. A simple approach which at least allows

  1238.         feature flags to be re-configured without re-building an app or service is to specify

  1239.         Toggle Configuration via command-line arguments or environment variables. This is

  1240.         a simple and time-honored approach to toggling which has been around since well

  1241.         before anyone referred to the technique as Feature Toggling or Feature Flagging. However it comes with

  1242.         limitations. It can become unwieldy to coordinate configuration across a large

  1243.         number of processes, and changes to a toggle's configuration require either a re-deploy or at the

  1244.         very least a process restart (and probably privileged access to servers by the

  1245.         person re-configuring the toggle too).</p>

  1246. </div>

  1247. 

  1248. <div id="ToggleConfigurationFile">

  1249. <h3>Toggle Configuration File</h3>

  1250. 

  1251. <p>Another option is to read Toggle Configuration from some sort of structured

  1252.         file. It's quite common for this approach to Toggle Configuration to begin life as

  1253.         one part of a more general application configuration file.</p>

  1254. 

  1255. <p>With a Toggle Configuration file you can now re-configure a feature flag by simply

  1256.         changing that file rather than re-building application code itself. However,

  1257.         although you don't need to re-build your app to toggle a feature in most cases

  1258.         you'll probably still need to perform a re-deploy in order to re-configure a

  1259.         flag.</p>

  1260. </div>

  1261. 

  1262. <div id="ToggleConfigurationInAppDb">

  1263. <h3>Toggle Configuration in App DB</h3>

  1264. 

  1265. <p>Using static files to manage toggle configuration can become cumbersome once

  1266.         you reach a certain scale. Modifying configuration via files is relatively fiddly.

  1267.         Ensuring consistency across a fleet of servers becomes a challenge, making changes

  1268.         consistently even more so. In response to this many organizations move Toggle

  1269.         Configuration into some type of centralized store, often an existing application

  1270.         DB. This is usually accompanied by the build-out of some form of admin UI which

  1271.         allows system operators, testers and product managers to view and modify Features

  1272.         Flags and their configuration. </p>

  1273. </div>

  1274. 

  1275. <div id="DistributedToggleConfiguration">

  1276. <h3>Distributed Toggle Configuration</h3>

  1277. 

  1278. <p>Using a general purpose DB which is already part of the system architecture to

  1279.         store toggle configuration is very common; it's an obvious place to go once

  1280.         Feature Flags are introduced and start to gain traction. However nowadays there

  1281.         are a breed of special-purpose hierarchical key-value stores which are a better

  1282.         fit for managing application configuration - services like Zookeeper, etcd, or

  1283.         Consul. These services form a distributed cluster which provides a shared source

  1284.         of environmental configuration for all nodes attached to the cluster. 

  1285.         Configuration can be modified dynamically whenever required, and all nodes in the

  1286.         cluster are automatically informed of the change - a very handy bonus feature.

  1287.         Managing Toggle Configuration using these systems means we can have Toggle Routers

  1288.         on each and every node in a fleet making decisions based on Toggle Configuration

  1289.         which is coordinated across the entire fleet. </p>

  1290. 

  1291. <p>Some of these systems (such as Consul) come with an admin UI which provides a

  1292.         basic way to manage Toggle Configuration. However at some point a small custom app

  1293.         for administering toggle config is usually created.</p>

  1294. </div>

  1295. 

  1296. <div id="OverridingConfiguration">

  1297. <h3>Overriding configuration</h3>

  1298. 

  1299. <p>So far our discussion has assumed that all configuration is provided by a

  1300.         singular mechanism. The reality for many systems is more sophisticated, with

  1301.         overriding layers of configuration coming from various sources. With Toggle

  1302.         Configuration it's quite common to have a default configuration along with

  1303.         environment-specific overrides. Those overrides may come from something as simple

  1304.         as an additional configuration file or something sophisticated like a Zookeeper

  1305.         cluster. Be aware that any environment-specific overriding runs counter to the

  1306.         Continuous Delivery ideal of having the exact same bits and configuration flow all

  1307.         the way through your delivery pipeline. Often pragmatism dictates that some

  1308.         environment-specific overrides are used, but striving to keep both your deployable

  1309.         units and your configuration as environment-agnostic as possible will lead to a

  1310.         simpler, safer pipeline. We'll re-visit this topic shortly when we talk about

  1311.         testing a feature toggled system.</p>

  1312. 

  1313. <div id="Per-requestOverrides">

  1314. <h4>Per-request overrides</h4>

  1315. 

  1316. <p>An alternative approach to a environment-specific configuration overrides is

  1317.           to allow a toggle's On/Off state to be overridden on a per-request basis by way

  1318.           of a special cookie, query parameter, or HTTP header. This has a few advantages

  1319.           over a full configuration override. If a service is load-balanced you can still

  1320.           be confident that the override will be applied no matter which service instance

  1321.           you are hitting. You can also override feature flags in a production environment

  1322.           without affecting other users, and you're less likely to accidentally leave an

  1323.           override in place. If the per-request override mechanism uses persistent cookies

  1324.           then someone testing your system can configure their own custom set of toggle

  1325.           overrides which will remain consistently applied in their browser. </p>

  1326. 

  1327. <p>The downside of this per-request approach is that it introduces a risk that

  1328.           curious or malicious end-users may modify feature toggle state themselves. Some

  1329.           organizations may be uncomfortable with the idea that some unreleased features

  1330.           may be publicly accessible to a sufficiently determined party.

  1331.           Cryptographically signing your override configuration is one option to alleviate

  1332.           this concern, but regardless this approach will increase the complexity - and

  1333.           attack surface - of your feature toggling system.</p>

  1334. 

  1335. <p>I elaborate on this technique for cookie-based overrides in <a href="http://blog.thepete.net/blog/2012/11/06/cookie-based-feature-flag-overrides/">this

  1336.           post</a> and have also <a href="http://blog.thepete.net/blog/2013/08/24/introducing-rack-flags/">described a

  1337.           ruby implementation</a> open-sourced by myself and a ThoughtWorks colleague.</p>

  1338. </div>

  1339. </div>

  1340. </div>

  1341. 

  1342. <div id="WorkingWithFeature-flaggedSystems"><hr class="topSection"/>

  1343. <h2>Working with feature-flagged systems </h2>

  1344. 

  1345. <p>While feature toggling is absolutely a helpful technique it does also bring

  1346.         additional complexity. There are a few techniques which can help make life easier

  1347.         when working with a feature-flagged system.</p>

  1348. 

  1349. <div id="ExposeCurrentFeatureToggleConfiguration">

  1350. <h3>Expose current feature toggle configuration</h3>

  1351. 

  1352. <p>It's always been a helpful practice to embed build/version numbers into a

  1353.           deployed artifact and expose that metadata somewhere so that a dev, tester or operator can

  1354.           find out what specific code is running in a given environment. The same idea

  1355.           should be applied with feature flags. Any system using feature flags should

  1356.           expose some way for an operator to discover the current state of the toggle

  1357.           configuration. In an HTTP-oriented SOA system this is often accomplished via

  1358.           some sort of metadata API endpoint or endpoints. See for example Spring Boot's

  1359.           <a href="http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html">Actuator

  1360.           endpoints</a>.</p>

  1361. </div>

  1362. 

  1363. <div id="TakeAdvantageOfStructuredToggleConfigurationFiles">

  1364. <h3>Take advantage of structured Toggle Configuration files</h3>

  1365. 

  1366. <p>It's typical to store base Toggle Configuration in some sort of structured,

  1367.           human-readable file (often in YAML format) managed via source-control. There are

  1368.           some additional benefits we can derive from this file. Including a

  1369.           human-readable description for each toggle is surprisingly useful, particularly

  1370.           for toggles managed by folks other than the core delivery team. What would you

  1371.           prefer to see when trying to decide whether to enable an Ops toggle

  1372.           during a production outage event: <b>basic-rec-algo</b> or <b>"Use a simplistic

  1373.           recommendation algorithm. This is fast and produces less load on backend

  1374.           systems, but is way less accurate than our standard algorithm."</b>? Some teams also

  1375.           opt to include additional metadata in their toggle configuration files such as a

  1376.           creation date, a primary developer contact, or even an expiration date for

  1377.           toggles which are intended to be short lived.</p>

  1378. </div>

  1379. 

  1380. <div id="ManageDifferentTogglesDifferently">

  1381. <h3>Manage different toggles differently</h3>

  1382. 

  1383. <p>As discussed earlier, there are various categories of Feature Toggles with

  1384.           different characteristics. These differences should be embraced, and different

  1385.           toggles managed in different ways, even if all the various toggles might

  1386.           be controlled using the same technical machinery. </p>

  1387. 

  1388. <p>Let's revisit our previous example of an ecommerce site which has a

  1389.           Recommended Products section on the homepage. Initially we might have placed

  1390.           that section behind a Release Toggle while it was under development. We might

  1391.           then have moved it to being behind an Experiment Toggle to validate that it was

  1392.           helping drive revenue. Finally we might move it behind an Ops Toggle so that we

  1393.           can turn it off when we're under extreme load. If we've followed the earlier

  1394.           advice around de-coupling decision logic from Toggle Points then these

  1395.           differences in toggle category should have had no impact on the Toggle Point

  1396.           code at all. </p>

  1397. 

  1398. <p>However from a feature flag management perspective these transitions

  1399.           absolutely should have an impact. As part of transitioning from Release Toggle

  1400.           to an Experiment Toggle the way the toggle is configured will change, and likely

  1401.           move to a different area - perhaps into an Admin UI rather than a yaml file in

  1402.           source control. Product folks will likely now manage the configuration rather

  1403.           than developers. Likewise, the transition from Experiment Toggle to Ops Toggle

  1404.           will mean another change in how the toggle is configured, where that

  1405.           configuration lives, and who manages the configuration.</p>

  1406. </div>

  1407. 

  1408. <div id="FeatureTogglesIntroduceValidationComplexity">

  1409. <h3>Feature Toggles introduce validation complexity</h3>

  1410. 

  1411. <p>With feature-flagged systems our Continuous Delivery process becomes more

  1412.           complex, particularly in regard to testing. We'll often need to test

  1413.           multiple codepaths for the same artifact as it moves through a CD pipeline. To

  1414.           illustrate why, imagine we are shipping a system which can either use a new

  1415.           optimized tax calculation algorithm if a toggle is on, or otherwise continue to

  1416.           use our existing algorithm. At the time that a given deployable artifact is

  1417.           moving through our CD pipeline we can't know whether the toggle will at some

  1418.           point be turned On or Off in production - that's the whole point of feature

  1419.           flags after all. Therefore in order to validate all codepaths which may end up 

  1420.           live in production we must perform test our artifact in <b>both</b> states: with 

  1421.           the toggle flipped On and flipped Off. </p>

  1422. 

  1423. <div class="figure " id="feature-toggles-testing.png"><img src="feature-toggles/feature-toggles-testing.png"/>

  1424. <p class="photoCaption"/>

  1425. </div>

  1426. 

  1427. <p class="clear"/>

  1428. 

  1429. <p>We can see that with a single toggle in play this introduces a requirement to

  1430.           double up on at least some of our testing. With multiple toggles in play we have

  1431.           a combinatoric explosion of possible toggle states. Validating behavior for each

  1432.           of these states would be a monumental task. This can lead to some healthy

  1433.           skepticism towards Feature Flags from folks with a testing focus. </p>

  1434. 

  1435. <p>Happily, the situation isn't as bad as some testers might initially imagine.

  1436.           While a feature-flagged release candidate does need testing with a few toggle

  1437.           configurations, it is not necessary to test *every* possible combination. Most

  1438.           feature flags will not interact with each other, and most releases will not

  1439.           involve a change to the configuration of more than one feature flag. </p>

  1440. 

  1441. <div class="soundbite">

  1442. <p>a good convention is to enable existing or legacy behavior when a Feature Flag is Off and new or future behavior when it's On.</p>

  1443. </div>

  1444. 

  1445. <p>So, which feature toggle configurations should a team test? It's most

  1446.           important to test the toggle configuration which you expect to become live in

  1447.           production, which means the current production toggle configuration plus any

  1448.           toggles which you intend to release flipped On. It's also wise to test the

  1449.           fall-back configuration where those toggles you intend to release are also

  1450.           flipped Off. To avoid any surprise regressions in a future release many teams

  1451.           also perform some tests with all toggles flipped On. Note that this advice only

  1452.           makes sense if you stick to a convention of toggle semantics where existing or

  1453.           legacy behavior is enabled when a feature is Off and new or future behavior is

  1454.           enabled when a feature is On.</p>

  1455. 

  1456. <p>If your feature flag system doesn't support runtime configuration then you

  1457.           may have to restart the process you're testing in order to flip a toggle, or

  1458.           worse re-deploy an artifact into a testing environment. This can have a very

  1459.           detrimental effect on the cycle time of your validation process, which in turn

  1460.           impacts the all important feedback loop that CI/CD provides. To avoid this issue

  1461.           consider exposing an endpoint which allows for dynamic in-memory

  1462.           re-configuration of a feature flag. These types of override becomes even more

  1463.           necessary when you are using things like Experiment Toggles where it's even more

  1464.           fiddly to exercise both paths of a toggle.</p>

  1465. 

  1466. <p>This ability to dynamically re-configure specific service instances is a very

  1467.           sharp tool. If used inappropriately it can cause a lot of pain and confusion

  1468.           in a shared environment. This facility should only ever be used by automated

  1469.           tests, and possibly as part of manual exploratory testing and debugging. If

  1470.           there is a need for a more general-purpose toggle control mechanism for use in

  1471.           production environments it would be best built out using a real distributed

  1472.           configuration system as discussed in the Toggle Configuration section above.</p>

  1473. </div>

  1474. 

  1475. <div id="WhereToPlaceYourToggle">

  1476. <h3>Where to place your toggle</h3>

  1477. 

  1478. <div id="TogglesAtTheEdge">

  1479. <h4>Toggles at the edge</h4>

  1480. 

  1481. <p>For categories of toggle which need per-request context (Experiment

  1482.             Toggles, Permissioning Toggles) it makes sense to place Toggle Points in the

  1483.             edge services of your system - i.e. the publicly exposed web apps that present

  1484.             functionality to end users. This is where your user's individual requests

  1485.             first enter your domain and thus where your Toggle Router has the most context

  1486.             available to make toggling decisions based on the user and their request. A

  1487.             side-benefit of placing Toggle Points at the edge of your system is that it

  1488.             keeps fiddly conditional toggling logic out of the core of your system. In

  1489.             many cases you can place your Toggle Point right where you're rendering HTML,

  1490.             as in this Rails example:</p>

  1491. 

  1492. <p class="code-label">someFile.erb

  1493. </p>

  1494. 

  1495. <pre class="code">  &lt;%= if featureDecisions.showRecommendationsSection? %&gt;

  1496.     &lt;%= render 'recommendations_section' %&gt;

  1497.   &lt;% end %&gt;</pre>

  1498. 

  1499. <p>Placing Toggle Points at the edges also makes sense when you are controlling access

  1500.             to new user-facing features which aren't yet ready for launch. In this context you can

  1501.             again control access using a toggle which simply shows or hides UI elements. As an

  1502.             example, perhaps you are building the ability to <a href="https://developers.facebook.com/docs/facebook-login">log in to your application using

  1503.             Facebook</a> but aren't ready to roll it out to users just yet. The implementation of

  1504.             this feature may involve changes in various parts of your architecture, but you can

  1505.             control exposure of the feature with a simple feature toggle at the UI layer which

  1506.             hides the "Log in with Facebook" button.</p>

  1507. 

  1508. <p>It's interesting to note that with some of

  1509.             these types of feature flag the bulk of the unreleased functionality itself might

  1510.             actually be publicly exposed, but sitting at a url which is not discoverable by

  1511.             users.</p>

  1512. </div>

  1513. 

  1514. <div id="TogglesInTheCore">

  1515. <h4>Toggles in the core </h4>

  1516. 

  1517. <p>There are other types of lower-level toggle which must be placed deeper

  1518.           within your architecture. These toggles are usually technical in nature, and

  1519.           control how some functionality is implemented internally. An example would be a

  1520.           Release Toggle which controls whether to use a new piece of caching

  1521.           infrastructure in front of a third-party API or just route requests directly to

  1522.           that API. Localizing these toggling decisions within the service whose

  1523.           functionality is being toggled is the only sensible option in these cases.</p>

  1524. </div>

  1525. </div>

  1526. 

  1527. <div id="ManagingTheCarryingCostOfFeatureToggles">

  1528. <h3>Managing the carrying cost of Feature Toggles</h3>

  1529. 

  1530. <p>Feature Flags have a tendency to multiply rapidly, particularly when first

  1531.         introduced. They are useful and cheap to create and so often a lot are created.

  1532.         However toggles do come with a carrying cost. They require you to introduce new

  1533.         abstractions or conditional logic into your code. They also introduce a

  1534.         significant testing burden. Knight Capital Group's <a href="http://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/">$460 million dollar

  1535.         mistake</a>

  1536.         serves as a cautionary tale on what can go wrong when you don't manage your

  1537.         feature flags correctly (amongst other things).</p>

  1538. 

  1539. <div class="soundbite">

  1540. <p>Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible.</p>

  1541. </div>

  1542. 

  1543. <p>Savvy teams view the Feature Toggles in their codebase as inventory which comes

  1544.         with a carrying cost and seek to keep that inventory as low as possible. 

  1545.         In order to keep the number of feature flags manageable a team

  1546.         must be proactive in removing feature flags that are no longer needed. Some

  1547.         teams have a rule of always adding a toggle removal task onto the team's backlog

  1548.         whenever a Release Toggle is first introduced. Other teams put "expiration dates"

  1549.         on their toggles. Some go as far as creating "time bombs" which will fail a test

  1550.         (or even refuse to start an application!) if a feature flag is still around after its

  1551.         expiration date. We can also apply a Lean approach to reducing inventory, placing

  1552.         a limit on the number of feature flags a system is allowed to have at any one time. Once

  1553.         that limit is reached if someone wants to add a new toggle they will first need to

  1554.         do the work to remove an existing flag.</p>

  1555. </div>

  1556. </div>

  1557.   </article>

  1558. </section>

  1559. 

  1560. 

  1561. <nav id="jumpto">

  1562.   <p>

  1563.     <a href="/david/blog/">Accueil du blog</a> |

  1564.     <a href="https://martinfowler.com/articles/feature-toggles.html">Source originale</a> |

  1565.     <a href="/david/stream/2019/">Accueil du flux</a>

  1566.   </p>

  1567. </nav>

  1568. 

  1569. <footer>

  1570.   <div>

  1571.     <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">

  1572.     <p>

  1573.       Bonjour/Hi!

  1574.       Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>

  1575.       Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).

  1576.     </p>

  1577.     <p>

  1578.       Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.

  1579.     </p>

  1580.     

  1581.     <p>

  1582.       Voici quelques articles choisis :

  1583.       <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,

  1584.       <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,

  1585.       <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,

  1586.       <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,

  1587.       <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,

  1588.       <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,

  1589.       <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,

  1590.       <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,

  1591.       <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,

  1592.       <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,

  1593.       <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,

  1594.       <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,

  1595.       <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,

  1596.       <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,

  1597.       <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,

  1598.       et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>

  1599.     </p>

  1600.     <p>

  1601.       On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.

  1602.     </p>

  1603.     <p>

  1604.       Je ne traque pas ta navigation mais mon

  1605.       <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>

  1606.       conserve des logs d’accès.

  1607.     </p>

  1608.   </div>

  1609. </footer>

  1610. <script type="text/javascript">

  1611.   ;(_ => {

  1612.     const jumper = document.getElementById('jumper')

  1613.     jumper.addEventListener('click', e => {

  1614.       e.preventDefault()

  1615.       const anchor = e.target.getAttribute('href')

  1616.       const targetEl = document.getElementById(anchor.substring(1))

  1617.       targetEl.scrollIntoView({behavior: 'smooth'})

  1618.     })

  1619.   })()

  1620. </script>