###### tags: `敏捷` ## 共筆快速入門 https://hackmd.io/s/quick-start-tw <font color=#f00>**如果有需要貼入圖片可以直接螢幕截圖放到本共同筆記裡,如以下影片示範**</font> [https://youtu.be/W2tIBZiTYR0] 如果換字體顏色, 把以下程式碼拷貝來改即可 * <font color=#f00>紅字</font> * <font color=#00f>藍字</font> * <font color=#390>綠字</font> ## 主講人簡介 ![A4海報_Ray_240119](https://hackmd.io/_uploads/rkj5g4joa.jpg) ![image](https://hackmd.io/_uploads/HkvB7kv3p.png) ## 申報 PDU ![image](https://hackmd.io/_uploads/HkktXkP3a.png) ## 講者簡介 ![image](https://hackmd.io/_uploads/Bk1ISum36.png) ## DevSecOps 就是敏捷和資安的結合 ![image](https://hackmd.io/_uploads/H1cg8O726.png) 我認為是「短週期交付價值」 ![image](https://hackmd.io/_uploads/SJgq8OXnT.png) 敏捷宣言 左邊比右邊重要,但不是代表左邊不重要,而是因為左邊能夠快速交付價值。 ## 敏捷宣言:人員與互動 vs 流程與工具 直接討論最快,而不是用工具 ## 敏捷宣言:可用的軟體 vs 詳盡的文件 要馬上可以用,所以沒時間寫文件 過去寫規格書都是很技術性的,從11月開始到隔年2月就要上線,但規格十分複雜,在網路上也找不到充足的資訊。 RD很嚴謹,因此規格書必須很完整,寫3個月,工程師花2周看,又寫了一堆問題,中間來往花了九個月才上線 即便是世界級的 Facebook ,現在叫 Meta 都無法預測產品的未來,我們也無法預測,所以採用敏捷的方式,能夠短時間交付價值,若是錯誤了,能夠快速丟棄,取得經驗。若是正確了,那當然很好。 ## 敏捷宣言:與客戶合作 vs 合約的協商 如何給客戶需求有價值的東西,就是只花二周就給客戶,讓客戶在身邊一起做,這就是「短週期交付價值」。 ## 敏捷宣言:因應變化 vs 遵循計畫 做了再說,趕快取得回饋 ![image](https://hackmd.io/_uploads/H1KPO_Q3p.png) ## SCrum 5 Values ![image](https://hackmd.io/_uploads/ryqfVJD2p.png) 承諾,有勇氣去做困難的事,所以這二周要專注,不去處理其他事。 ## Agile Development 敏捷宣言和 Scrum 都提到了要交付價值 ![image](https://hackmd.io/_uploads/H1DCduQ2p.png) 講 DevOps 之前,要先講 CI / CD ![image](https://hackmd.io/_uploads/SknbKumna.png) 開發團隊分析需求,進行設計、然後開發,測試,佈署,直到上線維運 從需求到佈署,為了要能夠快速的交付價值(短週期交付)就是敏捷的開發。 過去,在 Agile Development 都是手動處理,太沒有效率,結合自動化 CI / CD 就能夠更快進的交付價值。 ## 講者簡介 ![image](https://hackmd.io/_uploads/B1xec_72a.png) ![image](https://hackmd.io/_uploads/H1p9cuQhT.png) 在敏捷團隊中 Scrum Master (SM) 兼Product Owner (PO) 是一件不容易的事, 開發一個系統時,有時有些專業並沒有涉獵,因此找 RuRu 來協助擔任 PO。 PO 這個角色是以客戶的想法出發,因為事實上客戶並不會坐在身邊,所以出現PO。 RuRu 從會計出身,不斷接觸其他面向,也曾參加人資師塾班,在老板身邊,跟老板有同一個思考角度 ![image](https://hackmd.io/_uploads/BJ9ki_Q3a.png) 敏捷精神在企業組織中佔有很重要的角色,特別是持續的交付。 敏捷團隊開發產品,產品是要能夠快速上線讓使用者使用,才能夠面對競爭激烈的市場,如果產品開發到上線需要花很長的時間,那要如何和其它公司競爭。所以透過 CI/ CD 的轉型,我們讓部署的時間從原本的 6 小時縮短到 6 分鐘。 導入 CI/ CD 有什麼好處呢?部署的次數可以更多次,時間省下來才有空思考創新,每個功能的命中率也能夠打中市場的需求。 命中率高,才有空思考 ![image](https://hackmd.io/_uploads/BktXs_m36.png) ![image](https://hackmd.io/_uploads/SJvri_X3a.png) ![image](https://hackmd.io/_uploads/rkUM3OXhp.png) # CI/CD 的導入 一個工程師的薪資是不低的,要等一個月去研究CI/CD是不容易的,但由於自己是CEO,所以放手讓他研究,果然有好的結果,原一次布署要六個小時,最後只需6分鐘。 敏捷開發每二周就要有一個產品, ![image](https://hackmd.io/_uploads/HyYzpu73a.png) # Deploy Lead Time 從部署前(程式碼上去,也就是 CI)到部署完成的時間 ![image](https://hackmd.io/_uploads/B1psTumna.png) 收到一個需求,平均16天要上線,但部署要8天,怎麼行 ![image](https://hackmd.io/_uploads/B1G7CdQhT.png) 持續整合,要透過自動化工具 CD 指的是持續部署與交付 從測試站到正式站,剛剛說要 6 小時,現在要縮短到 6 分鐘。部署到正式站台需要有主管核準,在這之前都是自動化,自動化的好處之一是可以避免人為失誤。 ![image](https://hackmd.io/_uploads/SJB6Rum3T.png) AWS在client 端寫好程式後commit上傳到code commit->Code Build Code Aftifact管理外部程式 部署用codeDeploy 營運(客服人員)要將()->提供給工程師需改後經過主管再部署 ![image](https://hackmd.io/_uploads/BJryetXna.png) 為什麼會需要 DevSecOps ? 因為在部署到正式站台前需要有主管審核確保營運的安全性,營運需要有嚴謹的測試和確認。 從需求到營運都要考慮到安全。 ![image](https://hackmd.io/_uploads/Hy8uxKmna.png) ![image](https://hackmd.io/_uploads/SknngYQnp.png) 加上了 Security 的 AWS 架構,複雜多了。 開發團隊多個工程師將程式碼 Commit 到 Git, 會先將程式碼整合, 然後執行測試,經過原碼掃描 (靜態測試),軟體組成分析,動態測試 (DAST) ![image](https://hackmd.io/_uploads/r1vxWFXha.png) 軟體組成分析的作用是檢查 open source & 套件有沒有漏洞及需要更新。 Ex: 著名的 Open Source 套件 Log4j 曾經發生一個重大的資安漏洞,CVSS 的評分是 1-10 分,10分是代表最嚴重的漏洞而當年 Log4j 的漏洞就是 10 分。 參考:https://nvd.nist.gov/vuln/detail/CVE-2021-44228 log Form->記錄套件版本等 當用的套件有資安問題時,該如何 1.不要用,自己來 2.修正程式碼,誰能改 軟體組成分析後確認沒有漏洞或需要更新,可以進入動態分析 (DAST)。經過一連串的安全性測試能夠降低上線的風險, 一連串的測試報告能提供主管審查決定是否能進行正式站台的部署。 ![image](https://hackmd.io/_uploads/HJErGKX3T.png) ## GitLab DevSecOps 最佳實踐 ![image](https://hackmd.io/_uploads/H1pe7tX2T.png) # 要如何導入安全 ### 開發團隊中要有安全冠軍 OWASP 的安全建議中,認為團隊中要有一個人懂得資訊安全議題來協助團隊開發出更安全的產品,一個受過資訊安全訓練的專業人員,他就是安全冠軍。 ![image](https://hackmd.io/_uploads/SyRamFmh6.png) # Q & A ![image](https://hackmd.io/_uploads/HkzdNtX3p.png) 如果能知道用了那些套件,管控好,不一定每次都要做scan,因為這都需要費用 ![image](https://hackmd.io/_uploads/rJDR8YXh6.png) 處理安全議題要愈早(往左移)愈好 要循序漸進,先原碼掃描 iac要寫code 用程式碼將硬體基礎建立起來 自動化+懂安全,逐步建立->最重要的是企業文化 安全事件、中斷大多是事故團隊在處理 漏洞是DEV團隊在處理 老板自己來或授權外部專家才能有效,否則由下往上困難 安全這件事,在地端跟雲端都一樣,提供雲端的廠商會加強安全,但重要的是使用者對於雲架構的了解程度。