的産品名面向業界開發開放。
講師簡介：董越，進階産品專家。在軟體研發管理領域鑽研十餘載，是《未雨綢缪——了解軟體配置管理》等書的作者或譯者。2014年加入阿裡，目前從事阿裡巴巴軟體研發協同平台（Aone/雲效）的産品設計工作。
概述同學們好。為了讓新同學能夠比較快速的開始在阿裡巴巴研發環境下的開發，我們設計了幾門課程。其中，本節課程是百技課程-代碼服務的接續課程，介紹源代碼寫好後，如何釋出上線的内容。這包括：從源碼到上線、品質檢測的多種方法、流水線三個部分。其中每一部分，在本文中都是概要性的介紹，并給出相應的參考文檔，作為進一步學習的資料。
學習了這門課程，大家就知道了在阿裡寫完源代碼之後，要做哪些事情，使用什麼工具，就能把軟體安全釋出上線。
從源碼到上線，事情可不簡單問大家一個問題，什麼叫程式？或者說，什麼叫軟體？好像這裡面有歧義。有時候指的是源代碼。有時候指的是安裝包或者安裝CD光牒，比如，“我下載下傳了一個軟體。” 而有時候指的是已經安裝好随時可以運作的程式。比如手機上新裝了一個應用。還有的時候指的是正在運作中的，正在提供服務的程式，比如一個網站。
有這些不同的含義，其實反映了一件事情：單純的源代碼，其實還不能提供服務，不能為使用者帶來價值。隻有源代碼被建構打包，并且被部署運作起來，才能為使用者帶來價值。
那麼，如何才能部署運作起來，為使用者提供服務呢？這很麻煩嗎？是的，這很麻煩。
想象一下，你是一個初創企業的CTO。忽然天上掉餡兒餅，掉下來五個Git庫，源代碼已經寫好，而且一點兒毛病沒有。每個Git庫能編譯成一個war包。你需要把每個war包部署到100台伺服器上，總共需要500台伺服器。哦對了，随着使用者使用，會不斷追加新功能，産生新版本，需要更新伺服器上的軟體版本。
假定你不是在阿裡巴巴。假定也沒有阿裡雲。假定你隻是有很多錢可以雇到合适的人。你想想一共有多少事情要做？
要買伺服器。哦不，先要買或者租機房。風火水電要搞穩妥。要接好網絡。每台機器要裝好作業系統的合适版本。不止是作業系統，還有相關基礎軟體。還有路由。還有資料庫，還有監控系統，還有日志收集系統。中間件也是必須的。哦，域名還忘了申請了……
這些搞定了，才能安裝那些war包。這麼多台，肯定不能一台一台操作，累死了，得有個批量操作的方法。可這方法怎麼弄呢？另外，考慮到将來要更新軟體版本，是以這還不是一次搞定的事情。那更是得批量操作了。更新版本的時候，還有個麻煩事，不能一下子都停機啊。那不就事故了。是以得分批來。比如，先更新20%的機器，再更新20%，如此一共五批弄完。
往細節看，其中更新某一台機器，其實都是個挺複雜的過程。首先下載下傳新的war包到這台機器，然後開始替換過程。先得把流量切走吧，切流量前，還得先把監控報警關上。流量切走了，就可以停止目前war包的運作。然後用新的war包代替舊的war包，啟動試試看。如果通過了一些基本的自動檢測，說明新war包大體上能運作，于是就開始切流量回來，最後把監控報警恢複。忒麻煩！！
還 好有工具幫忙怎麼辦？用趁手的工具啊。正是為了提高大家的工作效率，讓大家能夠集中精力在具體業務本身的研發上，阿裡巴巴集團多年以來建設了一整套基礎設施。
在傳遞層和運維層，都有大量的基礎設施。但這些，大家可能感受不深。因為對于一個應用來講，它最關心的事情，基本都是通過Aone暴露出來的。Aone也就是最上層研發層的主要工具。
回到前面讨論的場景，把完美的源代碼釋出上線這個過程，那麼大體步驟應該是：
·
第一步，把運作環境初始化好。這一步目前同學們基本可以在Aone上一站式完成了，就是在Aone上注冊一個新應用，然後根據向導指引，把上線任務一項一項配下來。當然還有些内容比如資料庫還需要通路其他系統申請配置，将來我們努力做成一站式配置好。
· 第二步，根據源碼建構出壓縮包（基本就是把war包壓縮一下），然後把壓縮包部署到各目标伺服器上。這一步，可以在Aone上一鍵完成。将來更新版本也一樣。點一下按鈕，所有事情都做完。這就是用Aone的好處。
阿裡巴巴相 關術語 為了使用Aone，我們得了解一些Aone的關鍵概念。其實是在阿裡巴巴開發時，大家一開始約定俗成的概念，後來固化在Aone上。我們一個一個來看：- 應用 ：Git庫裡裝的是源代碼，這是程式的一種形态。那麼運作中的程式叫什麼呢？在阿裡巴巴，我們管它叫應用。一般來說，一個Git庫，建構生成一個包，産生一個應用，在若幹台伺服器/虛拟機/容器中運作，在測試、線上環境中運作。一般應用跟Git庫是一比一的關系不過也有各種特殊情況，比如一個Git庫裡有多個應用。是以，我們确實需要應用這個概念。另外，應用不僅包括了應用主包（通常是war包打成tgz包），也包括了運作所需環境的配置，比如tomcat版本等。
- 二方包 ：三方包，指的是來自阿裡巴巴外部的，開源或商業的包，比如jar包、rpm包等。而二方包，則是指來自阿裡巴巴内部的，通常是其他團隊的包。也就是說，一個團隊研發出這個二方包，公布出來，供各團隊使用。當然，也可能就是供團隊自己使用。反正，隻要是來自阿裡内部的，上傳到Nexus或Yum這樣的包的倉庫的，就都算二方包。
- 産品 / 産品線 産品樹 ：應用是從部署運維的角度看運作中的程式。産品是從使用者的角度看運作中的程式。通常産品由一到多個應用組成。産品進而構成産品線，這樣一級一級的上去，形成了一棵樹，叫産品樹。産品樹的根節點，就是阿裡巴巴。産品樹的第一級展開，是各個BU。
- 變更 ：在外面的世界，現在變更通常是指線上運作環境的變化，比如更新了軟體版本，比如擴容縮容等運維操作。在阿裡巴巴，變更也有這個含義。但是在阿裡巴巴，變更還有一個含義，軟體研發過程中的含義。通常我們把一條feature分支就對應到一個變更。于是也常管這條feature分支叫變更分支。從這個角度看內建，就是把若幹變更攢到一起，通過各種品質檢測後，部署上線。
- 釋出 ：釋出，release，這個詞常常是指軟體版本公布出來供使用。但在阿裡巴巴，這個詞不僅對應于部署到線上環境，即使是部署到測試環境，也叫釋出。換句話說，釋出基本上就是部署的代名詞。比如每個變更覺得自己OK了，就點一下變更詳情頁面上的“送出待釋出”這個鈕，标記一下。然後，在內建測試環境（也就是日常環境）對應的流程階段的詳情頁面，就能看見這個變更。再選中它，然後點選“送出釋出”這個鈕，就與其他變更分支一起合并到釋出分支，并部署到測試環境啦。
釋出部署方面，在阿裡巴巴，時下最重要的變革當然是Docker化啦。這方面的文章很多，比如阿裡人，請用AliDocker、以及具體指導T4 應用遷移 docker 釋出。
那麼這一波浪潮之後，下一波浪潮會是什麼呢？有可能是Serverless架構。這方面，外面的文章也很多，大家可以翻翻看。
提高 質 量的多種方法剛才我們給的是一個天上掉餡兒餅的例子，忽然間得到了完美的源代碼，然後考慮建構并部署上線。現實世界中哪兒有這樣的好事兒啊。代碼裡面肯定有bug啊。那麼，怎麼能夠有效率地把問題找出來，修複好？具體有哪些方法？
按四個象限梳理為友善梳理，我們劃一個橫軸，一個縱軸，然後按照得到的四個象限，梳理各種品質保證方法。這裡所說的橫軸，在最左邊，是源代碼。在最右邊，是運作中的程式。這裡所說的縱軸，在最上邊，是自動化，在最下邊，是人工。
先看左半部分。左下角，人工的對源代碼的檢測。這主要對應的是代碼評審。我們在代碼服務這門課上介紹的。此外，安全評審有時也有人工介入。
左上角，自動的對源代碼的檢測。代碼規約的自動檢查工具，就落在這裡。事實上，還有不少工具也落在這裡，論品牌，有Sonar、PMD等。論方法，有圈複雜度等。所有這些自動檢測，被稱之為Static
program analysis 或 Static code analysis，靜态程式分析/靜态代碼分析。
這方面，在阿裡巴巴有工具支援，對應的是Aone的實驗室這個功能。可以通過實驗室，接入各種靜态程式分析工具和方法。實驗室的前身是CISE。現在CISE也仍然是實驗室背後的引擎。是以有時候聽别人說CISE的時候，你就知道其實指的就是實驗室啦。
再來看右半部分。右上角，是自動的對運作中的程式的檢測。這也就是常說的自動測試啦。在阿裡巴巴，也是主要由Aone的實驗室來向大家提供相應服務。這包括單元測試/內建測試；接口測試/Web UI測試；功能測試/性能測試，等等。
右下角，是人工測試。雖說是人工測試，工具也同樣可以提供支援，主要是管理測試用例。相應的工具是Aone中的測試用例管理。
測試環 境隔離技不論是自動測試還是人工測試，隻要是需要先把應用部署到測試環境，那就跟測試環境的管理有關系了。測試環境的管理，我們專門講一講測試環境隔離技術。
想象一下，你開發了一個feature，也就是一個變更。為了讓它比較靠譜再送去內建，你需要對它進行測試。單元測試當然好，但是是不夠的。需要盡可能模拟真實環境進行測試。那麼問題來了，如何盡可能模拟真實環境？比如，為每個淘系的工程師另搭一個淘寶測試用？這費用咱真花不起……
怎麼解決這個問題？阿裡巴巴用了一個聰明的方法，測試環境隔離。讓大家共享一個測試環境，但又仿佛每個人都是獨占它的，互相不幹擾。
具體說來，假定搭起一套測試環境，需要1000台機器，分别運作應用ABCDE……。這個環境我們稱作日常測試環境。每個應用的版本呢，我們姑且稱之為A0、B0、C0、D0、E0……
現在假定甲這名同學在開發A這個應用的一個變更，在開發過程中，現在産生的應用版本是A1。于是把A1部署到單獨一台機器上，并用一些神奇的技術（通過中間件等）與剛才說的日常測試環境連通。于是，在甲這名同學看來，他所面對的系統是A1、B0、C0、D0、E0…… 而且仿佛他獨占了這個系統。
類似的，如果乙這名同學為了一個feature，在開發A和B分别拉出變更分支，産生A2、B2。那麼A2、B2将分别被部署到單獨的機器上，然後它們一起與日常測試環境連通。于是，在乙這名同學看來，他所面對的系統是A2、B2、C0、D0、E0…… 從乙的角度看，他仿佛獨占了整個測試系統。甲和乙在測試時，不會互相幹擾。
有了這樣的解決方案，就同時達到了兩個目标：盡量模拟真實的環境；用不高的代價。
關于測試環境隔離技術，這裡隻是簡單介紹下原理。
·
項目環境：就是前面說的，測試一個feature所需的測試環境。可能對應一個應用上的一個變更，也有可能對應多個應用。項目環境使用了上面講的測試環境隔離技術，背後接的一整套測試環境，是日常環境，詳見下面。
日常環境：就是內建測試環境。把各個變更攢在一起，然後部署到這裡，看是不是能work。
預發環境：這個環境比日常環境更接近真實環境。事實上，從網絡隔離的角度，它不是在測試網，而是在生産網。它所連接配接的資料庫，也通常就是線上運作使用的資料庫。一般來說，是先在日常環境測試，通過了再到預發環境測一下。
正 正 式環境：正式環境就是生産運作的真實環境，向廣大使用者提供服務。
流水 線：所謂流水線，通俗的講就是把不同的工作按一定順序串起來。為什麼要串起來呢？
首先，有些工作天生就是有先後順序的。如果想部署，總得先建構吧。是以建構-部署，就是天然的工作順序。如果每次都是先點個按鈕做建構，等建構結束後再點個按鈕做部署，那好像有點兒笨啊，不如點一個按鈕，把這兩件事按順序都做了。
其次，為保證品質，我們想往流程裡面加規則和卡點。比如，必須通過代碼評審和安全評審，才允許合并代碼。這些品質保證性的工作，還有可能有不同的順序和頻率。典型的，單元測試和靜态程式分析應該早做，頻繁的做。而整個鍊路的測試，比較費勁，頻率可以相對低些。是以，這些工作也是流水線中的環節，并且可能以不同頻率執行。不同頻率這個事兒，就是持續傳遞這個流行詞兒中所說的不同stage(階段)不同頻率。
Aone提供了把不同的工作串接的能力，也就是流水線的能力。在分支模式下，每個環境，比如日常、預發、正式，分别對應一條流水線。在Git Flow和自由模式下，你甚至可以把所有工作内容，從代碼送出到最後正式釋出，做到一個流水線裡。看着代碼過一道道“關口”，然後釋出上線，還是很爽的。
結語以上，概要介紹了從源代碼到上線的基本的建構部署過程，講解了各種品質保證方法及其工具支援，講解了流水線把流程作業連接配接起來自動運轉。這些能力合在一起，就實作了對持續傳遞的一整套工具支援方案。當然，如果你問DevOps的工具支援方案，我也會說，以上幾部分，構成了DevOps的工具支援方案…… 名字是次要的，關鍵是幫上廣大研發同學的忙，高效且穩妥的開發和釋出。
這節課隻是概要介紹。更多内容，阿裡内部的童鞋可參考老A小談的玩兒轉項目環境這場，或文字版開發如何玩轉Aone項目環境。
備注：外部的童鞋可以使用Aone的雲上版本
，體驗一個阿裡技術人工作的一天！
Work like alibaba系列直播内容幹貨專題頁面已經上線，所有圍繞代碼托管/持續傳遞/測試管理/項目協作的分享幹貨均可點
此處通路。