Atlassian是怎樣進行持續交付的？且聽 Steve Smith一一道來

Steve ：實際上，在我們實施持續交付時總共面臨著三方面的問題：有技術方面的，也有組織和管理方面的問題。

首先來談一下技術方面的問題，這方面的問題是比較明顯的。包括搭建服務器、設置機器、創建必須的腳本用于自動部署相關的變更，等等。但還有一些更微秒的挑戰，會隨著對深入交流的需求而漸漸浮出水面。一旦你創建了某種環境，能夠實現將變更一鍵部署到生產環境，你就需要確保所有團隊都保持靈活與開放式的溝通，而不會因為變更的節奏加快而使他們失去警惕性。Atlassian是一個高度分布式的公司，它的辦公室遍及悉尼、越南、阿姆斯特丹和舊金山，傳統的溝通渠道無法滿足我們的需求。我們所需的溝通能力不僅能夠讓人們簡單地進行信息交換，還能夠在團隊之間建立密切的關聯。因此我們在這方面的技術上投入了很大精力，這些技術能夠讓我們實現高質量視頻會議、共享圖片、團隊聊天等等，對于我們十分關鍵。

分布式團隊面臨的另一個問題與時區的不同有關。如果你需要與某位同事進行協作，只要你們處于同一時區，即使是身處不同的辦公室，也能夠很方便地進行視頻會議、共享屏幕。但如果你與同事處于不同的時區，那么就需要尋找某些工具，能夠幫助你進行線下協作。你可以提交一個pull請求，讓同事幫你審查某個變更。但同時，為了實現這一點，需要某些工具幫助你方便地檢索相關的變更，并且以一種集成的方式提交反饋。并且所有這些工具必須與其它工具進行集成，以提供一種無縫的工作流體驗。

這就帶來了組織方面的變更。一般來說，人們對于任何改變都是相當謹慎的。當開發者開始習慣于創新新服務的思想，那么系統管理員就會對由此帶來的網絡變更而感到擔憂。當開發者開始部署容器化的應用（使用Docker或類似技術），系統管理員則會對于容器中可能包含的軟件，以及它所帶來的整體影響心存顧慮。與之類似的是，如果系統管理員要求開發者以某種特定的方式編寫應用，或是對某種技術的使用進行干預，開發者也會因為缺乏自由而感到不快。只有在所有人齊心協力的前提下，持續交付才能夠發揮其作用，所有團隊之間必須進行合作，才能夠讓變更順利地生效。

最后，我們還遇到了大量管理方面的問題。Atlassian提倡一種文化“想要尋求怎樣的改變，就要身體力行”，這鼓勵人們努力推動他們所期望的改變。它能夠讓人們打破技術壁壘，鼓勵人與人之間的互動。但同時它也帶來了大量的問題，例如由誰來管理風險，或者說由誰擔當某種改變的最終業務負責人。Atlassian處理著大量的客戶請求，因此我們必須對相關的風險加以管理，這意味著像SOX和PCI這樣的制度會對我們的內部流程施加影響。我們需要適當地分配責任，對軟件進行變更的人與最終將其發布到生產環境中的人必然是不同的，因此在持續交付服務中需要引入控制功能，讓特定的角色能夠對某個特定的檢查點進行校驗。

Steve ：創建一種工作流的思想非常重要。問題跟蹤系統為某個特定請求過程中發生的每一件事創建了一個流程的標識符，使每個人都能夠對它的狀態進行從頭至尾的全程跟蹤。通過將問題跟蹤系統與VCS和CI進行集成，提出這個ticket的人就能夠看到它的任何變化：開發過程是何時開始的、問題是何時出現的，并且經過了怎樣的處理、以及它是何時部署的等等。這樣一來，人們就能夠更好的了解相關信息，對于整個流程的滿意度也更高。

這一點也為開發者帶來了一種積極的副作用：因為項目干系人能夠隨時找到所需的信息，他們就不必再去打擾開發者、系統管理員或其它任何人。這種趨勢正在得到人們的認可，舉例來說，大多數云系統都提供了某種狀態頁面，展示了每個系統的運行狀況，因此每個人都能夠隨時了解相關情況。

由于我們所用的問題跟蹤、版本控制以及CI系統都是Atlassian自身的產品，因此它們從一開始就是緊密集成的。不過他們的相互集成是通過公開的RESTful API實現的，因此其它產品也能夠通過對相關的終結點進行相應的調用而實現集成。

InfoQ：在你的演示中，使用特性分支是整個方法的核心，與將所有代碼都放在master分支的策略相比，這種策略是否存在某種缺陷？

Steve ： 如果你的多個特性之間存在著聯結性，它們就會變得非常復雜。同時，如果他們之間存在相互依賴，或是需要對方進行某種改變，問題就會出現。不過，一旦發生這種問題，這很可能意味著他們實際上是一個特性，因此這兩個問題應當被合并在一起。

有時，這種互依賴性更多地是由技術方面導致的。如果公開暴露的API沒有足夠的封裝性，使用者就可能會對其它系統的內部工作進行某些假設，導致了人為的互依賴性。因此遵循優秀的編程實踐是關鍵，并且要確保技術依賴性不可進一步變為業務方面的依賴性，這將妨礙你在并行的分支中開發并行的功能。

最后，你需要時刻牢記，當你創建某個特性分支時，就是對主線的一次轉移。因此你需要經常進行rebase，或從master分支進行pull操作，以確保你的特性分支的經常更新。否則，最后的合并工作可能會面臨極大的挑戰。

Steve ： 這一點又回到了測試的基本思想：測試是一組被編寫的代碼，但不會部署到生產環境中。在某些人一眼看來這似乎是一種浪費。然而，隨著時間的推移， 已經有大量的研究證實了測試的價值 。

對于持續交付來說也存在著同樣的爭議：對于任何一個有一定復雜度的軟件項目來說，開發的成本都是最高的。因此，為了保證軟件能夠正常工作，這就是對于進行測試所必須的基礎設施投入成本的理由。運行測試的資源成本往往低于開發者的時間，以及未能及時找到bug所帶來的影響，這就意味著測試資源是值得投入的。這也是為什么許多CI系統都支持按需進行縱向擴展，以使用云端的資源。為了應對峰值時的請求而進行臨時性的縱向擴展，通常來說都是值得的。

最終，這些額外的成本會將敏捷理念帶到下一級別：提供更小的反饋循環，以及盡快交付。

Steve ： 目前在實施持續交付的人可以說在站點了科技的前沿，因為CD的理念才剛剛得到普及。最大的困難或許在于如何在內部進行推銷：搭建這一整套過程可能要花上很長時間，而要向那些保守的管理人員灌輸CD的價值也是非常困難的。關鍵在于向人們傳授知識，告訴他們CD能夠帶來的益處，并將信息傳遞給所有角色（系統管理員、項目干系人、風險管理員等等），讓他們認可這一點是大家共同的思想。你無法強行推行這一舉措，或者只是因為別人這么做而跟風。

大型組織需要理解每種CD系統都是不同的。要在其中找到一個共性，使整個過程成為可重復的，這一點或許并不容易。此外，其中的某些權衡之處可能使它未必對于每個人都有好處，因此對于每種特定的情況都需要進行分析。它還對組織的文化有所要求，要做到對變更進行積極地反應，而不是一開始就設計好所有的計劃。

容器技術或許能夠對整個搭建流程有所幫助，雖然它自身也必須克服一些挑戰。其中主要的問題在于安全性，尤其是如何對容器中的軟件進行管理，并保證它的實時更新。傳統情況下，這一過程是由系統管理員負責的。但由于現在開發者也能夠創建容器，因此這一責任也延伸到其它團隊了。我們要對所有權進行重新定義，可以采取共同所有權的形式。

另一方面，像Puppet和Chef這樣用于創建大量機器的技術，它們的管理是通過配置實現的。而這種配置如今看上去越來越像代碼了，這也意味著系統管理員不得不應用一些軟件開發的實踐。此外，如果業務分析師也希望參與持續交付的流程，對哪些特性在何時部署到生產環境進行校驗，那他們也必須熟悉開發者所使用的工具。

這也意味著組織中的每個人不得不成為某種通才，公司必須鼓勵進行跨職能的培訓，才能夠實現這一點。Pull請求對這一點能夠有所幫助，每個部門或角色都可以請求其它部門對變更進行審查和批準，然后再繼續下一流程。