GitHub免費支持CI/CD了，開發測試部署高度自動化，支持各種語言，網友：第三方涼涼

郭一璞 栗子 發自 凹非寺

量子位 出品 | 公眾號 QbitAI

GitHub激動地宣布，終于支持CI/CD了。

CI\CD，全稱：持續集成 (Continuous Integration) ，持續部署 (Continuous Deployment) ，是開發流程的自動化利器，如今可以在公有項目上免費使用了。

全面兼容各種操作系統，各種語言，以及各種云。

這次重大更新，發生在代碼運行平臺GitHub Actions身上。

Actions的角色，是把工作流自動化 (變成代碼) ，讓大家在GitHub服務器上直接測試代碼、部署代碼。

而內置了CI/CD之后，這個一條龍的開發者服務又進化了。

現在，已經有Beta版可以注冊試用，正式版也會在11月到來。

消息一出，程序員的世界熱火朝天。推特贊數1400+，Hacker News熱度也超過了500。

一面，是懷著喜悅迎接一個更強大的GitHub；

一面，微軟這一統天下的姿勢，也讓人感覺到，像CircleCI這樣的持續集成工具，可能要涼。就像之前發布的包管理工具，令NPM瑟瑟發抖那樣。

所以，支持了CI/CD的Actions，到底有多強？

海納百川，高度自動

按官方博客的說法，新的GitHub Actions能把搭建、測試、部署項目的整個流程，更加方便地自動化。

不管你用的是Linux、MacOS還是Windows。

也不管工作流是直接在容器上運行，還是在虛擬機上運行。

廣泛支持各種語言和框架：

Node.js，Python，Java，PHP，Ruby，C/C++，.NET，Android以及iOS。

如果，你想測試多容器的復雜應用，現在可以把你的網絡服務和數據庫一起測試。只要在工作流文件里，加上一些docker-compose就行了。

然后，詳細觀察一下功能：

矩陣構建?(Matrix Builds)

有了它，你可以把一個項目的許多版本并行測試。

只要在Actions YAML文件里，加上這幾行代碼：

 1jobs:
 2 test:
 3 name: Test on node ${{ matrix.node_version }} and ${{ matrix.os }}
 4 runs-on: ${{ matrix.os }}
 5 strategy:
 6 matrix:
 7 node_version: [8, 10, 12]
 8 os: [ubuntu-latest, windows-latest, macos-latest]
 9
10 steps:
11 - uses: actions/checkout@v1
12
13 - name: Use Node.js ${{ matrix.node_version }}
14 uses: actions/setup-node@v1
15 with:
16 version: ${{ matrix.node_version }}
17
18 - name: npm install, build and test
19 run: |
20 npm install
21 npm run build --if-present
22 npm test

剩下的工作，交給GitHub就可以了。

實時日志?(Live Logs)

實時日志，可以在你的builds運行過程中，為它們的進程 (Progress) 提供豐富的反饋。

系統會把你的日志傳輸到Actions控制臺，實時顯示狀態。

這個日志功能是為了易讀性而定制的，里面還有Emoji。

另外，你也可以用一個簡單的永久鏈接 (Permalink) ，來深度鏈接 (Deep Link) 到任何日志文件的任意一行。

這樣，就很容易和小伙伴討論一個故障，或者測試結果了。

像寫代碼那樣

action就是代碼。所以可以編輯，可以重復使用，可以分享，可以fork。

當你fork了一個項目，就同時fork了它的action，和它的源碼。

這是個無縫連接的方法，你可以用跟原始項目同樣的action來搭建、測試自己的項目。

團隊說，要向社區學習，這是一個很好的辦法。你有了喜歡的項目，重現它的每一步，然后fork過來適應自己的需要。

這里用了一種整潔的新語法 (Syntax) 來表達工作流，基于YAML。

你可以重復使用每個action和工作流，引用起來很容易，就像簡單的repo reference。

這樣，就可以輕松把它們拼接起來，變成強大的工作流。

可以用JavaScript寫出來，或者創建一個容器action，兩種方法都能通過GitHub API來交互，其他公開API也可以。

還有一個豐富的生態，可以重復利用，它來自GitHub的各路合作伙伴：比如LaunchDarkly、mabl、Code Climate、GitKraden。

甚至，你還可以觸發一個CircleCI上的build。

不止一種工作流

除了構建、測試、部署應用，你也可以用GitHub Actions來自動化其他任務：

比如，Issue的分類和管理，自動發布新版本，和你的用戶群協作等等。

在GitHub整個開發者周期里、任何一個事件上面，工作流都能被觸發。

并且，任何GitHub App都可以添加自定義事件。這樣，開發者和它們的伙伴，就能定制GitHub來滿足項目的需求了。

從集成包和容器注冊表上構建

包的發布和容器的發布，是CI/CD工作流上的關鍵部分。

比如開源一個庫，比如部署一個大型網絡服務。

GitHub Actions讓各種包的發布和使用，變得更容易了。

不管是GitHub Package Registry里面的包，還是其他注冊表里的包。

開發者能訪問Actions了，也就能訪問GitHub Package Registry，來自動化整個工作流，從構建到部署。

簡單上手

GitHub想讓你快點用上CI/CD功能。

于是，一旦你給項目啟用了Actions，GitHub就會根據你的項目，匹配一些合適的工作流推薦出來。

所有公開項目都可以免費使用。

而私有項目要用CI/CD，就有價格表了：

不過，現在是beta期間，一切都是免費的，快來注冊：

https://github.com/features/actions

至于企業版，團隊計劃明年推出。

CI/CD是到底是什么

看到這里，可能還有一些朋友沒有明白：

CI/CD到底是個啥？

CI：Continuous Integration，持續集成，指的是一個團隊的所有開發人員每天多次把自己手里的代碼合并到主干中去，用一致的自動化方法來構建、打包和測試程序，可以頻繁修改代碼，提升軟件質量，便于團隊協作。

CI可以實現自動化測試，更早拿到測試結果，防止有問題的代碼被交付出去，也更容易編譯，降低了測試成本和和時間。

CD則有兩個概念，一個是Continuous Delivery，持續交付，在CI中構建自動化的測試流程后，持續將代碼發布的存儲庫，不一定部署到生產環境中。

持續交付對于細微的變更十分有用，可以加速迭代過程。

另一個是Continuous Deployment，持續部署，通過自動化的構建、測試和部署循環來快速交付高質量的產品，直接部署到生產環境中，用戶可以感受到產品的變化，不需要做專門的發布更新，而是修改之后幾分鐘就上線了。

持續部署可以使發布頻率更高，每次提交自動觸發發布流，降低了小批量發布的風險，用戶體驗也能持續提升，不用每次都等更新。

議論紛紛

原本要靠第三方才能實現的功能，現在GitHub自己就干了，這當然引來了許多程序員的熱烈歡迎，沒多久，GitHub推特的評論區里歡呼聲此起彼伏：Awesome! Cool! Amazing!

之前那些CI工具，可能日子就不好過了。

一大批CI工具面臨涼涼

不過，既然GitHub自己出了CI/CD功能，那么以前那些第三方CI工具，大家還會用么？

不少人已經開始揮手拜別了：

也有人看到多系統支持這一點就非常high:

哇哦，支持MacOS？這一點就足夠我從CircleCI遷移過去了，40美元一個月的CircleCI，對于一些React Native應用CI/CD是足夠了，但CD只能一個星期一次。

TravisCI、CircleCI這些工具，可能要面臨用戶流失糟糕狀況了。比如Hacker News上的這位CircleCI用戶：

對我來說這很有趣，讓我想到壟斷的自然崛起和技術中的多元文化。GitHub最近仿佛要“吃掉整個世界”，比如之前的軟件包管理，給了Artifactory也Nexus不小的撼動。現在搞這個，可能對CircleCI是個壞消息（我是CircleCI的用戶）。

作為一名開發者，短期來看我確實喜歡這個，不用再東拼西湊那么多東西，頭疼如何把它們整合在一起，如果GitHub不行了，CircleCI也不能用了，我們只要把氣全撒在GitHub頭上就好咯。

但是長遠來看，這樣競爭環境就出問題了，作為一個創業公司員工，要是有大平臺的大廠跑來跟你競爭這是很難搞的事，即使你產品更好，也敵不過大平臺的力量，畢竟他們集成了更多價值。

微軟的野心：把GitHub用戶導流到Azure？

也有人懷疑，此舉是微軟在給Azure鋪路，借GitHub的用戶量導流，目標還是瞄準了云計算市場。

作為一個.NET開發者，這就像吸引更多人去用Azure DevOps，進而讓他們成為Azure云的用戶，這是最后一步，終究是為了擴大云計算的市場。

我覺得對微軟來說一個好的策略是讓GitHub的CI/CD代碼和Azure DevOps盡可能重復，Azure DevOps不需要這么靈活，只要保持魯棒性就好了，GitHub可以當一個試驗場。

所有的路都導向Azure，GitHub的用戶基礎比Azure大得多，微軟想給自家IaaS獲取更多用戶。

估計在GitHub Actions里搞CI/CD的下一步就是讓GitHub能自己跑產品代碼，這樣買Azure云服務就省去了很多步驟。在一個地方運行代碼，停掉再用一個單獨的工具組件是很隨意的事，在一個地方有整個套件在這個市場是很明顯的事。

所以，你怎么看呢？

—?完?—