ick:一個持續整合系統
ick 是一個持續整合(CI)系統。訪問 http://ick.liw.fi/ 獲取更多資訊。
更加詳細的內容如下:
首個公開版本發行
這個世界可能並不需要又一個持續整合系統(CI),但是我需要。我對我嘗試過或者看過的持續整合系統感到不滿意。更重要的是,有幾樣我感興趣的東西比我所聽說過的持續整合系統要強大得多。因此我開始編寫我自己的 CI 系統。
我的新個人業餘專案叫做 ick。它是一個 CI 系統,這意味著它可以執行自動化的步驟來構建、測試軟體。它的主頁是 http://ick.liw.fi/,下載頁面有指向原始碼、.deb 包和用來安裝的 Ansible 指令碼的連結。
我現已釋出了首個公開版本,綽號 ALPHA-1,版本號 0.23。(LCTT 譯註:截止至本譯文釋出,已經更新到 ALPHA-6)它現在是 alpha 品質,這意味著它並沒擁有期望的全部特性,如果任何一個它已有的特性工作的話,那真是運氣好。
誠邀貢獻
ick 目前是我的個人專案。我希望能讓它不僅限於此,同時我也誠邀更多貢獻。訪問治理頁面檢視章程,入門頁面檢視如何開始貢獻的的小建議,聯絡頁面檢視如何聯絡。
架構
ick 擁有一個由幾個透過 HTTPS 協議通訊使用 RESTful API 和 JSON 處理結構化資料的部分組成的架構。訪問架構頁面瞭解細節。
宣告
持續整合(CI)是用於軟體開發的強大工具。它不應枯燥、易潰或惱人。它構建起來應簡單快速,除非正在測試、構建的程式碼中有問題,不然它應在後臺安靜地工作。
一個持續整合系統應該簡單、易用、清楚、乾淨、可擴充套件、快速、綜合、透明、可靠,並推動你的生產力。構建它不應花大力氣、不應需要專門為 CI 而造的硬體、不應需要頻繁留意以使其保持工作、開發者永遠不必思考為什麼某樣東西不工作。
一個持續整合系統應該足夠靈活以適應你的構建、測試需求。只要 CPU 架構和作業系統版本沒問題,它應該支援各種操作者。
同時像所有軟體一樣,CI 應該徹徹底底的免費,你的 CI 應由你做主。
(目前的 ick 僅稍具雛形,但是它會嘗試著有朝一日變得完美 —— 在最理想的情況下。)
未來的夢想
長遠來看,我希望 ick 擁有像下面所描述的特性。落實全部特性可能需要一些時間。
- 各種事件都可以觸發構建。時間是一個明顯的事件,因為專案的原始碼倉庫改變了。更強大的是任何依賴的改變,不管依賴是來自於 ick 構建的另一個專案,或者是包(比如說來自 Debian):ick 應當跟蹤所有安裝進一個專案構建環境中的包,如果任何一個包的版本改變,都應再次觸發專案構建和測試。
- ick 應該支援構建於(或針對)任何合理的目標平臺,包括任何 Linux 發行版,任何自由的作業系統,以及任何一息尚存的不自由的作業系統。
- ick 應該自己管理構建環境,並且能夠執行與構建主機或網路隔離的構建。這部分工作:可以要求 ick 構建容器並在容器中執行構建。容器使用 systemd-nspawn 實現。 然而,這可以改進。(如果您認為 Docker 是唯一的出路,請為此提供支援。)
- ick 應當不需要安裝任何專門的代理,就能支援各種它能夠透過 ssh 或者串列埠或者其它這種中性的交流管道控制的操作者。ick 不應預設它可以有比如說一個完整的 Java Runtime,如此一來,操作者就可以是一個微控制器了。
- ick 應當能輕鬆掌控一大批專案。我覺得不管一個新的 Debian 源包何時上傳,ick 都應該要能夠跟得上在 Debian 中構建所有東西的進度。(明顯這可行與否取決於是否有足夠的資源確實用在構建上,但是 ick 自己不應有瓶頸。)
- 如果有需要的話 ick 應當有選擇性地補給操作者。如果所有特定種類的操作者處於忙碌中,且 ick 被設定成允許使用更多資源的話,它就應該這麼做。這看起來用虛擬機器、容器、雲提供商等做可能會簡單一些。
- ick 應當靈活提醒感興趣的團體,特別是關於其失敗的方面。它應允許感興趣的團體透過 IRC、Matrix、Mastodon、Twitter、email、SMS 甚至電話和語音合成來接受通知。例如“您好,感興趣的團體。現在是四點鐘您想被通知 hello 包什麼時候為 RISC-V 構建好。”
請提供反饋
如果你嘗試過 ick 或者甚至你僅僅是讀到這,請在上面分享你的想法。在聯絡頁面檢視如何傳送反饋。相比私下反饋我更偏愛公開反饋。但如果你偏愛私下反饋,那也行。
via: https://blog.liw.fi/posts/2018/01/22/ick_a_continuous_integration_system/
作者:Lars Wirzenius 譯者:tomjlw 校對:wxy
相關文章
- 使用持續整合系統解放生產力
- 持續整合、持續交付與持續部署
- 持續整合、持續部署、持續交付、持續釋出
- 持續整合持續部署持續交付_持續整合與持續部署之間的真正區別
- iOS持續整合(一)——fastlane 使用iOSAST
- 持續整合 2.0
- Jenkins持續整合Jenkins
- 持續整合(二)
- 你真的懂持續整合、持續交付、持續部署嗎?!
- 傳統企業如何打造統一的持續整合平臺
- 淺談持續整合(CI)、持續交付(CD)、持續部署(CD)
- 對持續整合、 持續交付、持續部署和持續釋出的介紹
- 3分鐘瞭解清楚持續整合、持續交付、持續部署
- CircleCI 與持續整合
- Jenkins持續整合配置Jenkins
- 前端 docker + gitlab CI 的持續整合(一)前端DockerGitlab
- 基於 abapGit 和 abaplint 的 ABAP 持續整合的一個例子Git
- 什麼是持續整合?
- 持續整合 Jenkins 簡介Jenkins
- 持續整合配置之Nuget
- jenkins+docker 持續整合JenkinsDocker
- AspNetCore&Coding持續整合NetCore
- 持續整合Jenkins+GitlabJenkinsGitlab
- Jenkins 持續整合使用教程Jenkins
- Taro 小程式持續整合
- Practice – iOS 專案持續整合實踐(一)iOS
- Practice - iOS 專案持續整合實踐(一)iOS
- 自己動手開發一個Android持續整合工具-關於TaskAndroid
- 淺談持續整合的理解以及實現持續整合,需要做什麼?
- 使用流水線外掛實現持續整合、持續部署
- 作業系統PPT(持續更新)作業系統
- GitLab CI持續整合-GitLab RunnerGitlab
- 小程式的持續整合方案
- CI 持續整合 - 阿里云云效阿里
- Jenkens+Docker+Git 持續整合DockerGit
- Flutter web 持續整合實踐FlutterWeb
- Linux下搭建Jenkins持續整合LinuxJenkins
- SAP開源的持續整合-持續交付的解決方案