所謂持續整合，聽起來似乎很時尚，但其本質無非就是三件事：從**庫git中拉取**、編譯、部署。如果你想嘗試jenkins，可以通過docker安裝，然後整合到你自己的git倉庫上。
今天我們不談jenkins，今天要談的是circleci。在這幾個工具當中，circleci的介面應該說是最漂亮的：
circleci與github整合比較容易，直接選擇自己的**庫拉取即可。而github pages由於使用了jekyll，所以有必要看一下jekyll如何與circleci整合，但jekyll官網上關於與circleci整合的文章還是基於舊版本的circleci 1.0的，而circleci 2.0已經與1.0有了很大差異。所以下面我們來講一下如何把jekyll與circleci 2.0整合在一起。
與1.0不同的是，你不需要在專案的根目錄下建立circle.yml了，而是要在專案根目錄下建立乙個名為.circle的資料夾，然後在裡面放乙個名為config.yml的檔案，檔案內容如下：
version: 2
jobs:
build-job:
docker:
- image: circleci/ruby:latest
steps:
- checkout
- run: bundle install
- run: bundle exec jekyll build
- run: bundle exec htmlproofer ./_site --allow-hash-href --check-html --disable-external
- run: echo "build finished!"
workflows:
version: 2
build-deploy:
jobs:
- build-job
rsync的部署部分，因為專案本身已經在github pages伺服器上了，不需要額外部署。如果你需要部署到其他伺服器的話，還需要在其他伺服器上開闢rsync服務，然後在circleci裡執行rsync命令，那是另外乙個話題了。
關於circleci與jekyll整合的真實案例，可以參考我的部落格模版。
持續整合（一）
一 提出 整合軟體 的過程不是新問題，如果專案開發的規模比較小，比如乙個人的專案，如果它對 外部系統 的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加 即使增加乙個人 就會對整合和確保 軟體元件 能夠在一起工作提出了更多的要求 要早整合，常整合 早整合，頻繁的整合幫助專案在早期發現專案...
持續整合簡介
想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任務，然後從版本控制更新 開啟工程按下build，準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有人...
持續整合 CI
引子 記得剛加入趨勢開始開發工作 的時候曾被告知，趨勢有一套auto build的系統，會每天夜裡自動把當天check in的 進行構建，生成qa可測試 的build。每個rd都得小心提交code，因為專案結束的時候會看auto build的失敗率。可是構建失敗總是在所難免，尤其是每次要提交cand...