自救必看三大準則

CI 是條不歸路

今年九月初參加完 DevOps 2015 之後，有感而發，寫了兩則 tweets：
說實在的，打從 1999 年 Kent Beck 經典著作 Extreme Programming Explained 問世，整個軟體文化就被徹底分裂成兩個國度。以 agile best practices 出發的國度，不斷演化至另一個國度難以企及的高度。
--- Quote: 2015-09-03 Tweet #1
這個時代，如果還覺得 DevOps 是 mission impossible，可以說，連 1999 年的小團隊水準都達不到。或許該回頭蹲馬步，好好思考 Extreme Programming Explained 裡面講的幾個 best practices，有哪些可以嘗試看看。 
--- Quote: 2015-09-03 Tweet #2
Extreme Programming Explained 書中列的 best practices 很多，有些與組織文化及流程息息相關，也不見得一開始就能被說服。其中，我覺得最立竿見影的，與組織文化流程最少互斥的，就是這幾項：
  • Ten-Minute Build
  • Continuous Integration
說來容易，做起來可也得花一番工夫。但這世界上，有些打地基的事，不做，就像不會基本代數，就註定與微積分的境界絕緣。
CI，就是幫助你打好地基，開啟另一扇窗的手法。
Agile、CI、CD、DevOps、Scrum、TDD⋯⋯這個新國度，有太多神奇咒語，讓人一頭霧水，也搞不清楚優先順序。雖然我不認為有放諸四海皆準的萬靈丹特效藥，但是如果真的要挑出一項可以當做照妖鏡或試金石的切入手法，我認為，就從 CI 開始吧。
CI (continuous integration)，是一條不會過度陷入工具至上的 "cargo cult" 迷思，又能從某些角度有效撼動既有的流程制度。難怪梅姐 (Marissa Mayer) 會選擇用這條角度切入：
「沒有持續交付 (Continuous Delivery)，專案不得上線，我不是在說笑。」Yahoo 執行長 Marissa Mayer 的宣言。
--- Quote: 【誰說大象不能實現 DevOps】雅虎 97% 專案擁抱持續交付的關鍵
CI，不管你選用的是當紅的自架工具 Jenkins，或託管給 Travis CI（OSS 專案可免費使用），重點是：請踏出第一步。
初步嘗試 CI，一定會遇到絆腳石，但你不是第一個。我推薦過的好書《笑談軟體工程：敏捷開發法的逆襲》，就徹底討論過該議題了。摘錄一段當時的推薦文：
作者感慨：「在臺灣很多試圖採用敏捷方法但卻槓龜的團隊，缺少『追求技術卓越』的精神很有可能是一個主要的原因。」譬如說，如果沒有紮實的「自動化測試」及「持續整合」工夫，那麼，逐漸累積的「測試債」會讓 sprint 制度破功。當然啦，紮實的基本功並非一蹴可幾，作者也勉勵看過本書卻認為自己辦不到的人：「要『傻的願意相信書本裡所說的』，不要在尚未嘗試之前就先否定。」你願意開始嘗試嗎？
--- Quote: iThome 2012年 iT人必看的好書
手頭沒這本書的，不妨看看以下幾則文章：
不過，對「聰明人」來說，「傻得願意相信」可能是頭一個要面對的關卡吧。

今早，又忍不住寫下了：
CI/CD/DevOps 既是條不歸路，更是大躍進之路：一旦踏出第一步，就注定你會不斷接觸遠離平庸的新觀點、新技術。

至於背後是不是跑 agile，反而不那麼絕對了。 

屢屢從自己與別人演講、教育訓練、Q&A 中歸納出來的心法……
--- Quote: 2015-12-21 Tweet
重點是：一旦踏出第一步，就注定你會不斷接觸「遠離平庸」的新觀點、新技術。
所以，為了呼應剛剛的感想，在新梯次的 Ansible Workshop，乾脆帶大家用 Travis CI + Docker 玩一下 CI/CD 好了。因為從今年五個梯次 Docker Workshop 的經驗看來，滿意度最高的實作任務，一直都是 GitHub → Docker Hub 這一段 CI 動線⋯⋯
參考：https://school.soft-arch.net/blog/70585/ci-no-turning-back

留言

張貼留言

這個網誌中的熱門文章

IIS - ASP.NET 網站基本優化設定

圖片
  運行 ASP.NET 基本上都是掛載在 IIS 上面，但 IIS 預設的設定，並不適合 24 小時不中斷的營運系統。 如果沒有適當的調整，可能會造成使用者的感受不佳，而你又偏偏不會遇到。 本篇將介紹 IIS 運行 ASP.NET 網站的基本優化設定。 應用程式集區 打開 IIS 管理員，到應用程式集區，選擇網站後，開啟進階設定： 1. 一般 (General) 佇列長度 (Queue Length) 預設值是  1000 ，當封包數量在同一時間到達該指定值，之後的 Request 都會變成 HTTP Status 503 Service Unavailable。 例：當有同時間有 1001 個 Request 一起送到 IIS，第 1001 個 Request 會直接回傳 503，不會進到 ASP.NET 處理。 也不是無限大就好，也是要看伺服器等級。 假設調成 10000，也真的有同時 10000 的量，可能會演變成  CPU High  的問題。 因此，這個欄位沒有建議值，網站封包量很大才有需要調整這個欄位。 啟動模式 (Start Mode) 預設值是  OnDemand ，當網站執行回收後，會等到第一個 Request 進來，IIS 才會把網站啟動。 所以第一個連上來的使用者會等到比較久的時間，ASP.NET 初始化完成後，使用者才會得到回應。 建議設定成  AlwaysRunning ，當網站執行回收後，IIS 就會直接啟動 ASP.NET。 2. 回收 (Recycling) 固定時間間隔 (Regular Time Interval) 預設值是  1740 ，也就是每隔 29 小時 IIS 就會把該網站重啟。 很可能重啟當下使用者正在操作，對於要 24 小時不中斷的系統來說，這真的是很不妥當的事情。 如果 ASP.NET 的 Session Mode 是用 InProc，網站重啟使用者就全被登出了。 建議設定成  0 ，也就是關閉定期重啟網站的設定。 如果網站真的需要定期重啟，可以在 特定時間 (Specific Times)  設定，固定每天哪些離峰時間做重啟的動作。 3. 快速失敗保護 (Rapid-Fail Protection) Enabled 預設值是...
閱讀完整內容

Node.js 部署至 IIS 站台

圖片
基於公司網路架構的規定 記錄一下自己是如何成功將手邊的 Node.js 部署到 iis 上。 一、安裝工具 以下三樣，順序固定 ．安裝 node-v14.17.5-x64.msi 的node工具 https://drive.google.com/file/d/1oMVvy0p4ViP7v-EMA8vPqIghy_ulW_Af/view?usp=sharing ．安裝 iis 的 rewrite_amd64_en.US.msi https://drive.google.com/file/d/1O1J-NuiGpNywGesuqCeSEcFSfjKluFzN/view?usp=sharing ．安裝 iisnode-full-v0.2.21-x64.msi https://drive.google.com/file/d/1ijIW1Zz4rXrkW8F-aJQ5AA4vDromFfog/view?usp=sharing 二、建立IIS站 ．首先建立「應用程式集」 -識別：NetworkService 三、建立 web.config ．兩個方式 -自己為站台的情形，貼上以下內容 <configuration> <system.webServer> <!-- indicates that the server.js file is a node.js application to be handled by the iisnode module -->  <handlers>   <add name="iisnode" path="server.js" verb="*" modules="iisnode" />  </handlers> <rewrite>  <rules>   <rule name="sendToNode">    <match url="/*" />    <action type="Rewrite" url="server.js" />   </rule...
閱讀完整內容

遇見 Parameters 參數上限之大量資料寫入方法

圖片
遇到 Too many parameters were provided in this RPC request. The maximum is 2100. 的狀況時的處理模式 前言： 因為導入資安專案後，同仁已經針對 SQL 語法改採用 Parameters.Add 的方法撰寫。 但近來 HR 同仁因為有大量資料寫入的需求，遇到 Parameters 參數使用超過  2100  個的上限的例子 (如下圖) The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.  以下紀錄兩個方法，處理這問題： Parameters.Add 批次寫入。 SqlBulkCopy 大量資料寫入。 實作(一) Parameters.Add 批次寫入： 一樣使用 Parameters.Add，但會依 Parameters.Count 批次寫入資料 ( 效率差 ) protected void Button1_Click ( object sender, EventArgs e ) { //================================================== // // 1. 加入參考：System.Transactions // 2. using System.Transactions; // //================================================== //引用stopwatch物件 (計算執行時間) Stopwatch sw = new Stopwatch(); sw.Start(); //創造 DataTable，準備來接資料 DataTable dt = new DataTable(); dt.Columns....
閱讀完整內容