研發團隊導入CI的小小心得

自從FB加入了DevOps相關的社團，總是從很多前輩身上偷學到不少東西....

某日，有網友問了問題，大致上概述是：

身為研發團隊的leader想要提升團隊能力、快速回應需求，但目前開發團隊沒有使用版本控制、issue tracking... 現狀是leader架了一個git強迫大家使用，然後詢問如何導入，應該導入或選擇何種工具、方法....

或許是職位很類似，而本身也有一點管理上的經驗，雖然不知道是否符合所謂的DevOps或Agile的精神、心法，但問題卻令我很有感。雖然很多專有名詞和心法我並不熟悉、不夠深入，但在過去自己在職場及部門發展的一些制度或方法，好像跟大家談論的方法有點像(或沾到點邊)，因此照著我的經驗及想法回答了：

在下是覺得想要提升能力的想法很好，但也要一步步來，寫code的能力都不是一步登天了，導入相關制度或想建立文化，也不可能一次到位。

我覺得順序上最優先、無庸置疑的是版控，Issue Tracking、CI可以擺在之後，總要大家先認知到版控的優點，都熟悉、知道如何應用了再走下一步。

就個人當leader的粗淺經驗，最難卻也最重要的是：建立一個正向且偏敏捷的文化；而這點又跟公司文化和風氣有點關係，個人覺得也是需要視情況調整／客製，別人用得好的心法未必適合自己，要找出適合自己單位的風格。而這需要點時間，不能因為心急，反而讓同仁反感，或未蒙其利，誤以為先受其害。

跟導入系統有點像，不是一直強逼或宣傳要導入的東西多好又多好，必須讓user先體認到這東西對自己有益、不是來綁手綁腳的、不是增加loading的，才能順水推舟的推行起來，這樣也許會順利一點。

至於要用什麼solution、要用什麼ci的產品，等到真要用的時候再來決定也都不遲，不是嗎? 那都只是輔助我們的"工具"，而不是我們的"目的"。

需要什麼，再去找什麼來解決，否則光看你列出這一堆"專有名詞"，還沒敏捷就先投降、害怕一半了；等到大家覺得這樣好像不方便、好像那裡可以透過某工具、某產品可以改善，再找solution來套用就成了。

p.s: 你這些問題我都覺得很棒，但也許可以寫在一張紙上，不求立馬有答案，過了一段時間，日積月累，也許你自己就知道該怎麼選擇了；若能培養同仁也有像你一樣主動思考、精進的習慣，那更好。再不然，找同仁一起討論啊，這是大家要run的，就大家來選，一起在過程中學習摸索。

【後記】

其實本來並沒有刻意導CI，而是參加了某次Agile的研討會，看到Jenkins的神妙，順手在部門內架起來玩，原本只是想把大家各自手動編譯的工作交給機器，沒想到這個入門磚，之後讓小弟充分體會到測試、自動化建置...等等的重要性及好處，以前未實行前，總覺得這些好似在打高空一般，因此才覺得唯有體會到相關工具的好處之後，推行才能順利；現在日常的專案開發，已經不能無Jenkins了，使用它就像使用版控一樣自然。