其他

軟體的發布或部署過程必須是可重複且可靠的。這就引出了下一條…所有操作的自動化！我很難相信“手工操作是可重複且可靠的”這種說法。所以一定要將所有重複性的操作變成自動化的，從而變得可靠。如果某件事情做起來很困難或者讓你覺得很痛苦，那麼就儘早且儘可能頻繁地去做。乍一看上去，這麼做太蠢了，因為人的直覺反應是：應該延遲這件事。然而，實際上，這句話是說：如果做某件事很痛苦，一旦要求自己更頻繁地做，你就會有動力想出各種辦法，來解決這個痛苦，很可能把它變成了自動化的，最終會把它變成一件簡單容易的事情。就拿更新資

SEPG and SQA are two functions in organization that go hand in hand and see that the process is defined and implemented in the organization. SEPG, Software engineer process group:- Delivery directors/ Managers, Project Managers/Leads, SQA Manager,

最近，在google group的Agile

Mingle是一款敏捷式軟體開發 (Agile Software Development)管理工具，它即將發布就的版本。該版本中增加了很多新特性，當然，最主要的功能就是Card Trees啦。你可以在各種各樣的卡片之間建立父子關係，這些關係通過樹型結構可以展示出項目的複雜度。為了不同的目的，或針對不同的團隊角色，你能夠構建不同的樹。專案經理可能希望有一個計劃樹，用來做WBS 分解（work breakdown structure），而商務分析師想要用Story

作為InfoQ的《持續整合》專欄作者，剛剛發表了第三篇文章《分支策略》。有位童鞋問了這樣一個問題：我現在的團隊也面臨這樣的問題，更糟糕的是我們還沒有測試套件。目前只是面臨企業內網，馬上也面臨外網的應用了。痛苦。。。那個大俠給個好建議！ 其實，文章中已經給出了答案，即一直保持“主幹開發為主的短周期分支策略”。當然，很多團隊無法達到這種境界。原因可能非常簡單。比如，無法拒絕客戶要求，否則就有可能失去重要客戶。開發時的代碼品質太差，當需要發布時，在分支上修複Bug的時間需要很長。在主幹上開發新功能時不

不能持續學習的團隊，會出現下面的一些癥狀：·     疲勞（持續在緊張的節奏下工作）導致士氣低落。·     在一個迭代周期中，反覆地出現無法達到 “完成狀態”的現象。·     承諾的任務總是無法完成（有些特性或任務甚至還沒開始）。·     已經部署的軟體不斷地有缺陷暴露出來，導致開發計劃流產。·     減少或者取消回顧會議（“因為從來沒有真地解決過發現的問題”）。

在過去多年的持續整合諮詢經曆中，最常聽到的一個問題是：如何來評估企業在配置與發行管理方面做得到底怎麼樣？還需要在哪些地方進行改進或提高？兩年前，CITCON的幾個參與者給出了一個成熟度等級模型，主要關注於“持續整合實踐”，而在《持續傳遞》一書中，Jez與Farley也結合ThoughtWorks在這方面的實踐經驗，總結了“配置與發行管理成熟度等級模型”，並在多重專案中進行了實際應用，效果不錯。由於這是通用模型，所以各等級中多為定性描述，在拿到具體企業使用時，可以根據實際情況，對其中一些定性描述進

1. Your Single Path to Production:From Point-and-Click Package Promotion to Integrity Assurance to Package Deployment and Redeployment to History and Traceability, you will find that once you use a BRM you won't know how you survived without it. In

Cruise是Thoughtworks即將發布的又一款產品，其適用領域為持續整合，是新一代的持續整合＆發行管理系統。具有以下特性：零配置的構建網格——安裝Agent後，它們會自行更新和擷取配置，然後自動檢出所需構建的原始碼進行構建。 集中管理工件——將應用軟體包、測試結果和記錄檔集中存放，你可以在同一處得到你所需要的資訊和資料。端到端的安全性——Cruise支援LADP和活動目錄，Agent與Server之間的通訊基於SSL和公開金鑰技術，而且Agent都需要批准才能加入到構建網格。

假設閱讀本文的同學已經使用過Mingle，Mingle是一個專案管理工具，生來就可能很好地為敏捷服務，而且馬上就有新版本發布。——————————————————————————————————————————用Mingle半年多，為Card增加了很多屬性，今天想作個圖表，看看Story增加到開發範圍內的趨勢是什麼樣。卻發現只有In

持續整合是敏捷最佳實務之一，但並不是只有使用敏捷方法的團隊才能夠採納。但如果你能夠採納敏捷方法，那麼它會發揮更大的作用。“什麼是持續整合”在前面的文章中已談過了，這裡只把其中的一部分：持續整合的六個基本自動化再細說一下。這六個基本自動化是：自動運行測試、自動產生可部署的二進位檔案，把它部署到類似生產環境中，自動標識你的代碼基準，自動運行迴歸測試以及自動產生度量。一、運行測試

軟體開發中，“配置開關”根本算不上是一個“新”概念。無論是通過啟動時載入配置，還是應用程式運行時動態重新整理配置，都可以用來決定或改變應用程式的某種具體行為。比如：通過設定檔，使用應用程式串連不同的資料庫通過模板配置，達到應用程式“換膚”的目的通過系統管理員的配置，使不同的使用者具有不同的許可權所有這些“開關”都被認為是理所當然的，因為使用者的需求就是這樣的，“我需要通過xx開關來控制yy”。因此，做為交付團隊，也會老老實實地把這些需求實現了。然而，現在的很多團隊，為了能夠儘早發布軟體，使用主幹

CMMI 是一種已被很多IT公司廣泛採納的過程架構，而Agile是一種逐漸流行起來的軟體開發方法。

繼九個月前的首次發布，思特沃克公司（Thoughtworks）本月中旬發布Mingle 2.0。在此版本諸多修改和新功能中，最引人矚目的是：卡片樹 —— Mingle現在使用卡片樹的概念來展現特性、故事片、缺陷以及系統中你所定義的任何實體。它還能用不同的方式來展現樹，例如計劃視圖（Planning view）或開發人員視圖（Developers view）。全方位的報表（Cross-project reporting）

如果你的Team Dev正在使用敏捷開發方法，而客戶並不在意什麼開發方法，他們只想儘快地拿到他們需要的軟體。作為專案經理，你該怎麼辦呢？如果客戶不知道敏捷開發方法，那麼向他介紹敏捷開發方法是專案經理應該做的一件事，但是要適可而止。因為能用的軟體才是他們想要的，在沒有深刻體會到它帶來的益處時，你是無法用嘴皮子來證明的。但並不能這麼就算了，因為還要保持Team

持續傳遞成熟度等級模型更新，新版本v1.2發布《持續傳遞》一書中提供的“持續傳遞成熟度等級模型”是1.0版本。這是經過再次調整的改進版，更具有指導性和可操作性。使用說明：建議使用該模型進行現狀分析，發現改進點，不建議將其作為績效衡量的標準。共有七個維度，它們分別是：1. 持續整合（Continuous Integration)2. 環境與部署（Environments and Deployments）3. 可視化與可追蹤性（Visibility and Traceability）4.

回顧會議的目的：（1）創造一個安全的團隊環境；（2）建立信任和參加感；（3）對成功的欣賞；（4）為改進提供一個架構；（5）情緒宣洩；（6）直面問題；（7）自我建立團隊“規則”：建立並改進團隊流程。看看你做了哪些？經常被忽略的可能是(1),(2), (3),不會被忘記的是(4)，因為會上總要說一說“什麼做得好”和“什麼做得不好”。常見的錯誤用法是(7)，因為常常變成專案管理人員主動制定規則。不常看到的是(5)，因為普遍認為相對西方人來說，東方人都是內斂的。理解經常產生差異的是(6)，因為每個人對“

目前，持續整合工具多達30種，每種工具都有自己的特點。在國內，軟體企業很少為這類產品付費，所以國個目前最流行的包括Hudson（開源），CruiseControl（開源），TeamCity（商業版，買了IntellJ的License就能免費使用）。而在國外，還有兩個比較流行的商業軟體是AnthillPro和Go（原名為Cruise）。根據目前軟體發展的特點，在選擇持續整合工具時需要考慮對版本控制工具、構建工具、測試載入器等的支援。而對於企業級使用者和複雜軟體來說，需要考慮的因素更多。詳見http

現在，伺服器叢集已經是司空見慣的事情了。隨便一個小的互連網應用程式都需要用叢集來支撐。而當採納“持續整合”，尤其是“持續傳遞”實踐時，在各種環境上的部署讓你發瘋。這些環境包括開發環境、測試環境（包括功能測試和非功能測試）、試運行環境和生產環境。而且，每種環境可能會有多套執行個體，而不只是一套執行個體。曾經接觸過的一個團隊，其持續整合環境中就有260+台伺服器，隨著開發人員的提交，不同版本的應用程式在這些伺服器上一遍又一遍地被部署、測試、卸載。而且，這些伺服器的作用各不相同，有的是web伺服器，有

 多年來，“用度量資料與進階管理層溝通”一直被敏捷社區所排斥，而“害怕資料”並不是問題所在。正確的做法是：對成本、煩惱、風險以及XP的回報的絕對公開化。它處在主導地位，而且能夠生效。恐怕再繼續講述有趣的故事會使敏捷社區成為一個純粹的技術能力討論區。 然而，只有我們所掌握的這些案例是隨機樣本時，那些數字才具有普遍意義。而這些案例不是隨機樣本，所以那些資料無法反映現實。而且，