GitHub免費支持CI/CD了，測試部署高度自動化
本文經AI新媒體量子位（公眾號ID:QbitAI）授權轉載，轉載請聯系出處。
GitHub激動地宣布，終于支持CI/CD了。
CI\CD，全稱：持續(xù)集成 (Continuous Integration) ，持續(xù)部署 (Continuous Deployment) ，是開發(fā)流程的自動化利器，如今可以在公有項目上免費使用了。
全面兼容各種操作系統(tǒng)，各種語言，以及各種云。
這次重大更新，發(fā)生在代碼運行平臺GitHub Actions身上。
Actions的角色，是把工作流自動化 (變成代碼) ，讓大家在GitHub服務器上直接測試代碼、部署代碼。
而內置了CI/CD之后，這個一條龍的開發(fā)者服務又進化了。
現在，已經有Beta版可以注冊試用，正式版也會在11月到來。
消息一出，程序員的世界熱火朝天。推特贊數1400+，Hacker News熱度也超過了500。
一面，是懷著喜悅迎接一個更強大的GitHub；
一面，微軟這一統(tǒng)天下的姿勢，也讓人感覺到，像CircleCI這樣的持續(xù)集成工具，可能要涼。就像之前發(fā)布的包管理工具，令NPM瑟瑟發(fā)抖那樣。
所以，支持了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文件里，加上這幾行代碼：
- jobs:
- test:
- name: Test on node ${{ matrix.node_version }} and ${{ matrix.os }}
- runs-on: ${{ matrix.os }}
- strategy:
- matrix:
- node_version: [8, 10, 12]
- os: [ubuntu-latest, windows-latest, macos-latest]
- steps:
- - uses: actions/checkout@v1
- - name: Use Node.js ${{ matrix.node_version }}
- uses: actions/setup-node@v1
- with:
- version: ${{ matrix.node_version }}
- - name: npm install, build and test
- run: |
- npm install
- npm run build --if-present
- npm test
剩下的工作，交給GitHub就可以了。
實時日志 (Live Logs)
實時日志，可以在你的builds運行過程中，為它們的進程 (Progress) 提供豐富的反饋。
系統(tǒng)會把你的日志傳輸到Actions控制臺，實時顯示狀態(tài)。
這個日志功能是為了易讀性而定制的，里面還有Emoji。
另外，你也可以用一個簡單的永久鏈接 (Permalink) ，來深度鏈接 (Deep Link) 到任何日志文件的任意一行。
這樣，就很容易和小伙伴討論一個故障，或者測試結果了。
像寫代碼那樣
action就是代碼。所以可以編輯，可以重復使用，可以分享，可以fork。
當你fork了一個項目，就同時fork了它的action，和它的源碼。
這是個無縫連接的方法，你可以用跟原始項目同樣的action來搭建、測試自己的項目。
團隊說，要向社區(qū)學習，這是一個很好的辦法。你有了喜歡的項目，重現它的每一步，然后fork過來適應自己的需要。
這里用了一種整潔的新語法 (Syntax) 來表達工作流，基于YAML。
你可以重復使用每個action和工作流，引用起來很容易，就像簡單的repo reference。
這樣，就可以輕松把它們拼接起來，變成強大的工作流。
可以用JavaScript寫出來，或者創(chuàng)建一個容器action，兩種方法都能通過GitHub API來交互，其他公開API也可以。
還有一個豐富的生態(tài)，可以重復利用，它來自GitHub的各路合作伙伴：比如LaunchDarkly、mabl、Code Climate、GitKraden。
甚至，你還可以觸發(fā)一個CircleCI上的build。
不止一種工作流
除了構建、測試、部署應用，你也可以用GitHub Actions來自動化其他任務：
比如，Issue的分類和管理，自動發(fā)布新版本，和你的用戶群協作等等。
在GitHub整個開發(fā)者周期里、任何一個事件上面，工作流都能被觸發(fā)。
并且，任何GitHub App都可以添加自定義事件。這樣，開發(fā)者和它們的伙伴，就能定制GitHub來滿足項目的需求了。
從集成包和容器注冊表上構建
包的發(fā)布和容器的發(fā)布，是CI/CD工作流上的關鍵部分。
比如開源一個庫，比如部署一個大型網絡服務。
GitHub Actions讓各種包的發(fā)布和使用，變得更容易了。
不管是GitHub Package Registry里面的包，還是其他注冊表里的包。
開發(fā)者能訪問Actions了，也就能訪問GitHub Package Registry，來自動化整個工作流，從構建到部署。
簡單上手
GitHub想讓你快點用上CI/CD功能。
于是，一旦你給項目啟用了Actions，GitHub就會根據你的項目，匹配一些合適的工作流推薦出來。
所有公開項目都可以免費使用。
而私有項目要用CI/CD，就有價格表了：
不過，現在是beta期間，一切都是免費的，快來注冊：
https://github.com/features/actions
至于企業(yè)版，團隊計劃明年推出。
CI/CD是到底是什么
看到這里，可能還有一些朋友沒有明白：
CI/CD到底是個啥？
CI：Continuous Integration，持續(xù)集成，指的是一個團隊的所有開發(fā)人員每天多次把自己手里的代碼合并到主干中去，用一致的自動化方法來構建、打包和測試程序，可以頻繁修改代碼，提升軟件質量，便于團隊協作。
CI可以實現自動化測試，更早拿到測試結果，防止有問題的代碼被交付出去，也更容易編譯，降低了測試成本和和時間。
CD則有兩個概念，一個是Continuous Delivery，持續(xù)交付，在CI中構建自動化的測試流程后，持續(xù)將代碼發(fā)布的存儲庫，不一定部署到生產環(huán)境中。
持續(xù)交付對于細微的變更十分有用，可以加速迭代過程。
另一個是Continuous Deployment，持續(xù)部署，通過自動化的構建、測試和部署循環(huán)來快速交付高質量的產品，直接部署到生產環(huán)境中，用戶可以感受到產品的變化，不需要做專門的發(fā)布更新，而是修改之后幾分鐘就上線了。
持續(xù)部署可以使發(fā)布頻率更高，每次提交自動觸發(fā)發(fā)布流，降低了小批量發(fā)布的風險，用戶體驗也能持續(xù)提升，不用每次都等更新。
議論紛紛
原本要靠第三方才能實現的功能，現在GitHub自己就干了，這當然引來了許多程序員的熱烈歡迎，沒多久，GitHub推特的評論區(qū)里歡呼聲此起彼伏：Awesome! Cool! Amazing!
之前那些CI工具，可能日子就不好過了。
一大批CI工具面臨涼涼
不過，既然GitHub自己出了CI/CD功能，那么以前那些第三方CI工具，大家還會用么？
不少人已經開始揮手拜別了：
也有人看到多系統(tǒng)支持這一點就非常high:
哇哦，支持MacOS？這一點就足夠我從CircleCI遷移過去了，40美元一個月的CircleCI，對于一些React Native應用CI/CD是足夠了，但CD只能一個星期一次。
TravisCI、CircleCI這些工具，可能要面臨用戶流失糟糕狀況了。比如Hacker News上的這位CircleCI用戶：
對我來說這很有趣，讓我想到壟斷的自然崛起和技術中的多元文化。GitHub最近仿佛要“吃掉整個世界”，比如之前的軟件包管理，給了Artifactory也Nexus不小的撼動?，F在搞這個，可能對CircleCI是個壞消息（我是CircleCI的用戶）。
作為一名開發(fā)者，短期來看我確實喜歡這個，不用再東拼西湊那么多東西，頭疼如何把它們整合在一起，如果GitHub不行了，CircleCI也不能用了，我們只要把氣全撒在GitHub頭上就好咯。
但是長遠來看，這樣競爭環(huán)境就出問題了，作為一個創(chuàng)業(yè)公司員工，要是有大平臺的大廠跑來跟你競爭這是很難搞的事，即使你產品更好，也敵不過大平臺的力量，畢竟他們集成了更多價值。
微軟的野心：把GitHub用戶導流到Azure？
也有人懷疑，此舉是微軟在給Azure鋪路，借GitHub的用戶量導流，目標還是瞄準了云計算市場。
作為一個.NET開發(fā)者，這就像吸引更多人去用Azure DevOps，進而讓他們成為Azure云的用戶，這是最后一步，終究是為了擴大云計算的市場。
我覺得對微軟來說一個好的策略是讓GitHub的CI/CD代碼和Azure DevOps盡可能重復，Azure DevOps不需要這么靈活，只要保持魯棒性就好了，GitHub可以當一個試驗場。
所有的路都導向Azure，GitHub的用戶基礎比Azure大得多，微軟想給自家IaaS獲取更多用戶。
估計在GitHub Actions里搞CI/CD的下一步就是讓GitHub能自己跑產品代碼，這樣買Azure云服務就省去了很多步驟。在一個地方運行代碼，停掉再用一個單獨的工具組件是很隨意的事，在一個地方有整個套件在這個市場是很明顯的事。
所以，你怎么看呢？
