今天在 Agile Taichung 分享自己學習 Continuous Delivery 的心得
聚會的投影片如下:
另外，我覺得直接聽大師講最快，我的投影片主要都是參考 Jez Humble 跟 Martin Flower 大師們的 Talk內容。下面兩個 youtube，是我覺得講 CD 講的很清楚
Martin Fowler 在 XCONF 談 Continuous Delivery
Jez Humble 在 Spark 2013 談 Continuous Delivery
最後則是用一張圖視覺化所有 CD 重要的觀念:
軟體測試在敏捷化開發一定會遇到的問題，就是原本很可能都是以“週”為單位完成的Task。如果在一個三週Sprint的情況下，測試工作很可能都要變成以“天“為單位完成的Task，我們要如何能把大部份的測試活動都在短的時間區間完成！？如同 Scrum 大師 Mike Cohn 所說的，我們需要一個健康測試金字塔。把時間投資在對的測試活動上。
金字塔有三層，由下而上分別是 Unit Test ，Acceptance Test, GUI Tests。最上面不一定大小的 Manual Tests。這邊傳達的最重要的概念就是，我們應該盡可能地把時間投資在 Unit test 上，理由很簡單，因為 Unit Test 穩定度是最高的，而且最容易被執行。如果一個測試目標能在 Unit tests level 被處理掉的話，我們應該要盡量讓它們在 Unit test level 就發生。而當測試的 Scope 愈來愈大，測試的成本就會愈來愈貴，可能會由白箱測試變黑箱測試，所需要的測試文件就需要更多來傳達資訊。
很可惜地，大部份的測試團隊，剛好相反。投入了大量人力在 Manual tests 之上。也因為有大量的 Tester 在執行 GUI Test、Manual Test 所以 Developer 在相對少的資源下，就只能把大部份可以在 unit test level 就處理掉的任務直接讓給 tester 來完成。
Patrick Wilson-Welsh 把這個金字塔比喻成三隻小豬的故事。有做過 GUI test 的人應該都知道，我們應該最後才做 GUI test，因為他最 brittle，最容易因為一點點的改變而讓測試不通過。所以 Patrick …
看了GTAC 2011 Opening Keynote: Test is dead時注意到這本書。查了一下，發現Amazon的高評價，就馬上買了Kindle版(0.99 Usd)來看。裡面有一些不錯的觀念，在現今軟體業 Startup 風氣盛行的年代，我想值得記錄一下。
Pretotype 不是 Prototype 的筆誤。這個字是作者 Alberto Savoia 自創的單字。從 Prototype 衍生而來。pre 跟 pro 都有 earier, before 的意思。一般傳統上，我們常常為了證明一些點子是否可行，都會先用少量的成本投入，來測試看看是否值得再繼續投入下去，比如說原型(Prototype)，或是POC(Prove of Concept)都是典型的例子。但是Alberto覺得Prototype還是太貴了。能否有一些更快速，省成本的方法來驗證我們做的是對的它。因為找對的它來做是非常重要的，一些常見的統計數據告訴我們：
所以，愈早知道是否是對的“它”，遠比把“它”做對來得重要的多。
絕大多數的新物事都將會失敗， 即使被完美無瑕地執行
所以，我們常常在做一些不對的事情而不自知。當然，這邊所謂的對或是不對，其實定義可以很簡單，就是指目標市場的接受度。但是如果市場不買帳，就算他做的很完美，終究會走向失敗之路。Pretotype 是一種讓我們可以少痛一點的方式，即早發見這其實是不對的。而不是花了大把銀子跟青春才發現這不是市場要的。Pretotype 是指一種介於抽象概念(Abstract concept)跟原型(Prototype …
CentOS預設的JAVA版本和Jenkins不相容，所以要改安裝 OpenJDK 。可以用 yum search 檢查應該安裝那一個版本: yum search openjdk 會有 java-1.6.0 跟 java-1.7.0 兩個版本可供安裝，在此我選擇比較新的版本：1.7.0： yum install java-1.7.0-openjdk -y
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins -y
修改 iptables : 打開 80 Port，編輯/etc/sysconfig/iptables，把下面的rule加到最後一條
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
讓 Jenkins 開機自動啟動 chkconfig Jenkins …
這套方法是記錄在《How Google Tests Software》 一書之中，我覺得蠻不錯的，分享一下︰
Attributes-Components-Capabilities(ACC) 是Google團隊使用的測試建模的方法，可以視為快速譔寫 Test Plan 的一種方式。據 Jame Whittaker 的講法，一份ACC的完成時間約為 10~30 分鐘，如果達不到，代表自己對於要測的系統不夠了解。
目前 Google 己經把這個方法實現在 Google Test Analytics (GTA) 這套系統之上，更棒的是 GTA 目前己經 Open Source 出來了，而且有一個公開的沙箱網站，任何人都可以上去快速體驗一下ACC的魅力。
ACC主要的內容就是依照產品的 Attribute(特性), Component(元件), Capability (能力) 的三者，分別依照順序，一步一步來分析我們到底要測什麼，該測什麼，什麼要先測等等問題。下面分別介紹ACC三者的意義︰
Attributes: 產品的特色，是產品的形容詞。例如︰快，安全，穩定，好用。這個清單說明為什麼顧客要用我們的產品，而不是其它的競爭者的。
Components: 產品的元件，是產品的名詞。例如︰資料庫，通知系統，使用者..等等。這個清單列舉出整個系統中的元件，約10個左右為宜。
Capability: 產品的功能，是產品的動詞。例如︰分享照片給朋友，新增好友，收到朋友訊息通知。
關於 Attribute 跟 Componet，這邊書中是舉Google+為例︰
這本書的作者是在軟體測試界很有名的 James Whittaker，以 How to break xxx 系列跟 Exploratory Testing 聞名。這本是他在Google期間完成的著作。可惜他己經在2012年３月左右離開了Google，發表了一篇Why I left google/中文翻譯。從微軟到Google，最後又回鍋到微軟了。文中大體的原因就是Google把創新精神丟掉，而只專注在廣告上，不再是一家是以技術優先導向的公司。但是這些還是毫不影響Google在軟體界的王者地位。
Google跟微軟在軟體測試上的策略很不一樣。傳統上，微軟的開發與測試人員比例大概是１：１左右。小弟的公司也是如此。但是Google專職在測試的人員，就明顯少得很多。我想從本書找到，如果專職測試人員少的話，那麼整個軟體開發流程會變的如何？其實，微軟在2008年也有出一本拿自己公司名稱當招牌的測試書 How We Test Software at Microsoft，這本有點厚，之後找個機會來看。以目前軟體公司的發展看來，也許之後就會看到一本以 Facebook 為主角的測試書了。
在 Google，測試工作是由一個中央的組職稱為 Engineering Productivity 來負責。包含 Developer 跟 Tester tool chain, Release engineer 。從 Unit test 包到 Exploratory testing。
Google 在2001年時，約有200位開發工程師，但是只有3位測試工程師，那時開發工程師就必需為自己寫的程試的品質負責。那時TDD跟JUnit才準備流行，所以測試主要以 ad-hoc 為主。
James 常給人的忠告︰「不要顧用太多測試員工」，Larry Page︰「Scarcity brings clarity (意指︰在缺乏資源的情況時，會有清楚的目標；銀彈不足，才會想辦法彈無虛發 …
Trello，是一個小團隊任務管理的工具。關於Trello的使用方法，這此就不再多言了，Google一下都可以找到不少介紹，這篇主要是想記錄一下，我親身使用Trello之後觀察到的一些小心得。
我能在一個畫面就知道目前Project的最新狀態，相較於使用Email溝通，我能比較自由的方式去更新我目前的狀態，也不用太擔心訊息是否會干擾其它成員。
工作的指派可不可以自己決定？在Trello中，我們會希望答案是Yes。傳統工作模式中，可能就是每週一次的指派任務、回報進度。大家都是各做各的。等到一個星期之後，再彼此更新自己的Status。但是在Trello中，我們可以在"一個畫面"就可以知道目前團隊成員正在做什麼，還沒完成什麼。所以當我完成手頭的工作，尋找下一個工作，也許就可以是別人還沒完成的工作。整個氣氛就會變成整個團隊努力把ToDo List中的工作一步一步搬到 Done List中。
在使用Trello中，每一張Card的描述應該要被常常更新。如果這個Card任務太大，那我們就應該適時的把它拆解成幾個比較小的Card。當一個人Own了一個Task，好幾天都不動的時侯，我們就會應該讓它活絡一下。使用Trello的一個大好處就是我可以很容易感受到每一天的小小進步，這樣工作會比較有趣。
我發現團隊不少人都己經常態使用Trello，甚至是自己私人的規劃，像是出國玩，搬家等等。可見Trello系統的魅力。
Trello : https://trello.com/
看公司某些Team在實行 Scrum，別的不敢說，學得最像的一定是這種上面貼滿，地下也掉滿的便利貼 Task board：
Trello就是類似這種清單系統的線上網站。我覺得 Trello 令人驚奇的點就是他可以讓團隊的每一個人可以專注在自己的任務上，也可以同時知道團隊其它人的狀態。Trello UI設計的很簡單，使用上很流暢。讓我一用就決定在日常工作試用看看，並且也說服我的同事們一起使用。
Task Board 適用在短時間的任務清單管理上。因為在每一個Scrum中，團隊的任務就是把最左邊的Task努力搬到最右邊，彼此可以互相幫助。如果每個Task分的很細的話，上面也放不了多少Task。所以當達到 MileStone的時侯，就需要適時的 Reset，喘口氣，可以繼續衝下個回合。