Development

CI/CD 相關內容概念

概念解釋。

Continuous integration(CI，持續性整合)

  • 將開發人員對應用程序的更改被合併，系統將會通過自動生成應用並運行不同級別的自動化測試（通常是單元測試和整合測試）來驗證，確保這些更改沒有對程式功能造成破壞。測試內容涵蓋了從類和函數到構成整個應用的不同模塊。如果自動化測試發現新代碼和現有代碼之間存在衝突，可以更加輕鬆地快速修復這些錯誤。
  • 目的: 完成各程式碼的整合。應用程序的新更改會定期構建，測試並合併到共享存儲庫中，解決在一次開發中有太多應用分支，從而導致相互衝突的問題。

Continuous Delivery(CD，持續性交付)

  • 完成CI中生成及單元測試和整合測試的自動化流程後，持續交付可自動將已驗證的程式碼發佈到存儲庫。為了實現高效的持續交付流程，必須確保CI已內置於開發管道。
  • 目的: 是擁有一個可隨時部署到生產環境的程式庫。

Continuous Deployment(CD，持續性部署)

  • 最後的階段是持續部署，自動部署到指定環境。
  • 目的: 自動將預定的程式版本發佈到程式碼存儲庫的延伸，自動將程式發佈到生產環境。

CI/CD總結

  • CI/CD 就是程式開發完畢後，把開發完成的程式碼進行測試與Code Review，通過後經過合併於主線(Main branch)後直接發佈上線(Prod, UAT等環境)，這樣的過程就是所謂的 CI/CD。
  • CI/CD常用工具:
    • GitLab CI
    • Travis CI
    • Bamboo (Atlassian家出的 CI)
    • Circle CI
    • Jenkins
    • Ansible

*流程參考 Redhat *
Redhat_CI_CD

Unit Testing (單元測試)

  • 針對程式中的模組來進行正確性檢驗的測試工作，一個單元的定義可以是單個程式、函式、過程等內容，作為一個單元。(對於物件導向程式設計，最小單元就是方法，包括基礎類別（超類）、抽象類、或者衍生類別（子類）中的方法。)

System Integration Testing (SIT，整合測試)

  • 在單獨的軟體模組被合併作為一個組測試。在單元測試之後和在系統測試之前。整合測試在已經被單元測試檢驗後進行作為它的輸入，組織在更大的集合，和遞送，作為它的輸出，整合系統為系統測試做準備。
  • 目的: 整合測試的目的是校驗功能、效能和可靠性要求，配置在主設計專案中。

System Testing (系統測試)

  • 系統測試的涵蓋面很廣，主要包括功能測試、介面測試、可靠性測試、易用性測試、效能測試。 功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、資料處理&業務資料處理）方面測試。
  • 壓力測試與效能測試差異
    • 壓力測試要求進行超過規定效能指標的測試。例如一個網站請求是100qps，壓力測試就要是採用120qps個同時請求的條件測試。
      • 判斷準則： 系統能夠恢復、壓力過程中不要有明顯效能下降
    • 效能測試是就是該系統的效能標準(eg. 80tps)

Stress Testing (壓力測試)

  • 測驗系統在當下的軟硬體環境下能夠承受的請求有多少，用來計算出系統的極限。

User Acceptance Testing(UAT，使用者驗收測試)

  • 通常是由一般的使用者（通常這些使用者不瞭解軟體的具體邏輯，但對業務邏輯非常熟悉）進行的測試，因此是面向終端使用者的測試，結束後通常就可以佈署到正式環境了(Production)。

###　其他

  • TPS（每秒事務數）代表每秒執行的事務數量，由資料庫管理系統和用戶用於描述每秒鐘的資料庫操作數。例如，用戶每分鐘執行6個事務，TPS為6 / 60s = 0.10 TPS。
  • QPS：Queries Per Second意思是「每秒查詢率」，是一台伺服器每秒能夠相應的”查詢次數”，是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。
    More info: 相關參考1
    More info: 相關參考2

More info: Continuous integration(wiki)
More info: Continuous Delivery(wiki)
More info: CI/CD(RedHat)
More info: Software Testing(wiki)