###### tags: `軟體工程`,`AzureDevops`

Azure DevOps
===
###### 講師：董大偉
Azure DevOps 介紹
---
及Git為Azure DevOps的基礎，這個解決方案都圍繞在這兩個東西上。

其中包含CI,CD,套件管理，應用程式架構，持續回饋，設計DevOps Strategy(?)

Azure DevOps能做比redmine更多的是link code change to work items.

另一常見的像jira也在做類似的事情

Azure Devops 的學習資源
---
在實際操作的時候az devops cli login 會有奇怪的錯誤訊息 ，但並不影響功能(其實還是登入了)
* [RESTful API](https://docs.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-5.1)
* [練習網站](https://azuredevopslabs.com/)

Azure DevOps介面中的開發流程
---

在Azure DevOps中，講師所提的backlog大多為客戶需求由業務轉化後的樣子，並非實際上實作的workItem，workItem為完成backlog提到的需求所要做的實際工作。

backlog完畢後會交由看版方法的board決定哪些要做，進approved接著才決定sprint中的work item，backLog不會記錄太過技術的細節但sprint中會。

Azure DevOps整合的第三方套件
---
#### CD中的Release Gates
* As a quality gate.
`Check if the level of quality is still to decide whether or not the release can continue`
* As an automatic approval.
`Check if certain things are done, before signing off to the next stage. This might in some cases be the same thing as a quality gate.`

#### 套件License掃描
* white source bolt

#### 弱點偵測
* OWASP ZAP
* AZSK Azure Security Kit
* Threat Modeling Tool

#### 靜態程式碼分析(減少技術債)
* sonar cloud

#### 版本控管
* [Git](/AniJtVybQp2y8Dvxpdud2g)

Azure pipeline
---

#### Agent
Agent是用於執行Azure pipeline的主機，主要有以下兩種類型
* Microsoft hosted agents
`使用microsoft的範本機器進行build`
* self hosted agents
`在microsft 的 Azure portal 的平台上建立虛擬機器，自行建構環境來build`

#### Security of Agent Pools
* organization agent pool
* Reader
`Members of this role can view the organization agent pool as well as agents. You typically use this to add operators that are responsible for monitoring the agents and their health.`
* Service Account
`Members of this role can use the organization agent pool to create a project agent pool in a project. If you follow the guidelines above for creating new project agent pools, you typically do not have to add any members here.`
* Administrator
* project agent pool
* Reader
`Members of this role can view the project agent pool. You typically use this to add operators that are responsible for monitoring the build and deployment jobs in that project agent pool.`
* User
`Members of this role can use the project agent pool when authoring build or release pipelines.`
* Administrator

#### Two method of implement DSC(Desired state configuration)
* pull
* push

#### CI Build
你不止可以在Azure DevOps上對GitHub做連結，讓GitHub的Code修改時觸發CI Build。
你也可以反過來在GitHub上觸發Azure DevOps的Azure pipeline

#### 兩種設定Azure Pipeline的方式
* visual designer
* yaml

Azure DevOps 名詞定義
---

#### Release
* functional release (部屬功能並告知客戶)
* technical release (部屬功能但不告知客戶)
`什麼時候會部屬功能但不告知客戶呢，假設一個feature必須等到完全完成測試好後才能部屬，這會造成一個branch太長，而如同前面於git提到的，我們並不希望這個feature branch太長，因此會先部屬，但並不告訴客戶這個新功能，或是使用feature switch來控制哪些客戶可以使用這項功能`

#### Idempotence
* 定義：重覆執行能否產生相同結果
* 兩種達成Idempotency 的方式
* 重置並自動設定
* 直接建一個新的環境

#### Configuration Drift
Desired State Configuration(DSC)

#### Database as code
這是理想，但實際上不太可行，因為上版不會永遠成功，依然有無法自動化的部份。

#### AzureRM 與Az Module on powershell
建議移掉AzureRM，再安裝Az Module

#### Azure pipeline的免費條件
* Azure DevOps上的public repository
* Github上的public repository

#### Azure pipeline的計費方案
* 分鐘計費
* jobs

#### Infrastructure as code
* 方便追蹤修改的東西
* 讓發佈的步驟一致
* 統一在不同環境的建置步驟
* 可以自由擴展
* 建置檔也可以納入版控
* 可以用codeReview檢視建置環境的變化
* Immutible service process
`這裡的意思是說，在新的服務啟用的時候舊的會被淘汱而不是更新舊的，也就是新的服務在全新的環境上了`
* Allows blue/green deployments.
`這個設計會變的很漂亮喔，先建立一個新的服務環境，然後用loadbalancer讓流量到新的地方後淘汱舊的，很漂亮的Zero Down Time Deployment`
* 可將建置環境視為一種很彈性的資源，可以自由的重新配置

#### Open-source package licensing
* attribution
* BSD
* MIT
* Apache
* downstream
* MPL
* EPL
* MS-RL
* copyleft
* GPL
* LGPL
* AGPL

#### Azure Artifacts
Package management

#### Multi-stage Builds
為了減少包裝的大小，不保留build過程中的library，只保留結果。

#### What issues are often associated with the use of open source libraries?
* Bugs
* security vulnerabilities
* licensing issues

講師的軟體開發建議
===
Azure DevOps於軟體開發中的改善
---
* 提高透明度，提高自動化
* 不是工作多就有價值，而是能否滿足客戶的需求
* 無法二週交出有價值的產品的工作不要run scrum[^first]
* DevOps在於持續交付給客戶可以使用的產品
* 利用CI，CD來減少意料之外的工作

關於敏捷開發
---
* 交付給用戶有價值的產品，而不是符合規定但不合用的系統
* 需求變更是必然的，不固定需求，並面對需求變更

安全性的選擇
---
scrum把架構設計攤在每一個不同的階段，但這個與security的設計有衝突，因為security的設計在一開始就要決定，可能無法推遲或日後修改，這並沒有標準答案，需要團隊討論哪些東西可以推遲哪些不行。

產業革命的趨勢
---
近代軟體開發的產業革命，就是減少人員參與，盡可能自動化
其實就是產業革命的門檻，就是自動化到可以在2~4週內交付可用的產品(minimum viable product (MVP))。
在現今快速變動的環境中，很有可能我們對產品的生命週期高估了，反正他很快就要更動，又為何要做全面的架構設計，全面的架構設計有可能在這個環境內是過度設計。

#### 自動化測試的題外話
RPA，自動key單

技術債
---
#### 講師觀點
* tights deadline
`
因為deadline或是其它不得以的理由，我們必須要在短時間完成程式，因而造成了許多技術債，講師並非完全拒絕技術債，而是要控制技術債，讓他維持在某個可以接受的水準。
`
* 框架
`
任意導入框架或對於框架不夠熟悉框架的應用可能會形成技術債。
`

何時該進行重構
---
講師認為，重構就是寫程式的一部份，他不是需要切一段時間出來做的事，而是日常的開發工作，也就是你應該隨時隨地看到某一段程式覺得他不夠好就著手進行修改[^martinfowler]。

所以重構就是寫程式，寫程式就是重構，看到就重構可以有效減少累積大量技術債再來還的情況，很多時候你以為可以等有空再做，但你其實永遠都沒空，因為需求永遠寫不完。

根據書上寫的建議，如果你的老闆認為你重構是在浪費時間，完全沒有效益，講師分享了一個書上的建議，就是不要理他，因為重構是日常寫程式的一部份，記得嗎?你的確在寫程式[^refactoring]。

軟體開發的本質是什麼
---
我們都嘗試把軟體開發當作工程來實現，軟體開發其實有很強烈的創作色彩。

單元測試
---
單元測試的撰寫也有助於維護程式碼品質，更重要的是，他讓後面的人更有勇氣改你的code，只有你能為你寫的程式撰寫單元測試，也只有這些單元測試才能夠保護後面的修改者確定自己改的是對的。

導入DevOps的經驗分享
---
### 經驗
* 大多數公司不願意改變許多原本的組織結構
* 敏捷與DevOps在導入的初期會把組織的問題突顯出來
* 頻繁且持續的交付的結果會是正確的(根據需求)

### 傳統IT的問題
在連續性的工作環境中，多工一定會造成半成品，當你在不同的工作切來切去，就會導致你在通往目標的路上走走停停

### 例子
每年過節都會出現高速公路塞車的現象，為什麼同樣量的高鐵並不會有塞車的現象?因為高鐵上的每個人是等速的，所以不會影響彼此，如果高速公路上的每一台車都等速，沒有人快沒有人慢就不會有這個問題，但這件事可能嗎，似乎不太可能。

而且在高速公路上，你依然要等待其它可能加入或退出的車流，所以說「部份的成果不能夠代表產出」。這裡老師的意思想表達，專案的成果不可能由某一個單位決定，雖然從某些人眼中看起來好像是這樣子，但實際卻不是。

### 改善建議
#### 停止製造半成品
如何停止製造半成品，不要讓你的工程師多工，或是把工程師的時間塞滿，傳統的安排方式就是讓工程師在不同的案子當中切來切去，實際上，你切出去時就有可能留下半成品，而你從別的案子中切出來也在製造半成品，這些都是日後的技術債

#### 找到浪費的地方，並且持續改善
如果你的工程師一天到晚都在救火，根本無法做那些重要的事，那就把他找出來，改善他，會讓專案品質變好速度變快的方法不是加錢，也不是加人跟加班，是避免浪費

#### 導入後改善的指標數據
* 計劃外的工作數量有沒有降低
`計劃外的工作就像救火一樣，他直接的影響到團隊，讓團隊沒有效率，讓團隊產生半成品，因此若這樣子的情況降低就是很有意義的指標，因為他與敏捷要達到的目地一致`
* 不在項目中的準備工作有沒有減少
`在DevOps的雲端平台裡，理論上增加了專案的透明度，專案的透明度代表著敏捷開發的參與者們對於目前專案要做的事有沒有明確的認知，這某種程度代表了專案中的協作是不是沒有問題的`

#### 建立良好的環境([blameless-postmortems](https://codeascraft.com/2012/05/22/blameless-postmortems/))
一件錯誤的發生有許多的原因，但解決發生錯誤的人並非解決問題的最好方式。

檢討環境，研究如何減少錯誤才是解決問題的良藥。
責怪他人不會解決問題，治標不治本。

[^martinfowler]:老師推薦martin fowler的書，他好像是重構的作者。

[^refactoring]: 這句話來自重構一書。

[^first]:並非所有情況都適合使用Scrum有的部門或是工作性質本身就不適合，那就不用特別一定要run這樣子的開發流程，且在講師的建議中，這些無法run scrum 的東西應該被自動化

軟體工程
===
#### 發佈流程的思考方向
* 過程流程很長嗎?耗時很久嗎?
* 這個流程主要的目的是什麼
* 誰要來執行這個流程
* 這個應用程式可以用覆蓋的方式更新嗎?
* 你需要為了處理bug而額外增加步驟嗎?
* 需要一個隔離的環境來執行這個流程嗎?

#### Release and Deployment
發佈了程式，但並不告訴使用者，我們也稱為Techincal Release, 通知用戶時則為Functional release，一般來說，為了避免一次發佈大量功能而造成無法辨認的相容性問題，會逐次發佈Technical Release，並在過程中都沒有問題，且最後的Technical Release發佈完的測試也結束後，再通知客戶。
在Azure DevOps中，Release是CI/CD中產生的artifacts，可能是package或是container
Deployment則是發佈到機器的行為，也就是說，release(artifacts)可以被多次發佈。

#### 使用開源Library所遇到的挑戰
* Security
`需要時常注意CVE，裡面有版本以及已知的漏洞https://cve.mitre.org/`
* Quality
`可能該版本有些bug，沒有正常運行等`
* Old Version
`若要從舊版本升級可能會需要處理不止一個版本的升級，可能其它的也要一起升`
* Licensing
`使用權問題`

#### 產生技術債的主要原因
* 沒有一致的Coding Style及Standards.
* 缺乏或是設計不良的Unit Test.
* 忽略或不了解物件導向的程式原則
* 過大的單檔類別或library
* 錯誤的使用新技術或框架(Poorly envisioned use of technology, architecture and approach. )
* 過度設計(Over-engineering code)
* 文件或註解不足
* 程式的自我解釋能力不足(Not writing self-documenting code)
* 為了配合deadline抄近路
* 保留不會再被用到的code在原地

#### Definition of Code Quality
* Has Clarity
* Documented or Better self documented
* Efficient
* Maintainable
* Implements style
* Extensible
* Secure

#### 近代CI的四大支柱
* Version Control System
* Package Management System
* Contineous Integration System
* Automated Build Process

#### Threat modeling
* Defining security requirements.
* Creating an application diagram.
* Identifying threats.
* Mitigating threats.
* Validating that threats have been mitigated.

#### Purpose of threat modeling tool
* Communicate about the security design of their systems
* Analyse those designs for potential security issues using a proven methodology
* Suggest and manage mitigation's for security issues

#### Separation of Concerns
* Configuration Custodian
* Configuration Consumer
* Configuration Store
* Secret Store

雖然Mono Repository有這麼多好處，但他最大的問題就是不容易做CI/CD，因為code都在一起，區分測試範圍變的困難。

#### Contineous Integration(持續整合)
Key Benefit: Rapid Feedback for Code Quality
* 利用自動測試提升code的品質，減少壞code進入版控的機會
* 簡化測試及build code的過程

#### Contineous Delivery(持續交付)
持續交付的目的就是讓系統無時無刻都有一版正確的版本可以避免系統長時間無法使用的問題。

* Dev與Ops的角色是衝突的
* 持續交付在於實現又快又好又便宜(基於產業革命)
* 減少半成品，解決連續性工作的瓶頸
* 局部的產出不會讓整體的產出變高(因為會互等)
* 減少浪費

#### 進代軟體部屬方法
* Blue-green deployment
`藍綠部屬主要是為了Zero DownTime盡可能降低版本更新間系統不能使用的時間`
* Canary deployment
`金絲雀部屬的故事是古代的礦工會帶一隻金絲雀到礦場，如果金絲雀死掉了就馬上向出口跑，他的目的就是為了讓部份的使用者當白老鼠，若真的不行再換回原來的版本`
* Dark Launching
`不告訴客戶新的功能，通常有feature switch`
* A/B Testing
`有一個feature switch 讓用戶自己選擇兩種不同的模式`
* Ring deployment
`金絲雀與Dark Launching的合併版，但他主要是把客戶依照忠誠度分為三個層級，依序的對每一個層級進行發佈，若沒有問題再把程式推到下一個層級，這種方式通常會有feature switch也就是客戶可以自己選擇是否成為白老鼠`