Search
NT 390 特價中
使用 Node.js、WebDriverIO v7、Javascript、BDD、Percy、Jenkins、BrowserStack 學習下一代自動 Selenium 測試！
從這 8.5 小時的課程，你會學到
1 Web 自動化測試
2 處理 Web 元素
3 用 Cucumber 和 CodeceptJS 學習BDD
4 端到端測試範例
5 頁面物件設計模式
6 與 Jenkins 的 CI/CD 整合
7 實施 Babel Transpiler
8 用 BrowserStack 進行雲端測試
https://softnshare.com/automated-software-testing-with-webdriverio/
藉著在 Ant 哥這一篇下的回覆（
https://www.facebook.com/1815507975/posts/10215890666418971/?d=n），剛好能帶出一個重點，其實CI 跟 CD 從來都不該是指 "build server"，而是狀態。
持續整合 (Continuous Integration) 指的是：當團隊不只一個人對同一份 code base 在進行修改時，能多快地被整合在一起，並確認執行結果符合需求預期。
持續交付 (Continuous Delivery) 指的則更偏向：對 code base 的任何修改，在整合完確認無誤之後，可以不間斷、自動、快速地交付到 production 給使用者用。（包含 hotfix 修問題，包含 feature flag 的 rollback）而不是得等待 release 的日期才能 release，而不是得等一堆環境上的手動測試完，再自行打包對應的 feature code base 上到 production.
那種 DevOps = CI/CD = build server 的，要嘛就是被迫得用這樣的說明其他人才聽得懂，要嘛就是根本不懂 DevOps 跟 CI/CD 背後真正的涵義，以及那種狀態下的軟體開發交付，以及真正想要解決的問題。（自動化只是其中的一小個必要條件）
看大家說的 CI, 可以簡單把持續整合當作有狹義跟廣義兩種。
狹義就是只到拉 code 跟 build 跟打包。
廣義就是包含整合 build 完的 package 「是不是符合預期」，要知道使用起來有沒有符合預期，自動化測試是基本的。包含最基底針對邏輯的單元測試，還有部署到測試環境之後 end-to-end 的驗收測試。
有趣的是，大部分人在講 CI 都是廣義的，該有的都要有（我們以前 build job 還包含要自動產生符合公司規定或政府規定的 上版文件並自動發送通知），基本款就是拉 code, build, 靜態程式碼分析, 自動單元測試, 打包, 部署到下個環境, 執行該環境的 end-to-end 測試，產生文件。
但大部分嘴巴講廣義 CI 的人，他們實際的 CI 卻是狹義的 CI，只有拉 code + build, 勉強多一點靜態程式碼分析的套件，但也只是分析而已，也不會依據報告結果去修正或重構。
這篇文章探討的是資安與 CI/CD 流程整合的一個思路與經驗談。如果今天有辦法將資安掃描與 CI/CD 流程給整合一塊，是否可以讓團隊中的開發人員與資安人員一同合作，減少衝突與吵架，讓團隊產生的程式碼更佳強健與安全。
如同大部分的 CI/CD 概念一樣，每個團隊實做出來的方式都不盡相同，因此作者對於如何將資安整合到 CI/CD 流程中給出了一個範例，透過這個範例讓大家踏入這個領域，接者使用相同思路將其整合到自己團隊的工作流程中。
作者提出了四個階段
Level 1: 安全人員發現資安問題， 開發人員修復問題
Level 2: 安全人員與開發人員合作去產生 test case
Level 3: 當問題修復後，雙方人員繼續合作去尋找系統性的修復並且開發相關的檢測工具
Level 4: 主動的去探討潛在問題，發現並修復
作者使用了一個簡單的範例來展示這四個步驟怎麼進行，該範例就是有個應用程式會於 log 中去輸出敏感的機密資料
Level 1:
安全人員發現 SQLAlchemy 的 debug logging 被打開，然後會將一組機密資訊給輸出。
開發人員透過 ObfuscatedString 的功能去保護該機密資訊欄位，確保其數值不會被輸出
潛在問題:
驗證性不佳: 當開發人員修護後，這個問題要如何被確認是真的修復了。
再次爆發: 如果其他的開發人員不理解這次的修復，意外的將修復給弄壞導致問題再次出現
問題性: 本次的問題是單一問題還是一個全面性設定的問題，是否有其他的機密資訊也一起輸出
Level 2: 自動化測試與驗證
雙方人員合作去產生 Test Case 並且針對這個 Test Case 去撰寫驗證測試，確保修改沒有問題
潛在問題:
透過自動化的測試與驗證，可以確保問題被修復，同時也可以針對未來所有的修改去測試，確保問題不會再次發生。
這時候解決的只有當前這個問題，但是沒有辦法知道說整個團隊系統中是不是也有類似的問題，也有其他的機密資訊被輸出。最差的做法就是遇到問題，就修一次，每遇到一次就修一次
。
Level 3: 探討系統化的問題
下一步驟就是雙方人員合作去尋找系統化的問題並且修復。作者提到一開始先針對單一case修復，接者才要去思考是否有全面性的問題。
這個步驟非常困難，沒有一個絕對的方式去尋找解法，根據不同case會有不同的可能性。
文章全文滿長的，有興趣的人建議閱讀全文，我建議不論是何種職位跟背景的開發人員，基本的資安概念都要有
https://jacobian.org/2021/jan/11/security-ci-cd/
影片中的 測試 對象依舊是我的萬年不變BMI 範例，但現在這個範例BMI，從原本就有的單元 測試 ， 現在又加上了 自動化 UI 測試 ，這些都是我們在 CI / CD ... <看更多>
ci cd自動化測試 在 [心得] CI 的使用注意事項- 看板Soft_Job 的必吃
這篇來聊 CI (Continuous integration) 的導入須知，
什麼是 CI ，中文常見是翻"持續整合"。
(也有人是 CI / CD 持續整合/持續交付 並稱，
我以下都只說 CI，但涵蓋是 CI/CD。)
雖然是一個常見而且通用的概念，
我個人覺得因為名字不太好懂，很多人還是一知半解。
DevOps 很大一部分的工作會跟這題有關，
這個詞的發展就我接觸的順序早 DevOps 不少。
這十年來有些詞彙的發展先後不一，
都是根據當時的市場跟分工需求，定義上有些混亂。
--------
CI 最基本的概念，至少包含，
把一個專案從 source code ，到他真的上服務，
這一段 flow 中間的自動化。
換言之， checkout 自動，build 自動，
local(nightly) release 自動，deploy 自動。
很多人對這題可能認知的只有build專案的服務。
雖然最早 CI 其實是搭配 test ，因為持續發布持續測試，
所以在每個版本可以迅速找到"假設"被破壞的地方回饋。
不過國內撰寫測試風氣不發達，
真的做到測試能涵蓋到確保安全的地方，就我所見不多。
但即使如此，build 仍然是過版失誤中，相當常見的主因，
諸如 build 錯版本，丟錯版本，丟錯地方，下錯環境參數等等。
CI 在 build 自動化的優點在於，
只要設定好一個已經變化不大的 build process 。
剩下的要出錯的機率很低，
因為機器基本上都是 step by step process。
一般來說，做好 CI 有幾個好處：
1. build 版不用倚賴特定工程師的腦內思維，把工程師的中斷減少(不會被叫去過版或buil
2. 設定即文件，而且是活的文件
3. 為測試整合打好基礎
4. 減少測試環境的過版負擔
5. 能夠提供水平角色(pm/qa) 自動存取最新 build 的資料，
包括 web / app / 各類執行檔。
有些專案甚至是每天對外發 nightly version ，
就是個典型 CI 流程的特徵。
----------
目前圈內常見的 CI 手段，
最基本的大概是定期跑排程，一些 batchjob 勉勉強強就算數了。
其他常見工具包括 jenkins (前身為 hudson)，Travis CI ，
travis CI 的優點是跟 github 無縫整合。
可能還有一些其他的，我自己是比較習慣用 jenkins 。
也不是他特別好還是怎樣，從早期就一直用到現在懶得改，
另外是步驟都可以 shell base ，
換言之你能用指令做到的就能用他做，我是用的很習慣。
另外 azure devop 也有提供 pipeline & release，
可以做對應的事情，不過 azure 封裝的比較多，
用起來我自己是覺得跟 jenkins 風格大異其趣。
--------
導入時的第一個問題，build 的環境處理：
當你裝好 jenkins ，他就是個 web server ，
然後你可以使用該台 server 上的環境進行建置。
也可以建多台 slave ，到別台機器上去建置。
(比方說某些有平台相依的，ex. mac vs windows)
建置時有些工具需要分開安裝，
如 build android 需要 android sdk ，
build .net framework 需要 msbuild。
dotnet core 需要 dotnet core runtime 。
除了像 azure pipeline 有提供線上能 build 的機器(要收錢)，
其他大部分都是得自己搞定。
另外要留意一件事情是為了隔離性，
CI 的執行使用者通常不是我們進入操作的高權限帳號，
一開始的各類設定，檔案權限處理，通常會花一點力氣。
---------
第二個常碰到的問題，在於不熟悉指令建置的 input output 。
比方說微軟體系的 msbuild ，多數人可能用過 vs 的發布工具，
但對 msbuild 怎麼用不熟。
其實能用 vs 做到的都能用 msbuild 做到，
但有時需要鑽過茫茫複雜設定海。
另外就是 build 出來的 package 在哪，有時候需要找，
有些專案設定甚至會影響 build 的結果。
要留意跟團隊溝通有變化時要更新對應的 build 設定。
像是 android 有些人會改 gradle 設定檔，加入檔名的變化，
這個設定如果 build 那邊沒考慮到就會事倍功半。
---------
第三個常碰到的問題，在於權限管理的模型設定，
有些地方是採取集中建置的策略，
有些地方是讓工程師各自建置的策略。
其中特別需要的部分，
是把測試環境跟建置環境的權限分開。
另外設定檔的保存，不要讓沒有權限的人，
存取到超過他權限的設定檔也是重要課題之一。
-----------
第四題跟第三題有點重疊，在於各類環境設定的處理。
目前主流有幾派，一個是設定在 os 的環境變數。
(台灣我是非常少看到有專案這樣做)
一個是獨立保管設定檔，
但保管在哪這點目前無標準化，就我看到大家都是各做各的。
如找個 private blob (or s3) 放之類的，
也有人是交給 ansible 之類的發布作業接手。
-----------
常見的問題還包括討厭的跨專案間的相依問題，
比方說某專案需要某建置工具的 A 版本，
另一個專案需要某建置工具的 B 版本。
有時候會需要費心去處理版本的 bin 指定跟環境安裝。
----------
最後因為每次建置，大多數預設的情況，
我們會保留 workspaces 跟 output file 。
所以如果專案 build 出來的東西不幸比較肥，
那可能會常常把伺服器的空間塞爆，
這裡的空間管理就會是問題。
常見做法是直接接到外部的 file service 做保存。
----------
CI 有時候大家會開始設定 trigger ，可能 A 專案建置完之後，要跟著整套建完上測試之類的。
當單一建置時間太常，團隊人又多時，有可能會導致建置服務的塞車。
我們可能也要留意設定上，設定是不是適當的，
舉例，每次都需要 clone 整個專案嗎？
還是只需要取最新版就好。
每次都要重裝相依性套件嗎？(ex. maven , npm , nuget )
能不能 local cache ，或是內部有個 cache service，
有些設定在 build 時，會需要稍微調校來加快效能。
總之，很多人覺得自動化建置，等於再久也沒關係，
實務經驗來說，我覺得還是得追求建置速度，
快速反應，快速前進。
還有一些相對比較不多人關心的問題，
build fail 的處理要怎麼安排，這些就是有空再說了。
我個人會建議，有機會的話，多瞭解一些發布流程如何自動化，
dotnet 工程師看看 msbuild 跟 dotnet(core) .
android 玩一玩 ./gradlew assembleRelease
signapk 怎麼指令化操作
ios 玩一玩 xcode
對自己手邊專案的掌握跟理解都會比較上升。
有時候也可以幫自己省下不少時間，
省下多一點的時間，不管是要混要認真，
還是要在週末上網寫廢文，都會比較有時間。(笑)
-----
Sent from JPTT on my Google Pixel 3 XL.
--
I have a dream, it's silly but beautiful.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.167.67.203 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1598230146.A.8A1.html
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:28:58
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:29:19
※ 編輯: TonyQ (114.136.135.6 臺灣), 08/24/2020 09:29:34
是說幾個朋友在FB說, 覺得 CI 跟 build 還是有差,
欸 我覺得原則上同意, 因為 build 只是基礎的一環.
至於有了自動 build 是不是就能達到持續整合的精神,
比方說雖然有 build server 但還是每個月 build 一次.
那樣就不能說有持續整合的精神.
這我同意啦
只是說論述總有遠近, 要講到持續整合這個架構,
能進入的人又少太多了. XDDD
(啊是說你們自己來回啊. = =)
※ 編輯: TonyQ (210.61.209.201 臺灣), 08/24/2020 14:15:18
... <看更多>