2009年12月23日 23:20

軟體開發之建置風險的故事

「石頭閒語」已轉移到 rocksaying.tw 。 本文新網址請點擊此連結:《閱讀全文》。
軟體開發之建置風險的故事

  • shirock 發表於樂多Programming編輯本文
    樂多分類:學術/學習切換閱讀版型
    贊助商廣告
     
    引用列表:
    IBM 宣佈將把軟體開發與測試服務延伸到雲之彼端。快速導讀請看《A quick look at the IBM Smart Business Development and Test on the IBM Cloud》。 軟體開發的雲端服務,並非教我們如何設計與開發雲端服務項目。而是在雲之彼端為開發者提供軟體開發過程中所需的資源。軟體開發最基本的資源,是源碼的儲放與版本控制,還有規格文件的管理(wiki),這兩項就是源碼代管服務。例如 SourceForge, Google Code, GitH
    軟體開發,在雲一方【石頭閒語】 at 2010年3月18日 12:03
    我任職的公司,今年年初時,指派我用 CruiseControl.rb 規劃了一套每日建置系統。到目前為止,已經運作了超過半年的時間。也確實解決了許多潛在的軟體開發風險,例如 簡化專案交接風險。 不過隨著人員更迭,我時常要對新進員工灌輸每日建置系統的用處。本文就是我每次都會對新進人員說一遍的內容。 每日建置系統並不是什麼特殊的工具。就概念上來說,它只是把我們的專案建置動作,定期自動執行,並把結果記錄下來而已。它並不具備讓我們一建好每日建置系統後,就會自動解決所有問題的特殊魔力。
    淺談每日建置、BVTs之目的【石頭閒語】 at 2010年11月7日 02:10
    大約是一月時的事,我看到消息說「GitHub已將持續整合服務器Janky開源」。然後,我就在公司的郵件群組中發了封信,說我可能會評估一下 Janky 這套持續整合工具。同事在跟帖中說,這樣會不會分心,是不是應該等目前的專案都結束了再做? 同事的說法,反應出他們尚未確實理解「持續整合」的意義。我相信大部份開發團隊初次接觸「持續整合」時,都會有相同的誤解。我在郵件與 twitter 上表達了我的看法。
    持續整合與跑步呼吸【石頭閒語】 at 2012年2月6日 16:05
    回應文章
    學到不少,多謝分享。
    | 檢舉 | Posted by fcamel at 2010年1月8日 20:18
    這是非常好的經驗分享
    | 檢舉 | Posted by martin at 2010年11月10日 10:44