l

2012年6月30日 星期六

2010冬遊日本關西Day6-C京都府立陶板名畫庭

June 0 17:13~18:18

吃完午飯之後走出餐廳才發現原來下一個景點「京都府立陶板名畫庭」就在餐廳隔條馬路的對面不遠處。這個行程也是Kay特別安排的(其實所有的行程都是Kay安排的XD),主要是要來看安藤忠雄的建築。這個建築Teddy覺得蓋得很棒,因為雖然建築物就在大馬路旁邊,但是建築物巧妙運用水流,不但達到降溫的效果,而且還達到阻隔馬路噪音的效果(就是用流水聲蓋掉馬路傳來的噪音)。

01

02

03

 

從建築物往大門方向拍攝的全景照。

06

 

在水中的陶板畫耶,好特別啊。

04

 

建築物中有一個小型瀑布,現場聽起來的水聲還蠻大聲的,而且造成一種很沁涼的效果。

05

 

到「京都府立陶板名畫庭」不但可以欣賞建築物的設計巧妙之處,裡面的陶板名畫(把有名的畫作複製在陶板上面)還是有看頭。廢話不多說,請看。

07

08

09

10

11

12

 

建築物中最大的一幅版畫:最後的審判。

13

14

15

 

這一幅應該是最後的晚餐。

16

 

看完西方的名畫,換東方的。沒想到居然有清明上河圖耶,這是Teddy看過最清楚、最大幅的清明上河圖。

17

18

19

20

21

還有十二世紀後半日本本地的鳥獸人物戲畫

22

23

24

25

26

27

28

 

最後再欣賞一下建築物本身最為結尾。

293031323334353637

 

***

友藏內心獨白:去京都別忘了安排到陶板名畫庭參觀喔。

2012年6月29日 星期五

Scrum框架下的跨界開發

June 28 09:48~11:50

image

 

這禮拜三下午Teddy剛好有機會與「Apps跨界交流協會」的Ryan與ezScrum團隊討論「跨界開發」的議題。跨界開發不是說要鄉民們跑到人家家裡去開發程式,也不是要原本在當水電工的你去報名電腦補習班之後就可以「跨過界」變成軟體工程師。而是Ryan很熱心地想要搭起一座橋梁,讓UI設計師與開發人員可以找出一個合作模式,能夠很順利地做出美觀又好用的軟體。

軟體跟人是一樣的,「外表」和「個性」都很重要。豬哥一般鄉民們很容易被長相甜美的「正妹」給吸引,但是如果在正式交往之後,才發現這個正妹有很嚴重的「公主病」,或是做人很自私外加沒有愛心,這樣的交往關係就不容易持久。軟體也是一樣,以手機應用程式來講,在App Store上面隨隨便便都是幾十萬個軟體可供鄉民們選擇,如果App的介面沒有設計的漂漂亮亮,是很難吸引鄉民們的眼光。但是,光是漂亮只算成功了一半,如果軟體本身的操作流程不易使用,或是軟體不穩定,動不動就跟你搞什麼「重新啟動中」的把戲,那麼這樣的軟體也很難長久占用鄉民們手機裡面那一點點有限的空間。

Ryan已經成功號召了許多在UI設計界有名的公司或組織,也接觸了幾個軟體開發社群與公司,此次與ezScrum團隊的會議(Teddy單純是因為「個人原因」跑去插花的),是想討論Scrum在這種「跨界開發」的模式上,能不能幫上什麼忙。講到「跨界開發」,Teddy腦海中就冒出象棋棋盤上那條分隔紅子與黑子的「楚河漢界」。回想起10幾年前Teddy剛工作的時候(年紀大了,好像很多回憶都發生在10幾年前…Orz),也是遇到「跨界開發」的難題。當時Teddy帶領一個10人左右的團隊開發一套網路教學系統,團隊中有兩位專職的「UI設計師」。在10幾年前網際網路剛開始流行沒多久的那個年代,網路教學系統對於UI設計的要求其實不多,大該只有以下幾項:

  • 設計漂亮的icon或是按鈕。這一點算是基本款,一般的UI設計師都應該有能力可以勝任。
  • 設計網頁系統的整體觀感。設計整個網頁系統的風格、layout、配色等等。這一點就比單純地設計icon要困難不少,功力強一點的UI設計師才有辦法做得好。
  • 設計網頁系統的操作流程。這是最困難的一點,也是當年許多UI設計師的挑戰。要設計一個網頁系統,不就是設計一堆網頁,然後再用超連結把這堆網頁給連起來就好了嗎?當然不是,因為很多應用程式的工程,其實是需要控制狀態與操作流程。這樣的系統如果只是分析好一堆畫面,然後把這些畫面直接實做成一頁、一頁的網頁(不管是靜態網頁或是動態網頁),那麼使用者在操作系統的時候便很容易在網海中迷路,不知今夕是何夕,此「頁」是何處。使用者也經常遇到不小心按到瀏覽器的「上一頁」按鈕之後,整個系統就爆掉的 杯具 悲劇。

除了UI設計師能否達成Teddy心目中期待他們達成的任務以外,另一個困擾Teddy的問題就是:如何知道UI設計師有沒有認真地好好工作?這個問題聽起來很可笑,但是實際上這是一位身為程式設計出身的技術主管當時在帶領團隊最大的困擾。因為關於系統分析、設計、實作等等的問題Teddy與另外三位資深的工程師都有能力可以搞定,而且Teddy「大致上」也都很清楚每一件coding的工作需要多少時間。但是,在當時UI設計師對Teddy來講基本上就跟一個「黑盒子」差不多。

Teddy:什麼,畫一個icon要半天的時間?

UI設計師:對啊…不然你自己來畫…

***

Teddy:這個網頁操作的流程不太對喔,是不是應該用Wizard的操作模式這樣使用者比較容易上手?

UI設計師:這是網頁不是桌面應用程式耶,你不要用桌面應用程式的操作模式來思考網頁應用。

Teddy:問題是不管是桌面應用程式還是網頁應用程式,對使用者而言,一個繁瑣的操作流程,系統就應該要逐步分段引導使用者去完成才對啊。

UI設計師:那你就是要把網頁系統做成桌面應用程式的樣子就對了?!

準備開打…Orz

***

當年根本都還沒有什麼Scrum,Teddy採用的是看書學來的RUP(Rational Unified Process),但是書上並沒有說UI設計師要如何跟程式設計師一起合作啊。當時Teddy對於HCI的了解很少,與UI設計師的合作方式基本上就是請他們先把系統的prototype做出來,然後大家一起開會集思廣益,之後UI設計師再去修改,一直到做出一個大家可以接受的版本,或是大家都受不了為止XD。

不過這樣的經驗還算好的,Teddy也有遇過那種在大公司裡面,UI設計師與程式開發人員分別隸屬不同的部門。在這種情況之下的合作,只能用一個「」字來形容。UI設計師覺得程式開發人員「不識字又兼不衛生」,怎麼可以設計出這麼醜又難用的程式出來。而程式開發人員覺得UI設計師也高明不到哪去,而且做事超級會拖延的。只是要一個icon,可以拖個2-3天才給我;程式的「動線(操作流程)」還都必須要經過UI部門畫押才可以動工。這邊卡一下,那邊又需要幾天,我的程式到底還要不要寫啊。這些也都算了,另程式開發人員最不爽的是:啊你們UI設計大師搞出來的東西比我自己設計的還要難用啊。算了,既然是公司規定軟體操作流程必須要由UI設計師來負責,那我(程式開發人員)就不管了那麼多了,把程式寫出來就對了。總之到時候系統不好用不關我的事,都是UI設計的爛。

UI設計師內心獨白:我精心打造的UI簡直是藝術品啊,交給這些「大老粗們」一定沒好下場。總之到時候成品有問題就是這些程式開發人員實作能力太差啦。

Teddy內心獨白:不是你的錯,也不是他的錯,都是月亮惹的禍XD。

有這樣的團隊,公司還需要敵人嗎?

***

扯了這麼多,Teddy想講的只有一件事,那就是:跨界開發的問題不是技術的問題,而是溝通與心態調整的問題。

回到Scrum框架下去思考Teddy剛剛提到的那兩個例子所遭遇的問題:

  • 兩派人馬的誤會,有沒有可能藉由sprint planning meeting而減少或是擺平?
  • 藉由sprint planning meeting雙方是否可以更加理解對方工作的內容?
  • 雙方的工作進度是否變得更加透明?
  • 有沒有能力或是辦法組成一個cross-functional team?
  • UI設計師加入Scrum team之後,要如何與程式開發人員分工合作?
  • 在cross-functional team中,story要如何挑選,task要如何認領才不會造成「勞逸不均」的問題(有人忙得要死,有人無事可做)?
  • 同處於一個Scrum team,是否可以提升團隊成員對於所共同開發產品的歸屬感?

Teddy覺得Scrum不只是一個持續改善的框架,也是一座橋梁。橋搭的好,跨界開發的問題便可逐步地被解決。橋搭的不好,不用土石流或是颱風,光是人在上面走來走去,沒多久就自己斷掉了。

***

友藏內心獨白:Software development is all about communication。

2012年6月28日 星期四

當Branch遇到持續整合(4):Branch by Team

June 25 21:49~ 23:00

螢幕快照 2012-06-25 下午9.49.40

 

這一集要介紹四個「分支/合併模式」的最後一個Branch by Team(依團隊而分支)。Branch by Team的主要目的是要讓一個很大的團隊(數十人以上)可以同時開發一個專案或產品,但是同時還要維持trunk上的程式碼達到隨時可釋出的狀態。其主要做法為:

  • 將一個大團隊分成數個人數在九個人左右的較小團隊。
  • 每個團隊都是一個feature team,也就是說,整個專案依功能被切成若干的功能模組,而每個團隊負責開發至少一個功能模組。例如,假設有一個48人的團隊要開發一個圖書館管理系統,整個系統被分成讀者管理模組、書籍管理模組、借還書模組、期刊管理模組、電子書管理模組、報表管理模組等六大模組。整個團隊被分成六個小組,每個小組剛好八個人。這六組人馬就被指派分別開發上述那六大模組。
  • 為每一個團隊產生一個branch,每一個團隊就在自己所屬的branch上開發。
  • 當branch上的程式碼達到穩定的狀態時,branch才可以被merge回trunk。
  • 每次merge回trunk的程式碼必須要立即在merge到其他團隊的branch之中。

同樣是做branch,Branch by Team和Branch by Feature有一點很大的不同,那就是前者的branch是很「長壽」的branch,只要團隊還在,這個branch就存在。而後者的branch是很「短命」的branch,只要功能完成之後將branch的程式被merge回trunk之後該branch的生命也就跟著結束了。由於Branch by Team的branch生命週期很長,所以開發團隊就可以為每一個branch在持續整合系統上面建立一個建構專案也就是說,持續整合的工作在branch與trunk上同時執行

***

看完這四種「分支/合併模式」的介紹,還有應用時機和持續整合系統之間的關係,鄉民們應該可以發現,一個看起來很簡單的版本控制系統與持續整合的實務做法,其實箇中還是有著奧妙的學問。開發團隊必須依據專案與團隊的特性來選擇適合自己的「分支/合併模式」。不過還好扣除掉Branch for Release這個為了軟體釋出而存在的模式,真正用在開發上的模式只有三個。而這三個也很容易選擇:

  • 團隊人數很少:
    • 團隊成員集中:Develop on Mainline或是Branch by Feature
    • 團隊成員分散:Branch by Feature
  • 團隊人數很多:Branch by Team
  • 開放原始碼專案:Branch by Feature
  • 需要經常實施持續整合:Develop on Mainline或Branch by Team

***

友藏內心獨白:看完這四個模式,心中的疑惑又少了一個。

2012年6月27日 星期三

當Branch遇到持續整合(3):Branch by Feature

June 25 16:17~17:50

螢幕快照 2012-06-25 下午4.11.40

 

這一集為各位介紹Branch by Feature(依功能而分支)這個模式。這個模式的目的很簡單,就是希望trunk上面的程式碼永遠保持著可以被釋出的品質。為了達到這個目的,開發人員就必須要:

  • 開發任何一個新功能的時候,就必須產生一個新的branch。假設鄉民們採用Scrum,在這個sprint裡面有五個story要完成。當開發人員要開始針對某一個story開始施工的時候,就必須先產生一個branch,然後在這個branch上面做開發
  • Branch上的程式必須被驗證後才可merge到trunk中。當開發人員在branch上面完成某一個功能之後,該功能必須要先通過測試人員的驗證,之後才可以merge到trunk中

Branch by Feature的概念就這麼簡單。但是要運作的好,還有幾件事情要留意的:

  • Trunk上面的異動每天必須要被merge到每一個branch中:看到這一點鄉民們可能覺得怪怪的,不是說所有的開發活動都必須在branch上面進行嗎,那為什麼trunk上面還會有程式異動需要merge到branch中呢?有,當某一個branch開發完成且merge回trunk之後,此時trunk的異動便需要merge回其他branch之中。以上圖為例,專案一開始同時間有Story 1與Story 2這兩個branch。當Story 1開發完成並且merge回trunk之後,trunk上的程式碼便需要儘快merge到Story 2 中。這個要求鄉民們應該已經清楚了,但是為什麼呢?每個story所代表的branch不是各自獨立開發嗎,那為什麼某個branch送交回trunk的結果要儘快merge到其他尚在開發中的branch呢?答案很簡單,為了避免之後其他branch送交回trunk造成broken build
  • Branch不可以活太久:如果開發團隊採用為期兩周的Scrum,每一個branch的生命週期才能才幾天而已。也就是說幾天之內就必須要完成一個story。如果一個branch活太久,例如超過一個月,就代表某個功能橫跨了兩個sprint才完成。這通常是story太大,必須要再細分的跡象。此外,branch活得太長,表示某項功能要很久之後才會被整合一次(假設持續整合系統只針對trunk上的程式進行整合)。當然看到這邊鄉民們可能會說,為什麼不幫每一個branch在持續整合系統上都設定一個建構專案?因為branch的生命週期很短,如果持續整合系統要針對每一個開發功能的branch都設定一個「短命專案」,那麼持續整合的工作量將會大大的增加,不見得每一個團隊都願意如此做。
  • 最大同時進行開發活動的branch數量不可大於每一個開發週期預計完成的story數量:簡單的說,同時進行開發的branch數量不可大於團隊所約定的最大WIP(Work in Progress)的數量,否則將會產生一大堆開發中但是都沒有被做完的工作,也就是Teddy經常說的半成品
  • Refactorying要小心:如果開發人員產生branch的目的是為了refactoring,那麼refactoring的結果要盡早merge回trunk,以避免產生merge衝突。
  • 配置守門員:如果可能的話,每次merge回trunk的程式碼都需要經過專案技術經理或是technical lead的檢視與批准。

***

基本上對於Branch的使用可以分成兩大類,第一類是覺得merge很麻煩,所以儘量不使用branch,這就造成了主要開發工作都在trunk上的Develop on Mainline。另一類可以看成有「潔癖」,認為trunk上的程式碼必須隨時保持可釋出的狀態。所以,所有的開發活動都必須要在branch上進行。近年來很流行的分散式版本控制系統(distributed version control system),像是Git,用branch的頻率簡直就跟喝開水一樣,非常適合用來支援Branch by Feature模式。

***

Branch by Feature讓trunk維持隨時都可以釋出的狀態,所有的開發都在branch上面進行,開發人員可以毫無後顧之憂地修改程式碼而不用怕一不小心就弄壞了trunk。看起來很棒,也很酷(不曉得為什麼使用很多branch的開發團隊感覺起來就比較酷一點XD)。但是從持續整合的角度來看,Branch by Feature是比較不好的一種方法。為什麼?原因Teddy剛剛已經說過了,什麼,沒看到…哇哩勒!請再看一次:

Branch如果活得太長,表示某項功能要很久之後才會被整合一次(假設持續整合系統只針對trunk上的程式進行整合)。那為什麼不幫每一個branch在持續整合系統上都設定一個建構專案?因為branch的生命週期很短,如果持續整合系統要針對每一個開發功能的branch都設定一個「短命專案」,那麼持續整合的工作量將會大大的增加,不見得每一個團隊都願意如此做。

看到這邊鄉民們應該只剩下最後一個疑問:哪種專案適合採用Branch by Feature?

Branch by Feature很適合使用於開放原始碼開發專案,此類專案的開發人員通常散布於全世界各地,而且不是任何阿貓阿狗都可以直接把程式碼貢獻到trunk中。通常開放原始碼專案會有一個人或是一個小團隊,負責審核「義工」所貢獻進來的程式碼(可能以patch的方式遞交給專案負責人),通過審核之後才會進到專案的trunk之中。而這些「義工」在開發某項功能,或是解決某個bug的時候,可以先在自己的本地端產生一份專案的branch,然後在此branch上面開發。

除了開放原始碼專案外,有些採用Kanban(看板)系統的團隊也會使用Branch by Feature。由於Kanban沒有像Scrum有開發週期(sprint)的概念,採行Kanban系統的團隊,可以更有彈性的決定釋出軟體的時間(這一點跟開放原始碼專案還挺像的)。因此保持trunk上的程式碼隨時都處於可釋出的狀態就顯得非常重要。在Scrum中,只要sprint結束時有一個潛在可釋出的軟體便可。從這個角度來看,採行Scrum的團隊並不需要嚴格要求「trunk上的程式碼隨時隨地都處於可釋出狀態」。換句話說,如果是小型的Scrum團隊,採用Develop on Mainline就挺合適的。什麼,你問那大型的Scrum團隊要採用哪種模式?等下一集你就知道了。

等一下,故事還沒結束。看了上一段不要以為採用Kanban的團隊就一定要使用Branch by Feature。根據Teddy讀了《Continuous Delivery》的感覺,除了使用在開放原始碼專案外,這本書的作者似乎不是很欣賞Branch by Feature這種模式,因為採用這種模式和持續整合的精神有所衝突。至於要不採用這種模式,就請鄉民們自行判斷一下吧。

***

友藏內心獨白:不是每種branch模式都是對持續整合很友善滴。

2012年6月26日 星期二

當Branch遇到持續整合(2):Branch for Release

June 25 14:29~15:17

螢幕快照 2012-06-25 下午1.43.37

 

今天要介紹跟「Develop on Mainline」經常一起搭配使用的Branch for Release(為了釋出而分支)。如果鄉民們有看前一集的介紹並且瞭解了Develop on Mainline模式,哪麼Branch for Release就很簡單了。以下是這個模式的特點:

  • 功能都是在trunk上開發,也就是說Branch for Release必須要跟Develop on Mainline搭配使用。在這邊Teddy先偷跑說明一下,Branch for Release是可以跟其他三個模式(Develop on Mainline、Branch by Feature、Branch by Team)一起搭配使用。
  • 當trunk上面的程式碼功能已經完整到可以釋出的時候,而且鄉民們還要繼續開發新的功能就為這次的釋出產生一個branch。產品釋出後還需要持續開發新功能這一點很重要,如果產品功能到達可以釋出的階段,但是鄉民們並沒有打算為此產品繼續開發新的功能,那麼就不一定需要為此次的釋出而產生一個branch,直接釋出trunk上的版本即可。
  • 當產品釋出之後,針對每一個釋出版本所做的bug fix直接送交到該版本的branch中,確認這些修正沒有問題之後在merge回trunk。以上圖為例,1.0.x版的bugfix會先merge回trunk中,然後在merge到1.1.x版中。由此圖可看出來,每個版本的bugfix要先merge回trunk,然後再判斷是否要進一步merge到其他各個release的branch。如果一個軟體釋出的版本越多,這種merge的時機點越需要小心謹慎,以免發生沒merge沒事,一merge之後整個軟體反而無法建構的問題(Teddy內心獨白:難道這就是傳說的中越補越大洞的靈異現象?!)。
  • 最後一點,也是與持續整合最相關的一點,原本trunk上的專案在持續整合系統上一定會有一個相對應的專案這一點鄉民們應該都了解了。一旦為了釋出而產生一個branch之後,鄉民們也要幫這個釋出版本在持續整合系統上新增一個專案,這樣日後才有「人」可以幫這個釋出版本所做的修改或是bugfix做整合與建構的工作。如上圖所示,版本控制系統中有一個trunk和兩個釋出(Release 1.0.x與Release 1.1.x),而持續整合系統上也有三個專案,分別用來建構trunk、Release 1.0.x與Release 1.1.x。

***

就這樣,Branch for Release可以算是一個「輔助模式」,因為它跟軟體的主要開發活動無關,而是用來保持不同釋出軟體版本之用。最後一個送分題:何種開發情境適合Branch for Release?如果鄉民們看到這邊還不知道就要打屁股了,答案很簡單,就是軟體要釋出的時候…XD。

***

友藏內心獨白:最後一句難道就是傳說中的廢話?!

2012年6月25日 星期一

當Branch遇到持續整合(1):Develop on Mainline

June 25 10:49~12:33

螢幕快照 2012-06-25 上午10.58.27

 

上週Teddy提到最近讀了《Continuous Delivery》這本書,書中介紹了四種很有用的「分支/合併模式」(branch/merge pattern),並且討論這四種pattern與持續整合之間的關係。接下來就分幾天把這四個pattern介紹一下,哪四個?

  1. 在主幹上開發(Develop on Mainline)
  2. 為了釋出而分支(Branch for Release)
  3. 依功能而分支(Branch by Feature)
  4. 依團隊而分支(Branch by Team)

Develop on Mainline

第一種模式叫做「在主幹上開發」,顧名思義就是說:開發人員主要的開發活動都在主幹上進行,沒事不要使用分支(插花說明一下,這裡的主幹指的是版本控制系統,像是CVS或SVN上面的Trunk,又稱作Mainline)。這種方法聽起來有點怪怪的,很多介紹版本控制系統的書不是都鼓勵開發人員要使用分支,為什麼這個模式反而建議大家沒事不要使用分支?

要回答這個問題之前,要先說明一下版本控制系統的使用情境,基本上可以從兩個角度來探討:

  • 程式開發:從程式開發的角度來看版本控制系統,為了避免提交到trunk裡面的程式碼有問題,導致軟體專案無法成功建構,產生所謂的broken build,因此有些實務做法會建議開發人員頻繁地使用分支(branch)功能。這種想法的出發點是:開發人員在分支上開發新的功能,一旦新的功能通過測試確定都沒有問題之後,才可以把分支中的程式合併(merge)回trunk,這樣子便可常保trunk上的軟體永遠都保持在可以隨時釋出的狀態。聽起來很好,但是頻繁使用branch有兩個主要的缺點:
    • 版本控制系統中的專案結構變得比較複雜,因此增加merge的成本。
    • 降低持續整合系統的功效。開發人員可能花費好幾天的時間在branch上開發程式,之後才把完成的程式merge回trunk,此時才會觸發持續整合系統執行一次建構。換句話說,持續整合系統就變得不是那麼的「持續」了(好幾天才建構一次,就不能說自己有在實施持續整合了)。
  • 持續整合:為了建構,每一個存在於持續整合系統中的專案上都必須要指定一個版本控制系統來源位置(code repository)。因此,從持續整合的角度來看版本控制系統,如果所有的開發活動都在trunk上進行,那麼持續整合系統中便只需要指定到trunk便可建構一個專案。假設有一個專案同時在trunk與branch上開發,而團隊又想要實施持續整合,那麼至少需要在持續整合系統上為此專案設定兩個持續整合專案。

看完上面的分析之後,鄉民們應該知道Develop on Mainline這個模式的用意了。開發團隊如果要採用這個模式,需要搭配幾點配合措施方可成功:

  • 頻繁地簽入(check-in or commit)程式碼到版本控制系統中:每次有程式碼被簽入至版本控制系統中便會驅動持續整合系統執行一次建構。因此,如果開發團隊採用Develop on Mainline,便需要經常性地將手邊的程式碼送交到版本控制系統中,否則就無法達到持續整合的目的。至於何謂「頻繁」?理想上完成一小段程式碼,例如寫完一個method與該method的單元測試便可送交程式碼。如果一開始無法做到這麼極端,最低限度一天至少也要送交一次(通常是下班前)。
  • 允許trunk上存在短暫的broken build:由於開發人員直接將程式碼送交到trunk上,因此難免有時候送交進去的程式碼可能會造成建構失敗,此時trunk裡面的程式碼就是「不健康的程式碼」。如果有其他開發人員在這個時候不小心checkout或是update了trunk上的程式碼,那麼這位倒楣的開發人員就拿到一套有問題的程式碼。如果該開發人員沒有注意到這個問題繼續開發程式,最糟的情況可能導致做白工,或是要花很多時間才可以把自己個程式碼merge回trunk。看到這邊鄉民們一定會想:「這樣不是很危險?」是啊,當發生broken build而沒有人發現是一件很危險的事。Develop on Mainline這個模式的出發點是:由於開發人員非常頻繁地送交程式碼,所以專案也會非常頻繁地被建構與整合。如果送交的程式碼不幸引起broken build,至少能夠被持續整合系統給發現,這也正是實施持續整合的目的:早期發現,早期治療。只要團隊成員可以清楚地從持續整合系統中知道目前專案的健康狀態,那麼短暫的broken build也就沒有那麼的可怕。
  • 指派專人關照專案健康狀態:有時候造成broken build的原因不明,或是開發人員沒有意識至自己送交的程式碼已經造成了broken build。長此以往如果都沒有人負責去關注broken build發生的原因並追蹤修復的進度,則持續整合的效果有做等於沒做一樣。因此,團隊需要指派專人來關注是否有broken build發生。此人不是要負責去修復broken build,而是要通知團隊目前發生了broken build,並找到或是協調相關開發人員立即在最短的時間內修復broken build。

***

看到這這邊鄉民們可能會問:難道Develop on Mainline就完全不能用branch嗎?也不是說不能用,只是說「沒事不要用」。好,沒事不要用,那什麼才叫做有事可以用哩?

  • 釋出軟體的時候:這一點等Teddy寫到Branch for Release之後再見分曉。
  • 做實驗的時候:有時候鄉民們想要對專案做一些實驗,例如換掉某個元件,或是嘗試一些新的功能,但是又怕實驗風險太大而把trunk搞亂了。此時便可產生一個branch然後在branch上做實驗。

在Develop on Mainline的情境下所產生的branch有一特點,就是基本上branch是不會被merge回trunk的,這樣才符合「所有的開發活動都在trunk進行」的宗旨。

***

最後還有一點要補充的,開發什麼樣的專案適合採用Develop on Mainline呢?答案很簡單:

  • 所開發的軟體還沒有釋出之前。
  • 如果同一時間提供給客戶的軟體版本只會有一個,那麼就很適合使用。例如,公司內部的資訊管理系統,或是網站系統。
  • 團隊人數不是很多的時候,例如9人以內。

***

友藏內心獨白:開車要走大馬路,不要走小徑。

2012年6月24日 星期日

2010冬遊日本關西Day6-B鴨川與午餐

June 22 17:15~17:45

走出京都植物園之後,沒想到旁邊就是「鴨川」。這個鴨川在「萬城目學」的小說《鴨川荷爾摩》中出現了好幾次,比Teddy想像中要寬了很多。鴨川的水質看起來非常清澈,是個散步的好地方。

02

01

04

03

05

06

離開了鴨川來到了某條種滿銀杏的馬路上,看起來有一些商店可以吃午飯。

07

 

甚麼,大馬路旁居然有一塊看起來是建築用地的空地被拿來種菜,好特別。

13

 

選來選去選了這一家甚麼屋的…XD。

08

 

老闆看起來很殺。

09

 

Teddy點了生魚片蓋飯,哇哩勒,這個生魚片蓋飯還真是好吃啊。

10

11

 

Kay點了類似魚下巴的東西,味道也不錯。

12

 

午飯吃了50分鐘,休息的差不多了,下一站要到這附近的京都府立陶板名畫庭。下集待續。

***

友藏內心獨白:怎麼辦,如果以後再也吃不到這麼好吃的生魚片蓋飯了啊。