前言
隨着系統越來越大，開發人員、站點、服務器越來越多，微服務化推進，......等等原因，實現自動化的devops越來越有必要。 當然，真實的原因是，在團隊組建之初就預見到了這些問題，所以從一開始就決定這一塊要自動化。 帶來的實質好處也是顯而易見的，人力成本的節省、規範化的流程、可追溯的發佈歷史、解脫雙手（重複性勞動）、避免人爲操作產生的錯誤等等。
感概一下
1.目前市面上的成套的產品要麼貴的要死，要麼不支持本地部署，要麼就還是一個demo級別的東西，最重要的還是每個公司或者產品都有自己的一些特殊環境或者業務再裏面。不一定都適合。反正是比較難找到好用的，而且是成套的產品來。期待一個devops界的SAP，而且還要便宜！ 2.幾個老大哥產品還是做得很牛逼！比如jira，confluence，jenkins，sonar。官方文檔非常完善，網上教程多。接口完備。不像某些產品，看上去高大上，一用起來就是各種坑 3.懂開發的運維覺逼是牛逼的程序員！（^_^） 4.人真的非常重要，不然流程什麼的，呵呵，都是個屁......
大概的樣子
當然，目前這套工具還有很多不完善的地方，隨着不停的使用，或者變化的需求來進一步變化。
gitlab
開源的git倉庫，主要有幾個用途 1.源代碼管理 分支管理規則可以參考gitflow，或者規定一個合適自己的就好，微服務化後，一個站點或者說一個項目參與的開發人員只有有限的幾個人。用了簡單的方法，master作爲發佈用分支，每次迭代開發使用新分支，上線前合併到master；線上簡單的fix則直接在master分支上提交。 2.配置文件管理 放在gitlab上，主要是爲了方便管理，以及追溯修改歷史。當然，我們有自己的配置中心，能走配置中心的都儘量走配置中心，只有必須是文件配置管理的才放在gitlab上。 3.發佈腳本管理 jenkins需要使用到的發佈腳本。根據環境、源代碼語言、部署方式等有所不同
jira
jira敏捷開發管理工具，管理需求、研發迭代等。在加上他們家公司的wiki做知識庫管理基本穩了。 jira用下來發現還是相當強大！各種自定義可配置。頁面、字段、流程等等全可配置。有http open api可以直接調用修改信息、觸發流程等
使用的發佈流程也比較簡單。開發創建發佈任務，然後提交給測試，測試在jira上操作發佈到測試環境，準線上環境，線上環境進行測試等。準線上環境測試完後要發佈到線上需要讓具有leader權限的人進行一次審覈，一方面是讓leader知道有什麼東西上線了，另一方面也是安全控制的一些原因（比如說節假日前夕最好是不在做更新等，要做更新就得報備，不然出問題節假日就得嗝屁）。
截圖是比較歷史的版本了，最近在jira裏面找了一個進度條插件，然後把構建發佈的實時進度直接反饋到jira的頁面上。這樣就不用再打開發布系統查看發佈進度了，進一步提高使用體驗。
發佈流程工作流，根據自身的情況設計的
發佈系統
這一塊，是我們自己開發的一個簡單系統。主要作用是銜接各個開源工具的使用。作爲一個粘合劑系統使之分散的各個子工具能鏈接爲一個整體。 雖然，jira裏面有jenkins插件，jenkins裏面有jira的插件，但是組件對各個系統都有版本要求，然後組件使用上也蠻不方便的，最後也有一些需求要解決起來相當麻煩，所以纔有了自己的發佈系統。 功能還是比較簡單，一個前端小夥弄弄頁面什麼的1個禮拜就完事了，關鍵還是把當下的各種新技術都秀了一波，雖然頁面挺醜的。幾個系統的接口調用自己研究寫一寫也就幾天就完事了。 主要完成的幾個功能 1.發佈配置管理 站點或者系統的開發語言，部署的目標系統，要部署那些主機，是不是docker容器方式，docker要部署幾個示例，部署方式併發、串行發佈，要走那一個nginx，綁定的域名，綁定的端口等等信息。 在新的系統或者站點發布的時候由運維和研發協調填寫，後期則由運維來維護，比如擴縮容等
2.接收jira的發佈任務操作通知，並通知到某一個Jenkins去執行，sonar進行靜態代碼檢查等 3.接收jenkins構建部署反饋過來的進度 4.展示構建部署進度
5.一部分CMDB系統的功能，主機管理（ip，名稱，用戶名，密碼）之類的。方便。 至於爲什麼不用世面上已有的CMDB系統，也實屬無賴，要麼要錢，要麼好麻煩、要麼沒接口。索行自己簡單做一個。能滿足功能即可。 因爲涉及到主機的賬號密碼之類的，所以密碼都是公鑰加密存儲在系統上。 而密碼的使用方有2個，一個是jenkins在部署的時候新機器在創建SSH免密登錄的時候要用一次，還有就是遠程管理工具要用，所以對密碼的使用單獨寫了個小組件用私鑰解密獲得密碼，然後把發佈系統和小組件單獨管理
jenkins
jenkins絕對可以說是這套工具裏面的大佬了，可以說一切都是圍着他在轉。 接收發布系統發過來的構建請求，拉取代碼，編譯，拉取配置文件，打包成部署包，上傳ftp，發佈到私有docker倉庫，部署等等。 還要區分系統環境，開發語言(windows、linux、nodejs、.net core)單獨處理等。 1.參數化構建過程。比如要構建的分支名稱之類的 2.源代碼配置。git源代碼地址，gitlab固定的代碼只讀賬號，通過SSH進行代碼的拉取。 3.調用構建腳本。jenkins內的執行命令大約如下面所示
#!/bin/bash -l
cd /opt/deployscript # 進入構建腳本目錄
git pull #拉取最新的構建腳本
#調用構建腳本
#workspace,build_number,jobname,project_name,git_commit,git_branch,env,jira_id,userid
sh /opt/deployscript/${JOB_NAME}/${env}/deploy.sh "${WORKSPACE}" "${BUILD_NUMBER}" "${JOB_NAME}" "${PROJECT_NAME}" "${GIT_COMMIT}" "${selected_branch}" "${env}" "${JIRA_ISSUE_ID}" "${BUILD_USER_ID}"jenkins的構建腳本
重中之重了，所有的驅動都在這個腳本里面了。分環境、分開發語言單獨編寫的構建或部署腳本。 爲什麼每一個站點都有一個腳本的原因則是總有那麼一些站點是那麼的特殊和優秀，當然覺得多數系統都可以走一個公共的構建腳本。 腳本有不少要調用其他系統接口的，我則直接用.net core 寫了一個控制檯應用，專門負責這個事情，畢竟寫shell不是專業的。 具體的構建腳本就不貼上來了。 腳本執行步驟（net core 測試環境腳本）：在每一個部署完成或者出錯的時候都把進度反饋到發佈系統上。 1.源代碼在jenkins配置裏面已經幫忙拉取好了。所以腳本不用拉代碼了。 2.編譯。比如dotnet publish -c Release -r linux-x64 -o “輸出路徑” 3.編譯輸出內容打包 4.上傳到ftp。 5.拉取配置文件。 6.將輸入內容和配置文件，等打成壓縮包 6.拉取部署配置。要部署到那些機器，部署要併發還是要串行等 7.檢查機器是否已經完成SSH免密配置了，沒有配置則拉取密碼配置好。 8.並行或者串行進行發佈操作 9.SSH到目標機器，上傳壓縮包，部署腳本 10.執行部署腳本（解壓，停掉原來的服務，啓動新的服務，檢查是否啓動成功等）
sonar靜態代碼檢查
在發佈系統中接收到jira的發佈請求後，拉取站點的配置，如果是需要進行sonar檢查則把請求發送給sonar的jenkins。 目前我們配置的是發佈到產線的時候才做sonar的靜態代碼檢查，然後再sonar系統裏面配置了。 後面看需要，是否要對sonar的結果進行郵件。打算這樣做。每週出一份代碼質量報告，統計一週內已上線的項目和上一週相比錯誤，漏洞，壞味道，覆蓋了等數據的變化。弄個定時任務，sonar 2個接口獲取一下數據，存儲對比結果，發個郵件就完事了。
簡單總結一下
文章隨便寫寫，很多東西交代的不清楚，還有很多東西壓根就沒有說。比如說堡壘機集成，日誌、host監控集成等等等。我不會說實在是我太懶了，打字好累啊！ 總之，歡迎交流！！雖然實現的不完整，但是還是適合目前自身的需求的。合適的纔是最好的嘛
感謝開源界大佬的貢獻，雖然我還沒錢捐款。讓社區有那麼多那麼多好用的產品。 感謝前人已經種好的大樹，很涼快！
整套工具搭建完成，如果真的算時間估計也就不到一個月，當然真實情況是零零散散的，東戳戳，西戳戳。好在做這個事情之前有一個簡單的規劃，沒有走彎路，雖然再找國產產品的路上耗費了一些時間
從開始使用開始，3個月不到就發了不下2000次，這還是在剛起步階段。可想而知，確實是生產力工具
我的博客即將同步至騰訊雲+社區，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan?invite_code=v8yg6z6vosmk