---
tags: linux
---
[TOC]

# LSA(二) CI/CD
- With the growing complexity of application development, organizations are increasingly adopting *methodologies* that enable reliable, scalable software
- **DevOps** and **Site Reliability Engineering (SRE)** are two approaches that enhance the product release cycle through enhanced collaboration, automation, and monitoring

## 網站可靠性工程 (SRE, Site Reliability Engineering)

### What is SRE?
- 由 Google 提出的一詞，是為了解決內部龐大的系統而制定的一連串的 **規範** 和 **實作**
- **SRE is what happens when you ask a software engineer to design an *operations* function.**
> 中譯: SRE 就是當你去問一個軟體工程師如何設計一套維運方法的表現
- A discipline that applies aspects of software engineering to IT operations, with the goal of **creating scalable and highly reliable software systems**.

### How does SRE work?

- SREs run services and are ultimately responsible for the health of these services.
- The SRE’s day-to-day activity involves building and operating large distributed computing systems

#### **Service Reliability Hierarchy**
- As the hierarchy below demonstrates, the foundational practices in making a service reliable
- Supporting existing services by **monitoring** and **addressing** any issues arising.
- Then building up to **scaling**.
- Finally, supporting development of new product features.

> ==***Source:** [Google’s SRE book](https://sre.google/sre-book/table-of-contents/)*==
> The idea is that topics at the bottom are more “**basic**,” and they gradually get more **advanced** as you progress up the pyramid.
- **Monitoring**
- Without monitoring, you have no way to *tell whether the service is even working*.
- > **延伸內容:** [Monitoring tools and system](https://sre.google/sre-book/practical-alerting/)
- **Incident Response**
- Once you’re aware that there is a problem, how do you make it go away?
- The details of the **solution** you choose to implement are necessarily specific to your service and your organization.
- >**延伸內容:**
>[Effective Troubleshooting](https://sre.google/sre-book/effective-troubleshooting/)
>[Emergency Response](https://sre.google/sre-book/emergency-response/)
>[Managing Incidents](https://sre.google/sre-book/managing-incidents/)
- **Postmortem and Root-Cause Analysis**
- ***Learning*** and ***analysis*** from failure
- Ensure that the *incident* is `documented`, that all contributing `root cause(s)` are well understood, and, especially, that ***effective preventive actions*** are put in place to ***reduce*** the likelihood and/or impact of ***recurrence***.
- > Aim to be alerted on and manually solve only **new** and **exciting** problems presented by our service
- > **延伸內容:**
> [Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/)
> [Outalator: Tools](https://sre.google/sre-book/tracking-outages/)
- **Testing**
- Once we understand what tends to go wrong, our next step is attempting to ***prevent*** it
- Make sure you have good unit tests in place to provide quick feedback and allow us to fix issues before they make it to production
- Assurance that our software isn’t making certain classes of errors before it’s released to production
- > **延伸內容:**
> [Testing for Reliability](https://sre.google/sre-book/testing-reliability/)
- **Capacity Planning** *(容量規劃)*
- A process that ***balances*** the **available resources** to *meet customer demand* or the *project capacity requirements*
- Resource management
- Time management
- Team management
- Work management
- **Load Balance** ensure we're properly using the capacity we’ve built.
- > **延伸內容:**
> [Auxon: Tools for automating capacity planning](https://sre.google/sre-book/software-engineering-in-sre/)
> [Load Balancing at the Frontend](https://sre.google/sre-book/load-balancing-frontend/)
> [Load Balancing in the Datacenter](https://sre.google/sre-book/load-balancing-datacenter/)
- **Development**
- Do significant large-scale `system design` and `software engineering` work within the organization.
- > Key aspects of **Google’s approach** to Site Reliability Engineering
- **Product**
- Finally, we find ourselves at the point of having a workable product.
- Measure from the customer’s perspective
- >**延伸內容:**
> [Reliable Product Launches at Scale](https://sre.google/sre-book/reliable-product-launches/)
> *How Google does reliable product launches at scale to try to give users the best possible experience starting from Day Zero*

### SRE principles
- 
>[圖片來源](https://www.bmc.com/blogs/sre-site-reliability-engineering/)

- **Embracing risk**
- 利用 ***錯誤預算 (Error Budget)*** 來評估可以容忍錯誤的範圍，為一個量化的值，來描述可能服務每 天/周/月 可以失效的時間
- Aim to hit ***100-percent reliability*** as this goal is **unrealistic**
- 因為要一直維持 100% 的服務會耗更多的成本
- 且 98、99% -> 100% 的差距 使用者多半也難以感受到
- > 像考試一樣，從 90分 -> 98、99分比較容易，但從 98、99分 -> 100分就會更加困難！
- **Using Service Level Objectives**
- To measure the availability and thus ensure that everything goes right, it provides three metrics: ***SLI、SLO、SLA***
- ***Service-Level Indicator (SLI)***
- 定義了和系統「回應時間」相關的指標
- 例如回應時間，每秒的吞吐量，請求量，等等
- > These metrics are usually *collected within a certain period of time* and then **converted** into *rates*, *averages*, or *percentiles*.

- ***Service-Level Objective (SLO)***
- 和相關人員討論後，得出的一個 *時間區間*，期望 SLIs 所能維持一定水準的數字
- >Like: the average request latency must be under 100 milliseconds

- ***Service-Level Agreement (SLA)***
- **服務級別協定 (Service level agreements, SLA)**
- 對 *客戶* 的承諾，確保服務持續運行的百分比等相關與客戶談好的標準
- A ***documented agreement*** between a *service provider (服務提供商)* and a *customer (客戶)* that identifies both the services required and the expected level of service
- 衡量往往都不是功能性的, 而是數字性的
- 失敗率、成功率、等待時間、離線時間、流量、效能、回應時間 ...等等
- 與服務相關的*收費規定*
- 服務提供期間的時間規定
- 用戶責任的規定
- 對變更請求流程的說明
- 對解決與服務相關的不同意見的流程說明
- **Eliminating toil**
- ***Toil***(手工) is manual, repetitive work
- 特徵:
- 手動執行 script、上傳新版程式
- 對每個 新客戶 進行的重複性工作
- **Automate**
- The SRE writes code to automate management of the lifecycle of systems infrastructure
- **Benefits:**
- Consistency
- Time saving
- Faster repairs and actions

## DevOps

### 為什麼會出現 DevOps?
- **瀑布式** → **敏捷開發** → **DevOps**
#### **瀑布式開發** *`(Waterfall)`*
- **採用階段式開發**
- 軟體開發過程會被事先分為固定的幾個階段
- 具有可預測性
- 只要能準確理解需求和技術，而且 *需求不再改變*，開發團隊就能為專案規劃精確、完整的開發計劃與流程
- **採用階段式評審**
- 每個階段結束後，對該階段提交的成果進行評審，評審通過後才能進入下一階段
- **修改成本很高！**
- 會打亂開發流程，大量工作需要從頭來過，延誤整體開發進度
- 

> [圖片來源](https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm)
#### **敏捷開發**
- **適合客戶需求不斷變化的開發計畫**
- **重客戶參與度**
- 可在專案開發時，即時提出回饋與要修正的地方
- 
> [圖片來源](https://trueagilitygroup.com/products/agile-master-samc%E2%84%A2-%E6%95%8F%E6%8D%B7%E5%A4%A7%E5%B8%AB%E8%AA%8D%E8%AD%89%E5%9F%B9%E8%A8%93%E8%AA%B2%E7%A8%8B)
#### **DevOps**
- **`敏捷開發` 速度快、變動多**，且需頻繁的 **測試、上線部屬**
- 增加 `開發團隊` 與 `維運團隊` 的壓力與彼此間的衝突

### What is DevOps?
- DevOps 即是 ***「開發」(Development)*** 與 ***「維運」(Operations)***
- 重視 **開發、測試、維運** 三者間的結合
- 
> [圖片來源](https://squadex.com/insights/how-to-implement-devops-with-cams/)

#### **主要目的**
- 解決 ***開發團隊*** 與 ***維運團隊*** 之間的衝突
- **衝突的根源**
- **缺乏協作:**
- **開發:** 要做的事情就是將程式打包好，然後扔給 維運部門 後，自己的工作週期就結束了，
- **維運:** 會負責將程式安裝與部署到所有生產環境的機器上，同時也要想盡各種辨法與善用各種工具，確保這些程式持續正常地執行，即使維運部門完全不瞭解這些程式的實作細節

- **目標不一致:**
- **開發團隊**:
- 把客戶的需求實現，滿足產品的功能需求
- Focused on continuously delivering new products or features to meet business needs
- **維運團隊**:
- 維持 質量、穩定性、可用性
- Strives to preserve the *availability* and the *stability* of IT services and the IT *cost efficiency*

- **相互抱怨、產生衝突**
- **開發的抱怨**:
- 即使寫了詳細的文件檔，每次部屬也都還要和 維運 討論許久
- 交付流程太長了且不透明，總是要去提醒 維運 的進度
- **維運的抱怨**:
- 文件太複雜了，每次部屬都會耗費很多時間
- 開發 總是在要發布時，才來告訴 維運 該做什麼
- 剛剛發布，程式就出Bug，又要定位問題

### DevOps 的核心價值

- **CAMS**
- 
> [圖片來源](https://squadex.com/insights/how-to-implement-devops-with-cams/)
- **~ Culture ~**
- DevOps 其實是一種 **文化層面** 的改變，並不是單指某一種工具或解決方案
- 讓 **「開發多去想維運面，維運多去想開發面」**，不要只關注在自己的領域與工作上
- 讓不同團隊或職能的人，都能有權力為專案做某些改變，並同時為這些修改所造成的後果負責
- **關鍵元素**
- 
> [圖片來源](https://squadex.com/insights/how-to-implement-devops-with-cams/)
- >每個組織的狀況、結構都不同，不能一味的複製他人的 DevOps 文化

- **~ Automation ~**
- Why need automate DevOps?
- **Faster**
- Ensure that software will be released and delivered much **faster**
- > Because of automation, ***manual interventions*** and ***communication delays*** are reduced to the bare minimum, or eliminated entirely
- **Reduced redundant and repetitive tasks**
- ex: push code、testing、delivery、deploy
- Be able to focus on more important and valueable things.
- **Processes & Tools**
- 
> [圖片來源](https://squadex.com/insights/how-to-implement-devops-with-cams/)
:::info
#### **DevOps 工具 元素週期表**
> [資料來源](https://devops.phodal.com/home)
:::
- **CI/CD**
- By using `CI/CD pipelines` to connect processes and practices, DevOps **automates updating and releasing code into production**
- 
> [圖片來源](https://squadex.com/insights/how-to-implement-devops-with-cams/)
- **Continuous Integration (持續整合)**
- 持續、漸進的 驗證開發結果 ，小部分小部分地儘早確認
- **程式碼建置、分析** 和 **開發環境的測試**
- **Continuous Delivery (持續交付)**
- 交付到 **測試環境**，確保軟體持續保持在隨時可以釋出的狀況
- **Continuous Deployment (持續部署)**
- 自動部屬到 **生產環境**
- :::info
**開發/測試/生產 環境**
- **開發環境:**
- 程式員們專門用於開發的伺服器，配置可以比較隨意， 而為了開發除錯方便，一般都會開啟全部錯誤報告。
- **測試環境:**
- 一般是複製一份生產環境的配置，如果程式在測試環境中無法正常運作，那麼肯定也不能把它部屬到生產機上
- **生產環境:**
- 指 正式提供對外服務的，一般會關掉錯誤報告，開啟錯誤日誌。
- 包含了所有的功能的環境，任何專案所使用的環境都會以這個為基礎，然後根據客戶的個性化需求來做調整或者修改。
:::

- **~ Measurement ~**
- 告訴團隊該如何做正確的改善與調整
- 
> [圖片來源](https://www2.slideshare.net/warfan/devops-68063058)

- **Collect & Analyze Metrics**

- **DevOps Metric** *`(列舉一些)`*
- **Deployment frequency**
- Tracking how often you do deployments
- Do more smaller deployments as often as possible because reducing the size of deployments makes it easier to test and release
- **Deployment time**
- Tracking how long it takes to do an actual deployment
- **Lead time**
- The amount of time that occurs between starting on a work item until it is deployed
- > If the goal is shipping code quickly, this is a really key DevOps metric
- **Automated tests pass %**
- Tracking how well your automated tests work
- **Defect escape rate**
- Tracking how many defects make it to production
- Use this key metric to know when you need to **slow down** or **improve testing**
- > -> Tracking ***all defects*** that are found in your software
> -> ***Tag*** each defect so that you can know *where the defect was found*
> -> Create the ***reporting***
- **Availability**
- 可使用率
- > Depending on your type of application and how you deploy it, you may have a little downtime as part of scheduled maintenance
- **Service level agreements (SLA)**
- Track whether you are compliance with your SLAs
- > If there are no formal SLA, there probably are application *requirements* or *expectations* to be achieved
- **Error rates**
- Tracking error rates within your *application*
- indicator of *quality* problems
- **Application usage & traffic**
- After a *deployment*, you want to see if the amount of transactions or users accessing your system looks normal
- Neither ***have no traffic*** nor ***giant spike in traffic***
- **Mean time to detection (MTTD)**
- It is important that you problems or bugs quickly
- **Mean time to recovery (MTTR)**
- Track how long it takes to *recover* from failures

- **~ Sharing ~**
- **分享** 內容給團隊
- ex: 經驗、工具、**Measurement 後的數據**
- 不要把數據只保留在某幾個部門中，而是可以 **分享** 出來，讓有需要的人可以去查看
- 增加團隊的透明度

### Benefits of DevOps
- Ensure **quicker** and **frequent delivery** of application features that improve *customer satisfaction*
- Develop **faster** by **automating** repetitive tasks
- Remediate problems quicker and more efficiently

### SRE & DevOps
#### **SRE vs DevOps**
| | **SRE** | **DevOps** |
| ----------- | ------------------------------------------ | -------------------------------------------------- |
| **Essence** | A set of ***practices*** and ***metrics*** | a ***mindset*** and ***culture*** of collaboration |
|**Focus**| System ***reliability*** and ***availability*** | ***Continuity*** and ***speed*** of product development and delivery
|**Team Structure** | *Site reliability engineers* | A wide range of roles: *developers*, *QA*, *SREs*, etc |

> **SRE is more practical, and DevOps is more philosophical**

#### **How SRE connects to DevOps**
- You can implement both **DevOps** and **SRE** into your organization.
- A helpful way to combine the methodologies is to consider **SRE as a way to achieve the goals of DevOps**
- > *class SRE implements interface DevOps*

#### Here are some of the common goals of DevOps, and how SRE practices can help achieve them:
##### ==**Reduce silos (減低穀倉效應)**==
:::info
**穀倉效應**
- 企業內部因「過度分工」而缺少溝通，各部門彼此鮮少往來，也不願與其他單位分享資訊
- 只專注在自身的營運利益，而非整個企業的利益，最終導致整個組織功能失調、企業走向衰敗
:::
- SRE achieves this by **creating documentation** that the entire organization can use and learn from.
- **Infrastructure as a code *(IaC)***
- 以寫 code 的概念去管理/建立/維護 infrastructure
- 讓環境用 統一規管的格式或設定檔 來部署
- 如果有錯誤，就能根據 發生錯誤的檔案 去進行修改，不用再把責任推卸給別人
- 利用 **版本控制工具** (如 git) 來管理，使任何的改變都有跡可尋

##### ==**Accept failures as normal**==
- **Error Budget** *(錯誤預算)*
- It can accelerate development while maintaining reliability
- > - As long as development keeps within the error budget, engineers can push new code.
> - But, if there is risk of the error budget being breached, it's time to work on reliability in order to mitigate customer impact

##### ==**Measure Everything**==
- SRE measure the availability and thus ensure that everything goes right, it provides three metrics: **SLIs、SLOs、SLAs**
- These will give you the insights you need to make smart decisions

##### ==**Tooling & Automation**==
- Reduce manual toil
- Whenever you automate or simplify a process, it reduce toil and increase consistency
- It also accelerate the process, achieving DevOps goals.

##### ==**Implement gradual changes**==
- **Change is best when it is small and frequent**
- Change is risky, true, but the correct response is to split up your changes into smaller subcomponents where possible
- **CI/CD**
- Build a steady **pipeline** of low-risk change out of regular output from product, design, and infrastructure changes
- Coupled with **automatic testing** of smaller changes and reliable rollback of bad changes
---

## CI/CD 流程與理論

[圖片來源](https://iter01.com/595038.html)
### 為什麼我們需要 CI / CD ?
- 維護軟體品質
- 減少各項時間成本
- 減少"人工"出錯的可能

### CI 與 CD 的差別
- CI 是整合軟體的過程(再透過測試去看整合有沒有問題、成功)
- CD 是將程式碼與基礎設施結合起來的過程(部屬到 UAT 或 production)

--------------------------------
#### 0. 瞭解人員成本設備
---
### CI (Continuous Integration) 持續整合
- 開發人員完成一個階段性的程式碼後就經由自動化工具測試、驗證，協助偵測程式碼問題，並建置出即將部署的版本並交付 CD

#### 1. commit程式碼提交
[圖片來源](https://iter01.com/595038.html)
+ 程式碼提交階段也稱為版本控制。提交是將開發人員編寫的最新更改傳送到儲存庫的操作。開發人員編寫的程式碼的每個版本都被無限期地儲存。在與合作者討論和審查變更之後，開發人員將編寫程式碼，並在軟體需求、功能增強、bug修復或變更請求完成後提交。
+ 人員：開發人員和工程師、資料庫管理員（DBA）、基礎架構團隊
+ 工具：Git lab/hub , Bit bucket
#### 1-1. 靜態程式碼分析

+ 在程式ｂｕｉｌｄ之前先進行靜態ＳＡＳＴ測試，避免在後面構建或部署過程中失敗了浪費更多資源
+ 人員：開發人員和工程師、資料庫管理員（DBA）、基礎設施團隊、測試人員
+ 工具：Git lab/hub , Bit bucket

:::info

## **SAST（Static Application Security Test）**
- 是一種白盒測試方法，使用SonarQube、Veracode、Appscan等SAST工具從內部檢查程式碼，以發現軟體缺陷、漏洞和弱點（如SQL隱碼攻擊等）
- 優點:
- 廣泛的程式語言支持
- 檢測出錯誤的比率較高
- 可以直接標出錯誤程式碼的位子

- 缺點:
- 準確性差：優秀SAST產品的誤報率也在53%以上
- 通常運行很慢
- 需要一些定製或調整參數
- 無法看到執行結果
## **DAST（Dynamic Application Security Testing)**
- 對應用程式進行黑盒分析，再不看程式碼的前提檢查系統對潛在漏洞測試的請求和回應。
- 優點:
- 獨立於應用程式的技術和平台，無需程式碼細節
- 執行相對較快
- 誤報率較低

- 缺點:
- 檢出率低：優秀的DAST產品檢出率也只有18%
- 使用門檻高，報告通常需要安全專家解讀
- 無法定位到確切錯誤的位置
## **IAST (Interactive Application Security Testing)**
- (交互式應用程式安全測試）結合了SAST和DAST的優點。IAST可以像SAST一樣看到原始碼，也可以像DAST一樣看到應用程式運行時的執行流。

- 優點:
- 檢出率較高
- 誤報率較低
- 可以在研發測試和生產環境中使用
- 實時產生結果
- 可以持續檢測，對DevOps支持度更高
- 即插即用，無需配置或調整參數
- 缺點:
- 需要特定語言支持
> 待確認

[圖片來源](https://hdivsecurity.com/bornsecure/sast-dast-vs-iast-all-you-need-to-know-about-ast-tools/)
:::
:::success
## **白箱與黑箱測試**
- ### 白箱測試(White-box testing, glass box testing, structural testing )
> 該做什麼，該以什麼順序做
- 從軟體本身的結構，來判定其內部的資料應該要何去何從，檢驗的內容，主要分成兩個層面: 資料流程面(Data flow coverage) 與 控制流程面(Control flow coverage)
- 資料流程面: C=A+B A與B加完得值是否有放到C
- 控制流程面: C=A+B A+B是否比放入C先執行
- ### 黑箱測試(Black-box testing, functional testing)
> 只管結果是否正確 ，不論過程
- 又名功能測試(functional testing)，經由實際運行軟體來測試，測試的人不需要去了解軟體的內部結構以及資料流程，只需要去檢測軟體的輸入、輸出以及實際的運行狀況
- C=A+B A及B都要是數字，但使用者輸入"四"或"5"(str)，此時應該輸出 "無效的輸入"
:::

#### 2. Build構建階段
[圖片來源](https://iter01.com/595038.html)
+　將程式碼編譯成執行檔，並過檢查新增的新模組是否與現有模組配合良好，有助於更快地發現bug
> 簡而言之，構建階段是編譯應用程式的階段。構建過程的其他子活動包括工件儲存、構建驗證和單元測試
+ 人員：開發人員和工程師 技術
+ 工具：Jenkins
#### 2-1. 測試階段
[圖片來源](https://iter01.com/595038.html)
+ 根據使用者故事建立了測試用例和場景。他們進行迴歸分析，壓力測試，以檢查與預期產出的偏差。測試中涉及的活動有健全性測試、整合測試和壓力測試。
+ 人員：測試人員和QA工程師

#### 整合測試：
+ 整合測試是使用Cucumber、Selenium等工具來執行的，其中各個應用程式模組作為一個組進行組合和測試，同時評估是否符合指定的功能需求。在整合測試之後，需要有人批准將該組中的更新集移動到下一階段，這通常是效能測試。這個驗證過程可能很麻煩，但它是整個過程的重要組成部分。核查過程中出現了一些新的解決辦法。

#### 負載和壓力測試：

+ 負載平衡和壓力測試也使用自動化測試工具（如Selenium、JMeter等）來執行，以檢查應用程式在高流量環境下是否穩定和效能良好。此測試通常不會在每個更新上執行，因為完整的壓力測試是長期執行的。在釋出主要的新功能時，將對多個更新進行分組，並完成完整的效能測試。在單個更新被轉移到下一個階段的情況下，管道可能包括金絲雀測試作為替代方案。
#### 3. merge & code review
CI 步驟複習
Push -> unit test -> code review -> merge test -> release
---------------------

### CD (Continuous Deployment) 持續部署
- CI的下一階段，經過CI測試後所構建的程式碼可以透過CD工具部署至伺服器，減少人工部署的時間。

#### 4. Bake建立環境
[圖片來源](https://iter01.com/595038.html)
+　Bake是指從原始碼中建立一個不可變的映像例項，該例項在生產環境中具有當前配置。這些配置可能是資料庫更改和其他基礎設施更新之類的內容。Spinnaker可以觸發Jenkins來執行這個任務。
+ 人員：基礎設施工程師、現場可靠性工程師（SRE）、運維工程師
#### 5. 部屬
+ 將自動將Bake的映像傳遞到部署階段。這是將伺服器組設定為部署到叢集的位置。與上述測試過程類似，在部署階段執行功能相同的過程。部署首先轉移到測試、階段，最後轉移到生產環境，然後進行批准和檢查。整個過程由Spinnaker之類的工具處理。
### AFTER CI/CD
#### 6. 驗證(反饋)
+ 部署到生產環境是使用部署策略（如藍綠部署、金絲雀分析、滾動更新等）執行的。在部署階段，將監視正在執行的應用程式，以驗證當前部署是否正確或是否需要回滾。
#### 7. 監控
[圖片來源](https://iter01.com/595038.html)
+ 通過slack或電子郵件頻繁地向開發人員和專案經理反饋新版本的質量和效能。通常，反饋系統是整個軟體交付過程的一部分；因此交付過程中的任何更改都會頻繁地記錄到系統中，以便交付團隊可以對其採取行動。
---------

## Security

### 危害(風險)
[圖片來源](https://secview.io/posts/9-ci-cd/)
- 不足的流程控管機制
- 在整個軟體交付過程，人員或服務帳戶未基於最小權限原則配置，因此攻擊者可藉由被提權的帳戶執行較高層級的行為（甚至是影響生產環境的操作）
- > ＥＸ：濫用ＣＩ中的合併分支的，從而ｐｕｓｈ未經審核的ｃｏｄｅ
- 不適當的身分識別與存取管理
- 攻擊者藉由應用服務或工作站在拉取依賴項時執行惡意程式碼，並從中竊取環境中的資料或滲入生產環境。
- 不安全的系統配置
- 由於 CI/CD 各系統（SCM、Artifact 存儲庫等）涉及各種安全配置（基礎設施、網路等），攻擊者可透過潛在的 CI/CD 漏洞和錯誤的配置來存取生產環境。

- 不足的流水線存取管理
- 由於 CI/CD 環境是由多個需要互相溝通和身份驗證的系統組成，攻擊者可利用不安全的敏感資料管理和過於寬鬆的憑證存取周圍的系統。
- Artifact 無適當的完整性驗證
- 攻擊者經由 CI/CD 過程中的步驟（入口點）篡改資源並使其流向生產環境。
- 依賴鏈濫用
- 攻擊者將惡意程式碼或指令注入流水線的配置，以操控整個建構流程（例如：在 CI/CD job 的 script 中，使用 echo 印出置於環境變數裡的敏感資訊）。
- 被“毒害”的流水線(Poisoned Pipeline Execution )
- 攻擊者利用流水線存取管理的不足，存取環境中的敏感資訊或其餘的內/外部系統。

- 不受監管的使用第三方服務
- 由於組織缺乏對第三方服務的治理和可視性，導致擴大了組織的攻擊面。
- 不足的日誌記錄和可視性
- 攻擊者在 CI/CD 環境中執行惡意活動時不易被察覺，且缺乏事後調查的資訊
### 防護

[圖片來源](https://secview.io/posts/9-ci-cd/)

- 資安系統架構設計（Security Architechture Design）
- 開發前的功能設計和系統設計，最常見需要被考慮的像是「存取控制（Access Control）」和「機密資訊管理（Secret Management）」等等

- 運行時自我保護（RASP，Runtime Application Self Protection）
- 產品上線後，有基本「自我保護」的功能
- 像是網站如果提供搜尋的功能 query=123，但攻擊者可能會嘗試改成 query=123' and '1'='1，這時候網站可以主動判斷疑似遭受攻擊並且即時防禦
- 靜態應用程式安全測試（靜態測試，SAST，Static Application Security Testing）
- 在開發者開發完功能後、把程式碼推上遠端時，通常會自動觸發 Jenkins 進行基本程式碼掃描（像 Linter），這部分很適合再加上基本的 SAST 靜態測試工具。
- Python 弱點的 Bandit、掃 Go 弱點的 Gosec 等等
- 資安程式碼審查（Security Code Review）

- 軟體組成分析（SCA，Software Composition Analysis）
- 針對的是第三方套件的「已知弱點」掃描。為了自動化檢查這些第三方套件，我們在建構好映像檔後，就可以先做基本的掃描
- EX:針對容器弱點的 Clair、針對作業系統套件的 Vuls、針對 JS 函式庫的 Retire.js、和適用 Go、Python、Ruby 等語言函式庫的 Snyk
- 動態應用程式安全測試（動態測試，DAST，Dynamic Application Security Testing）
- 針對不同可能發生的資安風險一一測試（測試數量依成本及需求）
- 交互式應用程式安全測試（IAST，Interactive Application Security Testing）
- 監視在執行時間傳送的流量，並報告所發現的漏洞

## CI/CD 常用工具
* SCM
* GitLab (版控工具)
* GitHub (版控工具)
* Pipeline
* GitHub action
* GitLab CI
* Jenkins (自動化建置工具)
* Drone (自動化建置工具)
* Circle (自動化建置工具)
* Release
* Docker (迅速佈署環境工具)
* K8S (管理 Docker Container 工具)
* Helm (快速建置各環境 K8S 工具)
* Monitoring
* Grafana (機器數據監控工具)
* ELK (Log 蒐集工具)
* Feedback
* Telegram (通訊、錯誤通知工具)
* Slack (通訊、錯誤通知工具)

### VScode 工具

* 階段一
* Code Spell Checker
* catch common spelling errors while keeping the number of false positives low
* GitHub Copilot
* AI pair programmer which suggests line completions and entire function bodies as you type
* ESLint
* Code style

* 階段二
* Import Cost
* Display import/require package size in the editor*
* 階段三
* Dependency Analytics
* Flags security vulnerability, Suggests a project level license, check for conflicts between dependency licences ...
* support python golang

* Flow Language Support
* static type checker, designed to find type errors in JavaScript programs

## GitLab

### **認識 GitLab**
- The **DevOps software platform** that combines the ability to develop, secure, and operate software in a single application
- Fully **free and open-source software** distributed under the `MIT License`.

#### **Features**
- **Git-based repository**
- Helps development team collaborate and maximize productivity, faster delivery and increased visibility.
- **Authentication Levels**
- It can add and modify people’s permissions according to their roles
- **Built-in CI/CD**
- `GitLab CI/CD Pipeline`
- **Covers all stages of the DevOps lifecycle**
- `GitLab Workflow`
- **Offer other tools for effective development and project management**
- To-DO List, Milestones, Wiki, Issue Tracker, etc

:::info
### **Git**
- A **distributed version control system**
- Tracking changes in any set of files
- **Git repository**
- Contains all of the project files and the entire revision history
- > You take an ordinary folder of files, and tell Git to make it a repository.
> This creates a **.git** subfolder, which contains all of the Git metadata for tracking changes

:::warning
#### **Centralized vs Distributed Version Control**
#### **Centralized Version Control System**
- There will be just **one repository** on the server and that will contain all the history or version of the code and different branches of the code
- **Workflow**
- 1. Getting the latest version of the code from a central repository
- 2. Making your own changes in the code
- 3. Committing or merging those changes into the central repository
- **Pros and Cons**
- Easy to learn and easy to set up
- No requirement for additional space
- Without saving the entire code and history on your local machine
- A single point of failure risks data
- Slow speed delays development
- Users must communicate with the remote server for every command

#### **Distributed Version Control System**
- **Every single** developer or client has their own server and they will have a copy of the entire history or version of the code and all of its branches in their local server or machine.
- Every client or user can work **locally** and **disconnected** which is more convenient
- **Workflow**
- 1. Clone the code from the **master repository** in your own hard drive
- 2. Get the code from your **own repository** to make changes
- 3. Commit your changes to your **local repository**
- 4. Push your *local repository* code to the *master repository*
- **Pros and Cons**
- Reliable backup copies
- Flexibility to work offline

> [圖片來源](https://www.geeksforgeeks.org/centralized-vs-distributed-version-control-which-one-should-we-choose/)
:::

:::info
### MIT License - 軟體授權條款
#### **什麼是軟體授權條款？**
- 軟體授權條款是 法律文件，用來**管理軟體的使用與重新分配**
- 是「開源」概念的衍生物
- 一個「開源」專案理所當然須選擇一個相對應的授權條款
- 不要在沒有授權條款的情況下稱自己的軟體為開源軟體
- > 到底有沒有要讓別人使用、修改、或在其基礎上衍伸作品
#### **MIT License**
- 屬於寬鬆類型的軟體授權條款
- **條款內容可根據需求修改**
- 只需要在衍生作品附上 MIT條款內容 和 相關著作權聲明 即可
#### 其他授權條款
- **GNU GPL**
- 世界上第一個開源專案授權條款
- 最大的特點就是**感染性**
- 擁有 自由/開源軟體 的幾項權利(開發者可以根據自己的目的使用、修改、散布、發布衍生作品)
- 規定你使用的程式碼內有GNU GPL這個License時，你發布或散布的作品也要使用這個License，不可更換成其他授權條款
- > 也就是說，若你使用GPL類的License，後續所有衍生的作品都必須使用此License並開放可編譯的源碼給眾人
- > 因為商業層面的考量會避免使用此類的授權條款
- **LGPL**
- 與 GNU GPL 最大的差異是在 **「引用」** 的部份
- 如果只是引用LGPL的源碼沒有做其他修改的話，是不需要公開衍生作品的源碼的
- **BSD**
- 最大的特色就是 **標示**
- 開發者使用這類授權條款的軟體，後續可以選擇改用其他授權條款開放自己的作品
- 但必須要把原本程式碼的 BSD 條款的著作權標示內容（Copyright）留著
- **Apache License**
- 除了必須包含著作權聲明（Copyright）、Apache 條款（License）以外，還要**特別標示出修改過**的地方
- 
> [圖片來源](https://noob.tw/open-source-licenses/)

:::
:::info
#### GitLab 基本功能介紹
##### 後台管理者
- Admin Area 的功能介紹 *(只有使用 `root` 身分登入才會出現)*
- 
- **Overview**
- 

- **`Dashboard`**
- 
- **`Projects`**
- 
- 
- 可以設定 **Project visibility**
- 
- **Visibility Level**
- Project 與 Group 都可以設定 Member 及 Visibility Level
- `Public`: 即所有人，包含沒有登入 GitLab 的任何人都能看見此 Project 或 Group。
- `Internal`: 即所有的 User，都能看見此 Project 或 Group。
- `Private`: 只有該 Project 或 Group 的 Member 才能看見它。
- 也能再進一步根據各個功能進行權限管控
- 
- 
- Project Activity
- 
- Project Members
- 
-
- 
- [各個角色權限的詳細表](https://docs.gitlab.com/ee/user/permissions.html)

- **`Users`**
- 
- 使用者資訊
- 
- 

- User Access
- 
- **`Groups`**
- 
- 
- **Monitoring**
- 

- **`System Info`**
- 
- **`Background Jobs`**
- 

- `Health Check`
- 提供了一組 Access Token 搭配三個 URL 讓我們能夠用來監控服務的健康狀態
- 用瀏覽器開啟這三個 URL，即可得到一串 Json 格式的 Response
- 
- 
:::
:::success
### GitLab Workflow
- 可以將軟體的開發流程（Workflow）大致劃分為 10 個步驟
- 從創意發想（Idea）開始直至產品上線並收集回饋意見（Feedback）為止
- GitLab Workflow 即是以 GitLab 為核心工具，借助 GitLab 的產品生態系，讓開發團隊能夠有效地串連這 10 個步驟，迅速搭建團隊的 Workflow
- 
> [圖片來源](https://www.slideshare.net/warfan/gitlab-gitlab-workflow)
1. **Idea**
- 除了面對面的實體會議，線上的聊天討論空間中的某個想法，也許亦有機會成為產品創意發想的養分
- `Mattermost`
- 是一套開放原始碼、可自行架設的線上聊天服務
- 有分享檔案、搜尋與整合其他服務等功能
- [GitLab Mattermost](https://docs.gitlab.com/ee/integration/mattermost/)
2. **Issue**
- 將 Idea 轉成實際的 Story 或 Issue
- 有提供了完整的 Issue Tracking 功能
3. **Plan**
- 決定工作的優先順序，並分派工作
- To Do List, Issue Board
- 
- Workflow Tracking
- 
> [圖片來源](https://ithelp.ithome.com.tw/articles/10217957)
- Assignee Lists
- 
> [圖片來源](https://ithelp.ithome.com.tw/articles/10217957)
4. **Code**
- 動手撰寫程式！！
5. **Commit**
- 將程式碼送入版本控制系統中
- 遵守團隊的**分支策略**
6. **Test**
- 借助持續整合、自動化建置和測試，確保品質
7. **Review**
- 進行 Code Review & Merge Request
8. **Staging**
- 將程式自動部屬至 Staging 或 Production-like 的環境，確認程式在此環境下是否能夠正確運行
9. **Production**
- 通過驗證後，最後即可部署至 Production 環境供使用者使用
10. **Feedback**
- 透過 **Cycle Analytics**，為我們自動收集的這些針對專案進度、工時的控管狀況的數據分析
- 幫助團隊發覺目前開發流程中的瓶頸點 與 要改進的地方
- **Cycle Analytics & Charts**
- 
- 
:::

### GitLab Flow

#### Branching Strategies ( 分支策略 )
- **Speed** and **agility** are crucial when it comes to developing and releasing software
- However, when you have a large team of developers working simultaneously, **branching** and **merging code** can become messy fast.
- Teams need to have a *process* or *rules* in place to implement multiple changes at once
- **Aim to:**
- Enable parallel development
- Avoid conflicts when merging
- Easier integration of changes into the master trunk

#### Git branching strategies
- Git branching model is **lightweight** compared to other version control systems ( VCS )
- It’s so **easy and cheap to create branches in Git**
- This means that these `branches` aren’t just copies of the file system but simply a **pointer** to the latest commit
- 
> [圖片來源](https://www.flagship.io/git-branching-strategies/)
- :::info
#### **Git Internals - Git Objects**
#### **Git Objects**
- Git is a **content-addressable filesystem**.
- The core of Git is a simple **key-value data store**
- >You can insert any kind of **content** into a Git repository, for which Git will hand you back a **unique key** you can use later to retrieve that content.
- **Object IDs are hashes**
- hashing the *file contents* with `SHA-1`
- 

#### **Blobs are file contents**
- OID
- `blob [file size]\0[file content]`
> **\0** : 結尾 null bytes
- **blobs** contain file contents
> **blob** *( binary large object，二進位大型物件 )*
> 將二進位資料儲存為一個單一個體的集合
- 
- 

#### **Trees are directory listings**
- OID
- **Get the object entry of the file**
- `[mode] [file name]\0[object ID]`
- > a regular, non-executable file mode is: **100644**
- **Tree object hash**
- `tree [size of object entries]\0[object entries]`
- Representation of **directories**
- Note that `blobs` contain *file contents*, but not the *file names*!
- 
- 
#### **Commits are snapshots**
- OID
- `commit [the size of data]\0[data]`
- > data:
>
>[圖片來源](https://stackoverflow.com/questions/35430584/how-is-the-git-hash-calculated)

- Each commit contains a **pointer** to its **root tree**, representing the state of the working directory at that time.
- 
- 
- 

- 

#### **Branches are pointers**
- branches provide **pointers to the commits** we care about
- **Big Picture**
- 
>[圖片來源](https://ithelp.ithome.com.tw/articles/10190453)

:::

- 
> [圖片來源](https://www.slideshare.net/warfan/gitlab-gitlab-workflow)
>
#### **Git Flow**
- **Main Branches**
- **Master branch**
- a branch that stores the baseline of the *latest released version*
- **Develop branch**
- a branch that collects the developed features
- **Temporary Branches**
- **Feature branch**
- a branch for developers to *develop features*
- **Release branch**
- a branch that is responsible for *version release*
- **Hotfix branch**
- a branch that *corrects online defects*

- 
> [圖片來源](https://www.flagship.io/git-branching-strategies/)

##### **Pros**
- Complete rules with definite responsibilities of branches
- Easy to scale our development
- It simplifies parallel processing by isolating features

##### **Cons**
- Developers must use the `develop` branch and not `main`
- Most tools automatically use the `main` branch as the default
- it is annoying to have to switch to another branch
- It is a convention to call your default branch `main` and to mostly branch from and merge to this
- **Slow down the development process and release cycle**
- The complexity introduced by the `hotfix` and `release` branches

> Git Flow **適合「版本發佈」，但不適合「持續發佈」**
> **版本發佈**:目標是一段時間以後產出一個新版本
> **持續發佈:** 程式碼一有變動，就部署一次
#### **GitHub Flow**
- A simpler alternative to GitFlow ideal for **smaller** teams as they *don’t need to manage multiple versions*
- 
> [圖片來源](https://www.flagship.io/git-branching-strategies/)
- **All code on the master branch is the latest working version that can be deployed**

##### **Pros**
- Clear and simple
- Encourages **fast feedback loops**, making it possible for teams to quickly identify issues and make changes
- - You have no development branch where finished features sit and wait for release.

##### **Cons**
- Not suit for **big team**
- Like make larger releases or test multiple features together before deployment
- Not properly tested before merging with the master-release preparation and bug fixes happen in this branch

> GitHub Flow **適合「持續發佈」**

#### **GitLab Flow**
- 以 **「上游優先」（upsteam first）**
- 只認存在一個主要分支 Master 分支，他是其他所有分支的「上游」
- 只有這隻上游分支採納的程式碼變化，才能應用到其他分支
- 分兩種開發情況:
- **持續發佈**
- 除了 `master` 分支外，根據不同環境建立對應的分支。並需服從上游到下游一層一層的過關規則
- **開發環境** -> master
- **預發環境** -> pre-production
- **生產環境** -> production

- 
- > [圖片來源](https://iter01.com/607587.html)
- **版本發佈**
- 每當有一個穩定的版本，就要從 `master` 分支拉出一個分支
- 比如2-3-stable、2-4-stable等等。
- 只有修補 Bug 時，才允許將代碼合併到這些分支，並且需要更新小版本號
- 
- > [圖片來源](https://iter01.com/607587.html)

#### 小結
- `Git flow` 適用於**大團隊多版本**並存迭代的開發流程
- `Github flow` 適用於**中小型團隊** 持續發佈 的開發流程
- `Gitlab flow` 適用範圍則介於上面二者之間，支援 持續發佈 與 版本發佈 兩種情況

### GitLab CI/CD 實作
#### GitLab CI
- 在每次上傳版本到 Gitlab 後，都自動執行單元測試
- 
> [圖片來源](https://nick-chen.medium.com/gitlab-ci-%E5%85%A5%E9%96%80%E7%AD%86%E8%A8%98-%E5%96%AE%E5%85%83%E6%B8%AC%E8%A9%A6%E7%AF%87-156455e2ad9f)
- 在專案資料夾中偵測到 `.gitlab-ci.yml` 這個設定檔的時候觸發，主要是負責協調在各種不同情境時 Runner 該啟動是否該啟用及先後順序

#### 實作
#### Step 1. 事前安裝所需套件與軟體 以及 註冊相關帳號

sudo apt update
sudo apt install curl php7.4-cli php-curl php-xml php-mbstring rubygems

sudo curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer
composer //確認composer是否安裝成功

//Add the official GitLab repository
sudo curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

//Install the latest version of GitLab Runner
sudo apt-get install gitlab-runner

> Composer - PHP 管理模組套件
> composer 安裝成功圖
> 

- 註冊帳號
- [gitlab.com](https://gitlab.com/)
- [Heroku](https://dashboard.heroku.com/)

#### Step 2. 建立一個 Laravel 專案並確定能成功啟用

// 安裝 laravel 專案
composer create-project --prefer-dist laravel/laravel <project name>

// 移至專案資料夾
cd <project name>

// 安裝資料到 vendor/ 下
composer install

// 啟動伺服器
php artisan serve

- 
- 開啟網頁
- 

#### Step 3. 建置內函的單元測試
- 因專案預設就會有一個單元測試存放在 `tests/Unit/ExampleTest`

./vendor/bin/phpunit


> Laravel 自己就附帶兩個測試了，一個是 `Feature/ExampleTest.php`，另一個則是`Unit/ExampleTest.php`

#### Step 4. 將專案上傳至 GitLab
- [gitlab.com](https://gitlab.com/)
- 註冊、先創建一個 GitLab project
- 複製 專案 repo 連結
- 
- ```txt=
git init
git remote add origin <你的git repo link> //connect our local repository to the GitLab repository
git add . //add our changed file to our project
git commit -m "first commit"
git push origin master

    > git push [remote-name] [branch-name]
- 可以將　`master` 再 merge 到 `main` 中

#### Step 5. 架設 GitLab Runner
- ![](https://i.imgur.com/209Kbay.png)
- ```txt=
    //Register
    sudo gitlab-runner register

- 填入 URL 和 Token
- 到 GitLab 中，`Project -> Settings -> CI/CD -> Runner`
- 
- 最後選擇使用 `shell` 的方式作為 executor

#### Step 6. 呼叫 Runner 執行 CI/CD 的 JOB
- 刪除被隱藏不上傳的檔案或資料夾
- ```txt=
sudo vim .gitignore

    - 將 `.vendor` 和 `.env` 刪除
- 建立 `.gitlab-ci.yml` 設定檔
    - :::info
        #### `.gitlab-ci.yml` 設定檔 基本介紹
        - ![](https://i.imgur.com/rIPFzSb.png)
        - 建立每個 stage 的 job
            - ![](https://i.imgur.com/KiFXVWT.png)
        :::
    - ```txt=
        image: lorisleiva/laravel-docker:latest

        stages:
          - test
          - deploy

        unit_test:
          stage: test
          script:
            - ls -al
            - git branch
            - ./vendor/bin/phpunit --testsuit Unit

- 上傳到 GitLab 上 *(如果是直接線上編輯的話就不用再上傳)*
- ```txt=
git add .
git commit -m "upload gitlab-ci.yml"
git push origin master

- 查看 pipeline 結果
    - ![](https://i.imgur.com/2YQcIGZ.png)

#### GitLab CD



#### Step 7. 使用 Heroku 部屬我們的環境
- [Heroku](https://dashboard.heroku.com/)
- 註冊後，按 `create a new app`
    - ![](https://i.imgur.com/bsSZ0Hg.png)
    - 點選 `Open App` 可看到預設頁面
        - ![](https://i.imgur.com/AuqQuH7.png)
        - 預設頁面:
        - ![](https://i.imgur.com/aXFIEFO.png)


- 申請部屬API
    - `點選右上角帳號設定 => Applications => Create Authorization` 產生一組 Token
    - ![](https://i.imgur.com/6I5Ep47.png)

    - ![](https://i.imgur.com/W3OtxCs.png)
    - ![](https://i.imgur.com/QfyTlqb.png)
    - ![](https://i.imgur.com/LN7U31N.png)


#### Step 8. 在 Gitlab 中加入部署所需的變數
- `Project -> Settings -> CI/CD -> Variables`
- ```txt=
    variable 1.: HEROKU_PRODUCTION_PROJECT_NAME -> <Heroku 專案名稱>
    variable 2.: HEROKU_PRODUCTION_API_KEY -> 部署 Token

- 

#### Step 9. 加入專案資料 APP_KEY
- `Heroku Project -> Settings -> Config Vars`
- 加入一個變數，取名叫 `APP_KEY`
- Value值 要去 gitlab 的 .env 檔案中看
- 
- 

#### Step 10. 調整部屬的程式碼和 .gitlab.yml
- 新增一個 `Procfile` 的檔案在專案中
- 此為 Heroku 在部署更新時啟動的對象，比如範例為我們網頁服務使用 apache2 指令運行並把入口指向專案資料夾中 laravel 專案的入口資料夾
- ```txt=
web: vendor/bin/heroku-php-apache2 public/

- 調整 .gitlab.yml 檔
    - ```txt=
      production_deploys:
          stage: deploy
          variables:
            HEROKU_PROJECT_NAME: $HEROKU_PRODUCTION_PROJECT_NAME
            HEROKU_API_KEY: $HEROKU_PRODUCTION_API_KEY
          before_script:
            - sudo gem install dpl
          script:
            - sudo dpl --provider=heroku --app=$HEROKU_PRODUCTION_PROJECT_NAME --api-key=$HEROKU_API_KEY

- 調整 GitLab 使用 `sudo` 權限
- ```txt=
sudo visudo

    - 在最下方加入這一行
        - ![](https://i.imgur.com/3rI2YEb.png)
        - ```txt=
            gitlab-runner   ALL=(ALL) NOPASSWD:ALL

#### Step 11. 成功畫面圖
- 等待 pipeline 的執行
- passed 後再到 Heroku 的 Open APP 中開啟
- 成功圖:
- 

## 參考資料
### DevOps
:::spoiler DevOps 參考資料
- [The History of DevOps](https://www.appknox.com/blog/history-of-devops)
- [DevOps principles](https://www.atlassian.com/devops/what-is-devops)
- [為什麼會出現DevOps](https://www.ithome.com.tw/news/96861)
- [什麼是 DevOps - 艦長](https://chengweichen.com/2015/08/devops-taiwan-meetup-devops-ithome.html)
- [什麼是 DevOps - iT邦幫](https://ithelp.ithome.com.tw/articles/10184557)
- [你在找的是 SRE 還是 DevOps](https://medium.com/kkstream/%E5%A5%BD%E6%96%87%E7%BF%BB%E8%AD%AF-%E4%BD%A0%E5%9C%A8%E6%89%BE%E7%9A%84%E6%98%AF-sre-%E9%82%84%E6%98%AF-devops-2ded43c2852)
- [化解DevOps文化衝突](https://read01.com/588jL.html#.YmozwtpBxaQ)
- [DevOps & CAMS](https://squadex.com/insights/how-to-implement-devops-with-cams/)
- [SLA-wiki](https://zh.wikipedia.org/wiki/%E6%9C%8D%E5%8A%A1%E7%BA%A7%E5%88%AB%E5%8D%8F%E8%AE%AE)
- [服務級別協定-iT邦幫](https://ithelp.ithome.com.tw/articles/10076833)
- [SLA-blog](https://www.bmc.com/blogs/sla-template-examples/)
- [論開發與運維衝突的根源、表現形式及其解決方案 - 壹讀](https://read01.com/zh-tw/RKE23M.html#.YmwFE9NBw2y)
- [論開發與運維衝突的根源、表現形式及其解決方案 - 騰訊雲](https://cloud.tencent.com/developer/article/1540777)
- [DevOps技術發展史](https://kknews.cc/news/oqyy2vm.html)
- [開發 or 運維，DevOps 工程師實際上是做什麼的](https://www.ipshop.xyz/4156.html)
- [DevOps: No Wonder Why Conflicting Objectives Create Friction](https://www.linkedin.com/pulse/devops-wonder-why-conflicting-objectives-create-friction-geffray-1)
- [SDLC - Waterfall Model](https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm)
- [Google's SRE Books - Practices](https://sre.google/sre-book/part-III-practices/)
- [Google 實做 DevOps 的 SRE 方法介紹](https://blog.cloud-ace.tw/application-modernization/devops/what-is-devops-how-google-use-sre/)
- [Class SRE Implements DevOps](https://www.ahsan.io/2019-05-26-sre-implements-devops/)
- [開發環境、測試環境、生產環境、UAT環境、模擬環境詳解 - 程式人生](https://www.796t.com/content/1548984078.html)
- [Site Reliability Engineer (SRE) vs. DevOps: What’s the Difference? - *Leapwork*](https://www.leapwork.com/blog/site-reliability-engineer-sre-vs-devops-whats-the-difference)
- [SRE vs. DevOps — what’s the difference? - *Codilime*](https://codilime.com/blog/sre-vs-devops-what-is-the-difference/)
- [SRE vs DevOps: What’s The Difference? - bmc](https://www.bmc.com/blogs/sre-vs-devops/)
- [SRE Basics: Site Reliability Engineering Explained - bmc](https://www.bmc.com/blogs/sre-site-reliability-engineering/)
- [How SRE relates to DevOps - *ORELLY*](https://www.oreilly.com/library/view/how-sre-relates/9781492030645/)
- [How to Engineer for Real Reliability Using Dickerson’s Hierarchy - *CONTINO*](https://www.contino.io/insights/how-to-engineer-for-real-reliability-using-dickerson-s-hierarchy)
- [維運管理與 SRE 的關係](https://blog.cloud-ace.tw/application-modernization/devops/about-sre/)
- [SRE vs. DevOps [Understanding Differences & Similarities]](https://www.blameless.com/sre/sre-vs-devops)
:::

### CICD
- [it人](https://iter01.com/595038.html)
- [建構師觀點](https://columns.chicken-house.net/2017/08/05/what-cicd-do-you-need/)
- [靜態程式分析](https://kknews.cc/news/lmaa83g.html)
- [黑箱白箱](https://sites.google.com/site/nutncsie10412/ge-ren-jian-jie/bai-xiang-yu-hei-xiang-ce-shi)
- [SAST DAST IAST](https://hdivsecurity.com/bornsecure/sast-dast-vs-iast-all-you-need-to-know-about-ast-tools/)
### CICD security
- [白帽觀點](https://secview.io/posts/9-ci-cd/)
- [top 10 CICD security problems](https://www.cidersecurity.io/top-10-cicd-security-risks/?fbclid=IwAR3QPW1JVS8kkHuS9tst09GCMwEFjZIe2_6LVCXwfewrH6bJ0Y7TgVmLm50)
### CICD工具
- [CI CD 工具選用](https://www.gushiciku.cn/pl/gaCJ/zh-tw)
### GitLab
:::spoiler GitLab 參考資料
- [GitLab-document](https://docs.gitlab.com/)
- [GitLab-runner](https://docs.gitlab.com/runner/)
- [GitLab - *it邦幫忙*](https://ithelp.ithome.com.tw/users/20120986/ironman/2733?page=1)
- [GitLab-slideshare](https://www.slideshare.net/warfan/gitlab-gitlab-workflow)
- [GitLab - *wiki*](https://en.wikipedia.org/wiki/GitLab)
- [GitLab vs GitHub](https://www.geeksforgeeks.org/difference-between-gitlab-and-github/)
- [Git、GitHub、GitLab 三者之間的聯繫以及區別](https://www.readfog.com/a/1634443161186177024)
- [Top 10 best Git hosting solutions and services in 2021](https://www.devopsschool.com/blog/top-5-git-hosting-solutions/)
- [Why GitLab](https://about.gitlab.com/why-gitlab/)
- [【概念筆記】什麼是軟體授權條款(Software License)? 授權條款相關概念一次釐清](https://medium.com/@ellierellier/%E6%A6%82%E5%BF%B5%E7%AD%86%E8%A8%98-%E4%BB%80%E9%BA%BC%E6%98%AF%E8%BB%9F%E9%AB%94%E6%8E%88%E6%AC%8A%E6%A2%9D%E6%AC%BE-software-license-%E6%8E%88%E6%AC%8A%E6%A2%9D%E6%AC%BE%E7%9B%B8%E9%97%9C%E6%A6%82%E5%BF%B5%E4%B8%80%E6%AC%A1%E9%87%90%E6%B8%85-9d70e29f3a29)
- [常見的五個開源專案授權條款，使用軟體更自由](https://noob.tw/open-source-licenses/)
- [在開源時代的興起下，如何透過License共享並保有權益](https://progressbar.tw/posts/61)
- [版權有什麼要注意的地方？－ 軟體授權條款 - *iThome*](https://ithelp.ithome.com.tw/articles/10243402)
- [Centralized vs Distributed Version Control: Which One Should We Choose?](https://www.geeksforgeeks.org/centralized-vs-distributed-version-control-which-one-should-we-choose/)
- [What are all the differences between Git and GitHub and Gitlab? - *Quora*](https://www.quora.com/What-are-all-the-differences-between-Git-and-GitHub-and-Gitlab)
- [The benefits of a distributed version control system - *GitLab.com*](https://about.gitlab.com/topics/version-control/benefits-distributed-version-control-system/)
- [What is a centralized version control system - *GitLab.com*](https://about.gitlab.com/topics/version-control/what-is-centralized-version-control-system/)
- [What is Git and Why Should You Use it? - *nobledesktop*](https://www.nobledesktop.com/learn/git/what-is-git)
- [和艦長一起玩轉 GitLab & GitLab Workflow - *slideshare*](https://www.slideshare.net/warfan/gitlab-gitlab-workflow)
- [Commits are snapshots, not diffs](https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/)
- [Git Internals - Git Objects](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)
- [What Are the Best Git Branching Strategies](https://www.flagship.io/git-branching-strategies/)
- [Git Hash](https://stackoverflow.com/questions/35430584/how-is-the-git-hash-calculated)
- [Git 原理入門 - *iT邦幫忙*](https://ithelp.ithome.com.tw/articles/10190453)
- [Git-flow作者稱其不適用於持續交付?](https://iter01.com/607587.html)
- [Gitlab-CI 入門實作教學 - 單元測試篇](https://nick-chen.medium.com/%E6%95%99%E5%AD%B8-gitlab-ci-%E5%85%A5%E9%96%80%E5%AF%A6%E4%BD%9C-%E8%87%AA%E5%8B%95%E5%8C%96%E9%83%A8%E7%BD%B2%E7%AF%87-ci-cd-%E7%B3%BB%E5%88%97%E5%88%86%E4%BA%AB%E6%96%87-cbb5100a73d4)
- [Gitlab-CI 入門實作 — 自動化部署篇](https://nick-chen.medium.com/%E6%95%99%E5%AD%B8-gitlab-ci-%E5%85%A5%E9%96%80%E5%AF%A6%E4%BD%9C-%E8%87%AA%E5%8B%95%E5%8C%96%E9%83%A8%E7%BD%B2%E7%AF%87-ci-cd-%E7%B3%BB%E5%88%97%E5%88%86%E4%BA%AB%E6%96%87-cbb5100a73d4)
:::