DevOps Culture Establishment from 0 to 1-How We Established DevOps Culture in Two Years?(1)
一個人可以走很快，一群人可以走很遠，當工程師時，你的成就取決於你的成長。成為管理者時，你的成就取決於你能與你的夥伴走多遠。
快速導覽下集: 從 0 到 1 的 DevOps 文化建立-我們是如何在兩年半的時間建立 DevOps 文化(下)
起源
我們的故事不傳奇，來自一個小團隊的成立，沒有資本、沒有資源、沒有高手，兩年前的我，以iOS 開發的角色，剛剛加入這間剛成立、剛轉型的公司，沒有敏捷開發、沒有 CI/CD、沒有 Cloud 的觀念，土法煉鋼，本地超英趕美，接近隕石式開發。
這篇文章是兩年半下來的心得，會分享我是如何在這間公司中，導入敏捷開發、建立全自動的流水線、 CI/CD For iOS、Android、Web、Backend...，建立容器化環境、運用容器編排，微服務、DDD，並且多方吸收，執行 UX 開發流程方法論。
並且導入夥伴教育訓練分享、內部分享、筆記文件驅動、逐漸讓夥伴們成為 DevOps 文化人，初步了解系統思維、敏捷開發核心觀念，提倡自學能力、解決問題能力。
相信我，他並不容易，但值得你動手執行，值得你說服老闆。比起一開始就加入有完整的基礎設施的公司，我卻選擇了打造這個環境。
不一定要跟我選擇一樣的路，但希望這條路的經驗分享，對大家或多或少有一點幫助。
—
從 iOS 到 Xamarin Android
時間回到 2017 年，那時的我剛剛加入這間公司，申請的是 iOS 的職位，很喜歡 Swift，因為這間公司的 JD 是以 Swift 為主軸，跟那時候大家都想跨平台、Web 方式解決移動裝置平台的公司不同，老闆對新技術也有很高的興趣，對這間公司有高度的期待的加入了。
不過，戲劇化的來了。我的第一個專案，竟然是以 Xamarin 為核心技術，開發 Android ...
Xamarin Android 的心理門檻
相信大家都有可以想像或遇過，做為一個剛入行的 iOS 小白，當遇到一個技術完全沒碰過，而且跟你目前的使用的技術、技能都接近「毫無相關」的情況下（唯一的相關就是都是移動裝置平台（咦？），那個心理門檻有多難跨過去。
2017 年的 Xamarin 並不友善，他是基於微軟派以 C# 可以製作 iOS & Android App，並提倡性能與原生差不多。
2017 年的這個專案，他並不需要 iOS，生產 Android App 是這個專案的目標，那你可能會想問，為什麼不用 Android 原生呢？
答案是當時候的 Leader 表示，目前大家都只會 C#，這樣比較好支援。吳軍老師在硅谷來信第《第 159 封信》中有稍微介紹一下，為什麼服從很重要，一個我行我素，不願意服從的人，可能會是傑出的人才，但通常難以具備領導力。那時候我雖然有一度想放棄的打算，但也沒少想試試看的心意。
看到這裡，如果是你，你會放棄嗎？公式如：剛入職一間 A 公司的 B 職位，熟悉 C 技術，但第一個項目竟然要以 D 職位，使用 E 語言，開發 F 技術。
—
成為 Xamarin Android 工程師
一開始挑戰很大，還記得連環境都建置很久，完全不懂 Android的生命週期與如何開發，以及原生 Andorid 對應到 Xamarin 的什麼 function 什麼 class
再加上那時 Xamarin 相關文件資料又很少。
但這些並沒有讓我放棄，而是發現每天都有新知識，新東西可以學習，可以解決昨天不知道怎麼解決的問題，可以解決問題，成為我心中最滿足的事情，那時候我想去克服那些辦得到，可以解決問題，這讓我很有成就感。
於是我瘋狂研究 Xamarin 與 Android，理解 Android 的生命週期，對應到 iOS 是如何，以前我在 iOS 上實現過的功能，那到了 Android 該怎麼實作？
啊？以前完全沒做過的功能，我要如何用 C# 實作？哇，實作出來了那我在 iOS 上應該怎麼寫（還是不能忘記老本行 XD）？
這期間的經驗讓我的基礎知識大幅增長，因為這種思考模式，讓我對於各平台的原理、執行方式、設計理念有極大的認知成長，對於 Web API、RESTful API 觀念、雙平台的 Layout 方式都有顯著的成長。
五個月後，我完成了這個 App，用以前完全不會的技術與平台。
接觸 Frontend 與 Backend 契機
時間來到了 2018 年的 4月，其實對於前端與後端很有興趣，也透過一些平時的時間學習與實作了一些 Side Project 小作品，這時候有一個新創公司的專案，需要前端與後端來完成。我就接下了這個任務了（咦？哪來的自信）。其實很有體悟的一個觀念是，「自信來自於上一個成功，成功為成功之母。」，自信要有，要好好的成為你的底氣，但千萬不要變成自大，變成好像什麼事情都需要你的這種高傲的態度，那只會使你墜入深淵。
前端使用 Angular，後端使用 node.js。那時候的 Angular 已經是 2+，使用 Typescript，我很喜歡 Typescript 的設計，但那時並無時間與能力將 node.js 使用 Typescricpt 實現（但後來案子結束之後自己實現了一個可以看看這裡，現在都直接使用 nest.js，這又是另外一個故事了 XD）
並且這個專案要部署到 AWS 上，那時候對於雲設施很有興趣，也有試用一些，從學 AWS 開始，讓我進入了雲環境，也愛上了他。（後來更愛 GCP XD）
這個專案讓我學習更多的是 Container 的觀念，雖然之前都有聽過看過，但沒動手做過，這個專案讓我接觸了 docker，我將前端、後端、與資料庫 mongoDB 分別以 3個 container 掛起。
在前端內一些基礎與設計實作與學習過後，了解了一些前端原理、畫面渲染原理、CSS 交互，再加上上一個 Android 的經驗，對於網路溝通、API 概念，都有更加深入的體會，如何指定一個資料夾，透過瀏覽器壓縮後列入上傳列表（客戶表示只想選資料夾XD），Router機制。
在後端中 Node.js Express ，驗證使用 JWT，以及為什麼要用，Web API 是如何實作，RESTful 的原則要如何實踐，後端分層，如何跟 Database 溝通，資料流向，算法執行、資料結構，都有更加深入的理解。資料要如何實作 CRUD，並且當時對於 node.js 異步的概念吃足了苦頭（沒遇過，完全不知道為什麼不會一起執行XD），但也對於他異步的設計與理念有更加深入的理解。還了解了套件管理包、環境管理、檔案如何透過 S3 上傳、登入、註冊、授權、Log 設計與使用者權限設計。
在雲環境中，了解了 AWS 如何工作，如何設置 AWS 權限，S3 如何工作，EC2 如何執行，Cloud Watch、CloudFront、設置 Https、DNS、Domain等等。如何在 EC2 啟用 docker machine，對於 docker 的概念有更加的理解。基本操作 Ubuntu 等等
—
其實回頭看，這接段碰的東西剛好是繼續提升所需要的一些技術，也為後面的 CI/CD、敏捷、Scrum 埋下了一些伏筆，這個階段還屬於自幹型，雖然有用一些 Trello 管理工作項目，但是離理解敏捷還有一段距離，更不要說把制度帶入團隊中。
重回 Native iOS
上個專案大概在 2018 年 6 月告一段落，時間來到了 2018 年 7 月，這次回歸最期待的 iOS 開發（其實還多 Web、Native Android與 Backend XD）
測試的專案平台需求是移動裝置、後端與一個Web 後台，還有一個簡單的 Web 前台（部分移動裝置功能）
一開始還是我去執行建設架構、環境，寫一些範例。這邊的工作量與技術如下：
- Web 前台Angular2+: 100%
- Web 後台 Angular2+: 100%
- Backend .net core 2.1: 70%
- iOS Native Swift: 100%
- Android Native Kotion: 40%
- Infrastructure: Google Cloud, Firebase
– Compute Engine– Google Storage– Windows Server 2016– Ubuntu 16.04
這邊有不是 100% 的部分，表示已經有一些團隊合作，也開始更加深入的去使用 Trello 看板去執行衝刺，從UI/UX設計師配合設計 UX 討論到 UI 實作，功能規劃、任務分配、會議討論。這時候已經有一些 PM 的職能精神，初步了解專案管理上、需求管理上有什麼痛點，這些都成為下一個專案執行 DevOps 的基石。
關於 iOS，雖然從入職到現在好像都沒有 iOS 的專案，但我其實在平時用了蠻多時間繼續做 iOS Side Projcet 的，包括維護自己上架的 iOS Project 做了很多更深度的課程，並且實作。所以 iOS 技能是沒有退步的，或許還進步許多。很推薦喜歡技術的朋友多去實作，不要因為會了就用看的，理論跟實作永遠都有差別。我本身是喜歡動手做，做到停不下來，所以沒有什麼堅持的概念。我很追從這種觀念，如果一件事情讓你喜歡的停不下來，那何來需要堅持？
關於後端.net core ，一定有很多疑問，為什麼會選他？當初其實是對於微軟開源與開放的新項目 .net core 很感興趣，全新的設計理念，強大的效能，跨平台的能力，並且在於一入職時使用 Xamarin，所以對於 C# 不算陌生。他的設計理念、對容器化友善程度與軟件設計實作技術深深的吸引了我。他真的脫離了舊.net 的包袱，這讓我對於微軟另眼相看。
關於 Android ，由於有剛入職的經驗，所以對於 Andorid 的設計概念與生命週期有一定程度的認識，只是要使用 Kotlin Native 方式來實現（完全不想在用 Xamarin XD），Kotlin 寫起來有 Swift 的味道，讓我對於他還蠻喜愛的。
關於 GCP，這是初次使用 GCP 就深深的愛上了，他專案項目分類的設計我非常喜歡（那時候用AWS 的痛點就是沒有專案的概念），並且跟 Firebase 深度結合。這次初探算是熟悉了GCP 的基本功能，對於後面的 Cloud Native建置 與 CI/CD on GCP 有深深的伏筆。
上集總結
這個專案大約在 2018 年 12 月結束，接下來就是融合以上經驗的重頭戲項目了！
這個階段大約有一些 DevOps 的觀念，知道要建置 CI/CD，要設置敏捷開發，要執行 Scrum，但都尚未執行，只有大概碰到一點邊。真正去執行敏捷開發，再進化成 DevOps 文化。這一路上來回頭看深深覺得，哇，當初是如何辦到的，也走過了一些至黑時刻，但不代表後面沒有至黑時刻XD，我們一直有個信念，提起燈吧，走起路吧，沒有一個完整的地圖告訴你應該去哪，這是一個創業的旅程，是一個創造的過程。就像理查德在《真理與進步》一書中提到的。
- 你必須不斷往前走才可能不斷發現真相
- 真相不是目的，目的是不斷往前走，一直達到你真正要達到的那個目的地
所謂的燈式認知，就是這麼回事吧。活下去，才是目前最急迫的選擇壓。
期待一下下集吧！我們下次見
澄思設計-沈思世界的解決方案
解決問題的路上，也給大家解決過的問題不同的角度思考方案，包含軟體工程、架構、使用者體驗、專案管理等方法論。澄思設計以顧問的角色，積極解決客戶的問題。理解客戶的想法，這個客戶不一定是企業，也可能是個人，解決企業問題，我們使用專案解決，解決個人問題，我們使用產品解決。我們想要找的人，是能夠解決這個世界上各種大大小小問題的人，無論是透過溝通、技術解決，同時他應該會有積極與強大的自學能力，對於解決問題充滿熱誠，與團隊、與公司共同搭上火箭成長，那你可能就是我們要找的人Klearthink Design Co., Ltd.
如果你對我們公司有興趣，歡迎參考我們的職缺，我們有機會聊聊吧 :D
職缺參考
—
yasuoyuhao，自認為終身學習者，對多領域都有濃厚興趣，喜歡探討各種事物。目前專職軟體開發，系統架構設計，企業解決方案。最喜歡 iOS with Swift， [email protected]。
如果喜歡我的文章，可以按下喜歡或追隨讓我知道呦，拍手可以拍 50 下，更歡迎許多大神指點討論。感謝您的閱讀。
部落格：yasuoyuhao’s Area