[第八屆IT邦幫忙鐵人賽] 心得與感想

前言

終於完成這次IT邦幫忙鐵人賽,深刻有一種如釋重負的感覺!!
這次算是第二次參賽,比起兩年前的經驗,今年的事先規劃加上整年所學習的技術整合,文章內容比較完善也比較一致。這個月每天回到家用完餐,寫鐵人文章到凌晨已經是規律的行程,理所當然,假日也不例外:處理完家務事與雜事後,往往開始寫文章的時候也已經是晚上。整個過程最煎熬也最花時間的部分是實作與範例,每篇文章幾乎都有安裝、程式與實作範例,而並非只有理論與描述,因為我認為透過程式碼與實作可以讓技術學習更加扎實,故每個步驟能截圖就截圖,能提供程式碼就程式碼。

感謝所有看到最後一篇的讀者,這次系列文章雖然有事先規劃,但仍舊不夠完善,抵不過一日一篇的壓力,文章品質與內容不如自己預期的好,在此先跟各位致歉,後續這鐵人賽期間內,會再檢查與修補內容,讓這系列文章更加盡善盡美。

關於 .NET Core

今年有幸因公司專案需求,使用 .Net Core 進行專案開發,先撇開套件整合與不斷更新的問題,在開發期間可以從 .Net Core 專案中看到一些未來程式開發趨勢,包含了跨平台、指令操作、萬物皆注入、pipeline-request、middleware、 wwwroot 資料夾(方便前端工作)...等。雖然因為初期變更過於頻繁,很多人不建議前期使用於產品上(也包含我),但個人對未來發展卻是樂觀其成,若是閒暇之餘或有小專案,不妨可以嘗試看看。

 

 


關於 Gulp

與這系列文章開頭說的一樣,其實持續整合與持續交付沒有一定的流程,個人因公司專案就曾經使用過csx, F#, powershell...等不同方式實作持續整合,後期會推薦使用 gulp 很純粹是容易閱讀、理解與管理。在此也感謝大主管推薦我看 clean code 相關影片與書籍,這對我撰寫程式的觀念有很大的改變,而也漸漸地追尋clean code。

 

 


關於 Jmeter

測試非常的重要,無論單元測試、整合測試或壓力測試,QA是一門學問,絕非只有隨意按按系統檢查而已,學習如何做測試是必要的。Jmeter 是研究所強者同學介紹使用,工作四年多來仍離開不這套軟體。雖然還沒有玩得很透徹,但每次接觸都有更進階的使用。玩玩 JMeter 吧,會有意想不到的收穫(當然不只這套軟體,也可以玩玩其他測試軟體)。

 

 


關於 Bot

近期內 Bot 議題越來越夯,除了應用在IOT上,持續整合的使用也是非常棒的。這次鐵人系列文有小幅度接觸 Bot Framework 並與 TeamCity 整合感覺相當爽快。一但建構好後,工程師只需要發號施令與判斷即可:與Bot聊聊天就能完成工作與收到部署情況。不要覺得建構自動化流程耗時費力(真的耗時費力),建構後的實用度其實蠻高的,節省重複工作的時間也降低工程師的壓力,讓工程師專心處理程式開發的問題。

 

 


關於 docker

docker 就個人的認知,無論在 軟體使用方法 或 建構devops 無疑是一記震撼彈。雖然其技術原理與沿革發展不甚了解,但初步與學習如何使用後,這段時間內就不斷在思考如何好好的使用 docker ,讓公司的自動化程序更穩固更快更方便管理。

其實在 docker compose、dockerfile 與命令執行的方式已經可以完成很多持續整合與測試部分,但為什麼仍舊要整合 Teamcity 呢? 就個人目前看法,TeamCity 的功能與套件仍相當實用,整合原有持續整合流程與 docker 可以讓您的自動化流程建構更加順遂,而不用因為轉用 docker 而將整個自動化流程打掉重練或重新尋找套件,但是否更有效益就需要評估與實驗了。

很開心在鐵人賽的最後有機會學習、實作與撰寫 docker 技術,透過辛苦的幾天達到自己最大的學習效益。一起學習 docker 吧!

 

 


最後

感謝鐵人賽的舉辦,讓自己能夠透過這活動督促自己學習。
感謝所有強者鐵人,樂於分享自己的學習經驗與教學文章。

在過年之前,我只想躺在家裡補眠惹 ........... /images/emoticon/emoticon01.gif

 

 


上一篇:Docker 與 TeamCity 整合
返回目錄


參考資料

註:本系列文章將於2016 IT邦幫忙鐵人賽進行同時,一併發佈於個人blogger與dotblog。