#PS：要轉載請註明出處，本人版權所有
#PS:這個只是 《 我自己 》理解，如果和你的
#原則相沖突，請諒解，勿噴
前言
軟件開發，水很深。
做了兩年有餘的攻城獅，做了代碼開發，技術框架搭建，環境搭建，項目管理，用戶溝通等工作，我從代碼開發者的角度來看，我們的寫的內容到用戶實際使用往往中間有許多的內容的，作爲開發者，千萬別人爲自己寫的代碼就是整個項目週期的全部，其實code部分只佔很少的時間，從code後到交付給用戶使用的中間部分纔是非常大的一個時間佔比。
軟件開發思考
在學校裏面，當我們學習軟件工程這門課時，教授的內容是比較傳統的軟件開發流程，它們大概是如下的流程：
- 獲取到大致項目需求
- 需求評估
- 需求文檔整理
- 概要設計（技術框架設計）
- 編碼
- 測試
- 交付
當交付給用戶後，實際情況是不可能一次性交付成功的，都會涉及到相關的需求細化和變更，於是又要重複5-7的步驟。
到了實際工作中後，會出現一種現象，項目交付的時間儘可能短，項目需求變更和交付時間也需要儘可能的短，於是就出現了傳統按部就班的開發模式不能夠完成相關的項目，於是出現了一些快速開發的方法，如敏捷開發。
在實際過程中，敏捷開發只是加速開發迭代部分，如果沒有控制好，就會出現開發速度加快了，但是測試，交付會出現問題，爲啥會出現呢？其實很簡單，就是都是獨立串行的，這會導致從整體看，項目開發時間拖長。
爲了解決類似的問題，又提出了類似Devops的說法，就是大家都坐一起，相互依賴的做事，因爲都是站在整體考慮的，所以可以對整個流程（開發、測試、交付）的情況進行協調，效率會比較好。
爲了把上述的問題處理好，我們必須要引入一些工具（VCS,CI,CD,CD）來幫助我們做事，否則是處理不好的這些事的，就會出現：要不效率低，能完成。要不效率高，就是容易出錯。
版本管理系統（Version Control System）
版本管理系統，這個不用介紹了，大家平常工作中都會用，常用的有svn和git，如果沒有接觸過，有興趣的可以多去網上找找資料學習學習，它們可以提供代碼管理、溯源等功能。
版本管理系統除了本身的屬性外，它自身帶的一些特性可以用來做一些其他的事情，比如它的push事件可以用來觸發一些其他的工作。
持續集成（Continuous Integration）
持續集成其實對於開發者來說，是很簡單的一件事情。就相當於你code完，然後手動編譯，測試這樣的一個流程。平常比如你用vs寫了一個程序，然後你右鍵編譯，然後f5運行測試，最後到相應的目錄去打包發佈程序。這種方式在軟件規模比較小的時候，完全可以採用，流程可控的，當軟件規模過大，而且需要持續維護修改時，這種方式會讓人炸裂的。
所以持續集成簡單的歸納爲通過一些工具來自動化編譯，單元測試，並生成相關的報告。至於什麼時候自動開始編譯，這裏就是上文說的VCS的相關事件來觸發就行。
持續交付（Continuous Delivery）
持續交付其實由相關QA質量保證團隊來手動或者自動的方式，檢測剛剛持續集成的程序版本，在模擬生產環境下，是否能夠正常工作。
這裏強調的還是內部測試，只是相關測試更貼近於實際生產環境。注意這裏沒有部署到生產環境。對於很多公司來說，其實QA軟件部門是等於沒有的。
持續部署（Continuous Deployment）
持續部署就是通過一些工具，自動化的把經過單元測試，QA測試後，打包，自動化部署到生產環境這麼一個過程。
關於ci，cd，cd，vcs的說明
其實就以上而言，你可以直接認爲就是，使用工具，自動化從vcs拉取代碼，自動化編譯測試程序，（半）自動化QA保證，自動化部署程序到生產環境這麼一個過程。這裏藉助了很多自動化工具，大大節約了程序多次迭代的時間。所以對於軟件開發來說，哪怕是敏捷開發，devops等模式都可以很好的建立起來。
但是不是說以上的就是最好的呢？因爲在軟件第一次發佈的時候，如果借用以上的自動化流程，需要一個人或者團隊來建立這個自動化邏輯，這是比較煩的一件事情，所以如果軟件迭代次數少，規模不大，不要硬搬硬套上述整個流程，實在是不合適。但是裏面的vcs，我還是希望每個項目都能夠用起來，真的很不錯。
Jenkins ， Travis ，Github Action 等ci，cd工具說明
這些工具是我用過的，世界上還有許多這樣的工具，看個人喜好了。這裏要對這些工具分一個類，按照他們的部署位置分一下，一種是需要自己搭建相關服務的，並完成cicd的事情，一種是自己提供相關配置文件（yml），由雲端給你解析這個配置文件並完成相關功能。
這裏Jenkins是屬於需要自己搭建服務的，需要自己定義相關的流程並完成cicd的事情。
Travis，GitHub Action這種是輸入雲端的功能，基本上算是屬於SaaS，你只需要提供遵循相關語法的配置文件，它們就會自動完成你定義的流程。
總結
合適的事情，選擇合適的工具。不是所有的情況都能夠把上面的整套給懟到團隊中去，但是整個軟件開發的流程和內容還是值得我們大家思考和借鑑的。
比如我們的團隊就引入了git和jenkins就夠了，能夠做簡單的版本管理和基本的軟件集成測試。其他的手動介入性價比比較好。
比如我自己封裝的一些開源小功能，我引入git，travis， github action就已經足夠了。
#PS：請尊重原創，不喜勿噴
#PS：要轉載請註明出處，本人版權所有.
有問題請留言，看到後我會第一時間回覆
