本文只有一個重點，就是介紹可以使用 GitLab API 為 Project 設定 GitLab Runner，如果是使用工具前都會查閱說明書的資深 GitLab 使用者，可以直接轉身離開喔（喂～哪有文章一開頭就把人趕走的～）
（本文撰寫時，使用的 GitLab 環境為 14.0。） （本文同步發表於 Medium。）
前情提要 之前在 GitLab Taipei User Group 中有一位苦主表示遇到了一個狀況，他必須要將指定的 GitLab Runner 分配給超過百個 Project 使用，想詢問有沒有比較簡單的方法？
一般來說如果有 Runner 需要同時供應給多個 Project 使用，通常會建議將 Runner 建立為 Group Runner。如此一來在相同 Group 內的所有 Project 皆能直接取用此 Runner，唯一的限制就是 Project 必須隸屬在相同的 Group。因此對於苦主來說，這個解法他會需要將超過百個 Project 全部搬家至 Group 內，因此不太適用。
另一個方案是，假如你是自架 GitLab Server，則可以透過 Admin 管理者，架設 Shared Runner，便能夠如同 gitlab.com 那樣，直接提供不限 User、Project 皆能任意使用的 Runner。當然要說缺點就是 Shared runner 預設是全開放給所有人皆能使用的 Runner，因此如果你又想要做出額外的權限控管，同樣又要另外想辦法。不幸的是印象中苦主似乎是使用 gitlab.com，GitLab 官方當然沒開放權限讓使用者自行在 gitlab.com 上架設 Shared runner。...
先前在擔任講師時，有時會遇見學員反應「我的 GitLab CI 沒有在運作」，出狀況的原因當然很多種，像是 .gitlab-ci.yml 的格式錯誤、內容錯誤、Runner 設定錯誤⋯⋯，本文就來條列一些常見的原因。
（本文同步發表於 Medium。）
常見狀況 以下逐一分享幾種常見的異常狀況。
一、CI/CD Pipeline 設定檔的檔名錯誤 GitLab 預設的 CI/CD Pipeline 設定檔為 .gitlab-ci.yml，要注意前面有一個 .，以及是 yaml 檔案 .yml，不要太順手寫成 .yaml。另外就是 GitLab 也能設定改用別的檔名作為 CI/CD Pipeline 的設定檔，因此也要注意是不是有啟用這項設定，搞不好你的專案還真的已經改用 gitlab.yaml 當作 CI/CD Pipeline 設定檔了喔～
二、CI/CD Pipeline 設定檔的存放位置錯誤 續上，除了檔名之外，CI/CD Pipeline 設定檔的存放位置也很重要。預設的存放位置是專案的根目錄，存放位置也同樣可以自行修改。
【小提醒】CI/CD Pipeline 設定檔的檔名及存放位置都可以在 GitLab 的 Porject > Settings > CI/CD > General pipelines > CI/CD configuration file 中修改。
三、忘了啟用 Runner CI/CD Pipeline 要能運作，你必須要為 Project 啟用 GitLab Runner 才行。在 Porject > Settings > CI/CD > Runner 中確認是否有 Enable 任何一台 Specific runner 給此專案使用。...
因為 COVID-19 疫情，所以 DevOps Taiwan Meetup #33 臨時決定從實體活動轉變成線上活動。因此需要尋找合適的線上活動解決方案。但市面上有著各式各樣的「線上會議 + 串流直播」解決方案，有沒有哪一種是花一點小錢就能一次搞定的方案呢？
也許這次 DevOps Taiwan Community 打算嘗試的 Zoom 付費方案會是一個可以考慮的選項。
本文記錄此種方案的操作步驟。
（本文同步發表於 Medium。）
操作步驟 下面逐一說明各項操作步驟。
取得 PRO 以上等級的 Zoom 帳號 首先我們需要有至少為 PRO 等級的 Zoom 付費帳號。
從下圖的比較可以發現，雖然 PRO 等級的帳號依然只能主持最多 100 名與會者的會議，但重要的是 PRO 就提供了我們想要的「社交媒體串流」及「1 GB 雲端錄製」。
有了「社交媒體串流」，就某個角度也算是間接解決線上活動「參加人數上限」的問題，未能順利搶到線上票的朋友，可以改為觀看直播，一樣能聽見講師的分享。至於與講師的互動這部分，則可以透過 sli.do 之類的額外工具收集 Q & A，再讓講師逐一回答，另外也可以適度地引導參加者將提問與討論延續至 FB 社團或其他的討論空間。
【小提醒】Zoom 的付費方案是採訂閱制的，因此如果你只打算運用在單場線上活動，在活動舉辦完畢後，記得在訂閱週期將至之前，登入 Zoom 帳號去取消訂閱。
Zoom 帳號採購的部分就不逐一說明，唯獨提醒大家在採購的時候，要注意自己有沒有不小心勾選到了不需要的「附加功能」。
（採購過程中，Zoom 會一直鼓吹你多買一點功能。）
（Zoom 不死心，繼續問你要不要多買一點其他方案。）
開啟 Zoom 的「社交媒體串流」 有了 PRO 帳號，接著要啟用「社交媒體串流」。（預設是不啟用的。）
請透過瀏覽器登入 Zoom 網站，接著進入 管理員 > 帳號設定 > 會議 > 會議中（進階）。...
DevOps Taiwan Community 於 2021/3/29 舉辦了實體的 Meetup #31，本文針對這次活動做個簡短的紀錄。
因為 COVID-19 疫情及缺講師的緣故，DevOps Taiwan Community 有好一陣子沒舉辦活動，陷入無法每月舉辦實體 Meetup，活動有一場沒一場的狀態。而這次能在 2021 年 3 月再次舉辦 Meetup 必須要特別感謝本次負責擔任講師的兩個單位——資策會及 F5/NGINX；感謝兩方的聯絡窗口及講師的協助，讓志工們可以在很短的時間內促成這次的 Meetup。
Meetup #31 一如往常由兩位講師上場，分別帶來不同的主題。
（本文同步發佈於 Medium。）
講題一：資策會的開源 DevOps 整合工具分享 這是由資策會數位轉型研究所的資深工程師蔡宗融帶來的分享，主要在介紹資策會目前打造出來的開源 DevOps 工具懶人包。（懶人包是我自己的評語）
講師表示當 DevOps 一詞在台灣開始普遍廣為人知時，資策會當然也不例外，在資策會內部也有追上這股 DevOps 熱潮，到底什麼是 DevOps、DevOps 能夠為我們（資策會）帶來什麼、以及我們（資策會）又可以為 DevOps 做些什麼。資策會在內部經歷了一番醞釀與努力之後，最後順利推出這套「開源 DevOps 整合工具」。
該工具目前有一個介紹官網，有興趣的朋友可以參閱上面的介紹，官網的網址為 https://www.iiidevops.org/
演講中講師提到 DevOps 可以帶來三項好處：
加快軟體開發與交付的速度 縮短更版週期、降低更版風險 讓開發與維運團隊共同面對問題 但要如何讓團隊開始進行 DevOps 轉型呢？一個要從文化及思維層面著手，另一方面則是從工具面著手。因此如果能提供團隊一套可以快速啟用、容易上手、已經打通 Workflow 各環節所需之自動化工具的「DevOps 整合工具」，也能有助於推進團隊的 DevOps 轉型。
那麼資策會推出這套「DevOps 整合工具」已經包含了哪些工具呢？
講師表示目前已經整合了 Redmine、GitLab、Sonarqube、Rancher、Kubernetes⋯⋯等多項工具，可以說下面這張常見的 DevOps 循環的左半邊 plan、code、build、test 的工具已經整合的差不多了。2021 的下半年，他們會繼續加強右半邊的工具整合。...
最近看了一篇熱門文章《利用 Apps Script 讓 Google 表單回覆自動產出 Google 文件》，不看不知道，看了才知道原來 Google 有推出 Apps Script 這麼神奇好用的東西，透過它可以搭配 Google 的服務實現各種「辦公自動化」。
這麼有趣的服務，令人不禁想要天馬行空的運用它，究竟我們可以拿 Apps Script 做什麼事情呢？
（本文同步發佈於 Medium。）
如前面所述，在思考 Apps Script 可以拿來做什麼時，忽然想起前一陣子研究 Jira service management 所注意到的一個功能——Customer Portal。簡單來說 Customer Portal 就是一個面向使用者的單一窗口與入口，假設今天是 IT/MIS 部門在使用 Jira service management，那麼 IT 部門就可以利用 Customer Portal 建立一個給一般員工使用的「IT 問題回報表單」。假如員工有各種 IT 問題，就填寫該表單，IT 部門則會從 Jira service management 得到員工回報的問題資訊，根據資訊開立 Ticket 並分配給工程師處理。IT 部門除了可以從 Customer Portal 得到表單提供的資訊，甚至還能夠設定當員工填寫了表單的某些選項時，就直接觸發事先準備好的自動化腳本，直接自動處理某些 IT 問題。
（Jira service management 的 Customer Portal。）
Customer Portal 這麼棒的功能，真希望 GitLab 也能擁有，但很可惜目前只能自己打造。所以就讓我們參考上面那篇文章，利用 Google 表單 + Apps Script + GitLab 試著快速搭建一個陽春版的「IT 問題回報表單」。...
（活動延期至 2021/11/24，已順利舉辦！） （非常可惜，因為 COVID-19 忽然爆發，活動已延期暫緩。看著當時寫的這篇宣傳文，真是百感交集。）
下個月 5/27、5/28 即將舉辦 DevOpsDays Taipei 2021，這次的活動場地一樣在大家熟悉的老地方「臺北文創」。由於 COVID-19 疫情的緣故，今年的講師群幾乎清一色都是國內講師，活動的規模也縮小至 1 天半，即 5/27 下午舉辦「開放空間會議」，5/28 為一整天的研討會。
（本文同步發佈於 Medium。）
活動介紹 今年是自 2017 年以來，第四次舉辦 DevOpsDays Taipei， 雖然今年活動規模縮小，但活動的豐富度依然不減。
開放空間會議 （截圖來自 FB 粉專，2019 年 Open space 的盛況。）
首先，按照慣例今年一樣會舉行大受好評的「開放空間會議」（Open Space Technology），時間會安排在 5/27 下午 13:00 ~ 16:30。
想當初 2017 年時，籌備小組一直很擔心與煩惱 Open space 到底該如何進行，擔憂會不會白白準備了場地與設備，但最後根本沒人願意額外花費一整個下午來參加一個沒有講師沒有議程的交流活動。
然而 2017 年的經驗徹底地跌破了我們的眼鏡，當年有超過一半的購票者願意在聽都沒聽過的狀態下，參加 Open space。那一年的經驗，讓籌備小組徹底地感受到 Open space 的魔力，原來人們是有辦法在很短的時間內，即產生共識、連結與認同，原來深度的經驗交流與分享可以發生的如此自然與順暢，以及原來人們並不是抗拒交流，也許只是習慣了「聽講」或者人們只是欠缺一個合適的「交流場域」。
（截圖自 FB 粉專，2017 年的 Open space 盛況。）
「開放空間會議」就是一個如此神奇、充滿魔力的「交流場域」。如果你已經確定報名參加 DevOpsDays Taipei 2021，還請千萬不要錯過 Open space。請帶著你自身的經驗、你在職場上遇到的困難與疑問、以及一個開放的心，來到 Open space 與其他人進行交流，這個下午也許你有可能會獲得超乎你想像的收穫。...
2020 年，因為爆發 COVID-19 疫情的緣故，世界各地許多的研討會都被迫中止舉辦，當時 DevOpsDays Tokyo 2020 也受到影響，被迫臨時中止。在疫情肆虐一年之後的 2021 年 4 月，DevOpsDays Tokyo 再次出發，這次以線上、線下同步進行的全新形式回到了眾人面前。（當年 DevOpsDays Taipei 2020 也同樣受到 COVID-19 疫情影響，在不斷延後舉辦與籌備事宜之後，最終也是決定中止舉辦。）
【補充】當時 DevOpsDays Tokyo 決定中止活動的事情，可以參考這篇 Blog 記錄 DevOpsDays Tokyo 2020 中止の経緯
在 DevOpsDays Taipei 2019，台灣這邊邀請了日本的 DevOpsDays 組織者（Organizer）與講師來台交流，今年則是日本的組織者邀請我們以線上的方式參加 DevOpsDays Tokyo 2021。本文就以簡短的文字紀錄 4/15、4/16 這兩天透過線上參與 DevOpsDays Tokyo 2021 的部分見聞。
（本文同步發表於 Medium。）
活動形式與大會運用的各種線上服務 （大會公告，活動將會採取線上、線下同步進行。）
DevOpsDays Tokyo 2021 採取線上、線下同步進行的形式舉辦，但由於疫情的緣故，很多講師也是採取遠距的方式進行演講。
即便是日本當地的講師，很多也是透過遠距的方式演講。有些演講會有多位講師以遠距的方式同台分享。所以有時在演講正式開始之前或結束之後，在不經意之間還可以聽見講師們在互相聊天。
如果講師是遠距演講，在線下的場地，就會將遠距的畫面投影給線下的參與者；反之，如果講師是實際來到現場分享，則會由線下將現場的講師及簡報畫面提供給遠距的參與者。
而 DevOpsDays Tokyo 2021 這次採用的遠距工具是 ZOOM。由於活動議程分為三軌同步進行，因此總共開了三個 ZOOM 會議室，參與者需要自行按照議程時間表，進入不同議程的會議室。
DevOpsDays Tokyo 2021 有英文講師，而大會很貼心的聘請了即時口譯員，因此在英文演講的時候，該議程的 ZOOM 會議室會多出一個「語言」選項。這是 ZOOM 的一項貼心功能，如此一來日本的與會者即可切換至 Japanese 聆聽口譯員翻譯的日文，反之當日文與會者在提問時，英文講師即可切換至 English 聆聽口譯員翻譯後的英文進行回覆。...