Codeship公司CTO Florian Motlik客座文章
對於任何一家初創企業而言，行動靈活、迭代迅速並且以早期用戶及客戶反饋爲導向進行產品調整可以說是其一路成功發展的必要前提與核心手段。AWS社區英雄兼Netflix成功遷移至AWS雲基礎設施的幕後功臣之一Adrian Cockcroft就一直在強調“速度贏得市場”這一理念。時至今日，初創企業面臨着來自方方面面的競爭壓力，而這種壓力也迫使他們對自身產品作出變更與改進。
面對來自方方面面的競爭壓力，初創企業需要對自身產品作出變更與改進。
要保持初創企業跟上不斷變化的市場發展節奏並達到與之等同的速度提升效果，持續集成與持續交付無疑是必不可少的兩大最佳實踐。
持續集成與持續交付是什麼？
持續集成是指在任何將代碼提交至代碼庫時運行整體測試套件的過程。這種方式能夠幫助大家確保自己的應用程序按照預期般正常起效，且其中的變更內容不會帶來意料之外的狀況。
持續交付則意味着確保我們的代碼始終處於可部署狀態，甚至能夠在我們向主代碼庫作出變更的任意時間點被髮布至分期及生產基礎設施當中。這一機制當中還包括運行測試，也就是讓持續集成成爲持續交付流程的組成部分。這能幫助大家快速將新功能與新改進提供給客戶，同時從後者處快速得到反饋意見。
擁有一套出色的軟件開發與交付流程對於初創企業而言可謂意義重大，這一點我們在之前的工作流最佳實踐電子書當中已經進行過闡釋。
考慮到上述情況，在今天的文章中，我們將共同分享五項提示——我們的多家客戶已經將其納入實踐當中，並在長期執行的過程中藉此獲得成功，包括實現快速響應並打造出卓越的產品成果。
1.測試的目的在於提高用戶滿意度而非驗證軟件本身
在我看來，人們對於測試工作的最大誤區之一在於，大家往往認爲測試的目的在於驗證軟件是否能夠正常起效。事實上，保證用戶滿意度纔是測試的核心訴求所在。
當構建一款產品時，客戶通常會對我們提出兩大預期：
i. 不斷創新以支持新的需求類型。他們希望依賴產品供應商，要求後者能夠打造出適應其未來一到兩年當中各類實際需要的方案。
ii. 不要對原有系統造成破壞。
適當的測試手段能夠幫助我們確保在應用程序開發的同時，不至於給用戶帶來持續不斷的負面影響。此外，理想的測試機制還能爲大家帶來更爲自由的發揮空間，因爲只要能夠順利通過所有測試項目、即代表着我們不會對用戶的業務流程造成損害。換言之，理想的測試機制爲我們提供快速迭代所必需的速度與安全性保障。
在這方面，很重要的一點就是保證在測試結果全部通過的情況下，大家能夠完全信任測試套件的考查機制並將成果立即加以部署。具體來講，當測試結果一切正常時，我們需要充分信任這一結論，只有這樣才能實現持續交付的核心原則——隨時部署現有成果。在這種情況下，即使在週五晚上跟朋友們出去放縱一下也沒關係，因爲測試套件的可靠性給了我們充足的信心。以此爲前提，我們才能實現更快捷的實驗性嘗試並將新功能推向市場。
對於初創企業而言，用戶是推進產品開發與業務增長的主要動力所在。因此，我們必須儘可能避免不斷破壞自己的現有應用方案，因爲這往往會令客戶感到失望甚至憤而離去。
2.讓庫驅動基礎設施
在開發人員的日常工作當中，他們不應該將太多精力浪費在大規模生產基礎設施身上。相反，他們的注意力應該始終集中在代碼、或者說哪些代碼存在於哪些分支等問題上。當不同分支間的代碼進行合併後，成果應該馬上得到部署。
舉例來說，將來自某功能分支的代碼合併至另一分期或者生產分支當中，這意味着我們希望將其部署到基礎設施當中的各個對應層面。開發人員應該能夠始終關注代碼本身，並在代碼內容無誤時立即開始進行下一項任務——而不必擔心如何將其納入生產體系。
從我們的經驗出發，庫機制是實現這一理想工作流的絕佳方式之一——我們不斷使用這種方式，而且並沒有出現任何衝突。確保任何一點只存在有最後一次提交的代碼內容。通過這種辦法，開發人員能夠始終關注代碼與庫本身，而這也正是他們應該投入全部時間與精力的部分。
3.建立一套恆定的基礎設施
對於基礎設施這樣一套長時間運行的體系來說，我們很難對其進行復制，而這往往會引發一些潛在問題——例如bug需要數週時間才能徹底得到解決。有時候，基礎設施甚至會在毫無記錄的情況下發生變更。正是這一切消耗掉了開發人員的大量寶貴時間，而這些時間本應被用在處理他們的本職工作——也就是產品開發身上。
相比之下，恆定基礎設施當中包括大量恆定組成部分。每次進行部署時，設施都會根據需求更換各組件，而非像過去那樣對現有組件進行升級。這些組件皆源自一套通用型設計原型，此原型會在每一次部署操作時得以構建，並能夠接受測試與驗證。此外，如果大家希望在意外狀況之下由更新版本回歸至早期版本，這些原型甚至可以進行重新部署。此類通用原型可以通過自動化方式建立，不過如果各位願意，以手動方式完成亦無不可。
恆定服務器就像樂高積木：不要費力修復，拆掉重裝最方便。
這種恆定性不會因爲建立訪原型所使用的任何工具或者工作流而受到影響。其最佳用例應該運行在雲或者虛擬化環境當中。儘管也可以被引入非虛擬化環境，但在這種條件下恆定機制的優勢將受到嚴重影響，或者說收益將低於支出。
建立這樣一套恆定基礎設施要求大家的技術團隊以自動化方式完成任意組件的設置與部署工作，因爲各組件會不斷被替換並因此產生龐大的工作量。當某臺服務器由於某種原因而發生故障時，大家可以立即將其替換掉——正如玩樂高積木時那樣。
通過直接替換任何運行狀態與預期不符的服務器，大家可以輕鬆實現基礎設施的自我修復，也就是在運行過程中的任意時間點對組件進行更替。
Docker及其它容器技術方案通常能夠在這方面工作當中起到良好作用，不過大家也不要忽略掉Packer等非容器工具在構建AMI時所發揮的優勢——我們已經在這方面進行了長期驗證。將AWS CloudFormation與userdata及cloud-init配置相結合則構成了另一套工具，能夠幫助各位利用保存在代碼庫中的代碼實現系統的構建與配置工作。
4. 測量一切，記錄一切
在實現各部分組件部署工作的自動化之後，大家還需要確保引入適合的記錄與測量機制，從而瞭解整套基礎設施在任意時間點中的運行狀態。
這些數據將成爲保障基礎設施運維及穩定性的關鍵所在。我們需要在任意時間點上保持查看當前系統狀態並添加額外測量指標的能力。另外，大家還需要引入相關報警方案，這樣一來當基礎設施組件發生故障時，團隊成員能夠輕鬆訪問到全部相關數據而不必再將時間浪費在不斷跳轉當中。需要強調的是，單單對數據進行收集還遠遠不夠。如果無法保證每位團隊成員都能輕鬆加以訪問，那麼這些數據的存在將變得毫無意義。
目前可供選擇的日誌記錄與測量指標服務很多。AWSCloudWatch就同時支持日誌記錄與測量指標這兩項功能。
利用AWS CloudWatch深入瞭解基礎設施的運行狀態。
AWS ElasticBeanstalk支持面向Amazon S3存儲服務的日誌記錄功能。除此之外，Papertrail以及Librato Metrics（也就是我們所使用的方案）等服務亦能起到同樣的作用。最重要的是，大家應該選擇一家服務供應商，並立即開始自己的指標與記錄收集之旅。
在將測量指標與日誌記錄部署到基礎設施當中之後，請確保代碼庫中的每一項變更都受到所嵌入方案的正確記錄與測量。對代碼進行運維可以說是瞭解基礎設施運行狀態的重要一環，我們應當在代碼審查的過程當中對每一項代碼變更進行認真權衡。
5.關閉指向設備的訪問通道
隨時開放指向生產基礎設施會給團隊帶來非常負面的引導效果，也就是說成員們會不願在早期的中央位置出發着手進行指標與日誌記錄收集工作。此外，大家還需要在基礎設施的設計方案中考慮到對生產環境的調試需求。
爲了對團隊進行正確鼓勵，我們能夠採取的最佳舉措之一就是直接關閉掉指向生產基礎設施的訪問通道。或者，至少確保團隊成員需經過多次跳轉才能加以訪問。另外，爲了徹底消除這種訪問能力，大家可能還需要將SSH私人密鑰從AWS服務器當中完全移除。
如此一來，團隊中的每位成員就不得不對需要被保存在中央指標系統內的數據進行收集，從而順利完成調試工作。再次強調，對基礎設施直接進行訪問相當於保留了一條捷徑，其極具破壞性而且存在着巨大的安全隱患。消除這種訪問通道可以切實緩和可能出現的安全問題。
總結
對於任何一家軟件初創企業而言，向持續交付過渡並最終實現卓越的軟件開發流程都是一項非常重要的根本性任務，因爲其能夠在加快開發速度的同時確保大家不會對產品乃至客戶造成破壞性的影響。這種不影響應用程序本身而實現持續迭代並獲取客戶反饋的方式將幫助大家在市場競爭當中力壓羣雄、脫穎而出。
因此，請大家確保將充裕的時間及人力資源投入到持續交付工作的實現當中，如此一來各位將在企業運營的每分每秒享受到由此帶來的可觀回報。
原文鏈接：
核子可樂譯