軟體開發中，「配置開關」根本算不上是乙個「新」概念。無論是通過啟動時載入配置，還是應用程式執行時動態重新整理配置，都可以用來決定或改變應用程式的某種具體行為。比如：
所有這些「開關」都被認為是理所當然的，因為使用者的需求就是這樣的，「我需要通過xx開關來控制yy」。因此，做為交付團隊，也會老老實實地把這些需求實現了。
然而，現在的很多團隊，為了能夠盡早發布軟體，使用主幹開發方式，並在程式中加入了另外一種「對使用者透明」的開關。這種開關通常有兩種使用場景是：
某些高階（或創新）的特性已經開發完畢，但業務人員根據市場情況，認為不需要投放市場。
市場需要某些已開發完成的特性，但還有一些特性尚未完成，仍舊處於開發中。
無論哪種情況，都是要求將某些特性進行隱藏後再發布。這種開關常常被認為是不可取的，但現在很多需要「持續交付」的公司都在使用。
開關最容易的地方就是應用程式的使用者介面。當為已上線的應用程式重新設計了全新互動介面後，團隊無法在一次性在同一發布週期中將其修改完成時，可以 先保留原有頁面不變，同時每次僅替換少數的新頁面。令所有未開發完成的頁面對使用者不可見，例如：原有頁面的url是 那麼對應的新頁面使用 /create_user（要對後台邏輯的修改應能夠同時響應新舊兩個頁面的請求）。當新頁面完成後，將原來建立使用者的頁面鏈結重新指向新頁面就可以了。 這樣，就能在不破壞原有功能的前提下，做到持續發布。
另外，對於那些無法在乙個發布週期內實現的新功能，我們可以使用下面形式的「開關」：
...etc...
public function isfeatureon(featurename:string):boolean
$/accounts/featurebits?useruid=&orguid=&而在編碼中，可以使用不同的實現方式：
if( registry.config.isfeatureon( featurename ) ) else else
public function createmaindisplay():displayobject else}
if( registry.config.isfeatureon("hq.trickle_reporting") )
**示例來自於：erik sowa,"feature bits" on slideshare.net
更多關於"持續交付"的內容請見
未完成的遊戲
半年前的某天，陽光穿過烏雲照射著滿是創痕的世界，我走在曾經熟悉的靜謐的寒冷的恐懼的街道。並沒有先前設想的那樣來一陣狂歡，大概是意識到了人生短暫，不應該花費過多精力在慶祝上。高考遠沒有預期的那樣滿意，不過我還是舒了一口氣，終於結束了。2015年的9月，寒雪社群掛上這樣一句話 由於種種原因，論壇暫時關閉...
未完成的工作
1 上下文不明確，需要明確重啟的場景，什麼情況下需要重啟？重啟是完成什麼功能的，配置生效？2 執行分析沒有串起來，從使用者下發重啟mml命令，到後台整個集群如何逐步完成重啟，操作結果如何展示給使用者 3 規格沒有明確，重啟多長時間完成？4 一些規格限制沒有明確，如mml必須先返回操作結果 5 異常場...
Chrome外掛程式開發練習 還未完成
manifest.json的內容 permissions popup.js的內容 function cityname var wholeurl prefixurl citycode surfix var configuration ajax configuration dalian param da...