與問題控制系統集成的自動化軟件版本控制

Question

在閱讀語義版本控制http://semver.org/後，我決定使用以下模式。但是，在自動化和集成SDLC工具方面，我有一些未解決的問題。

版圖樣：
major.minor.revision.build
使得;

重大：重大變化，應手動增值。
未成年人：只要在問題跟蹤系統中解決了現有功能的新功能或增強功能，就應該自動增加小的更改。
修訂版：只要在問題跟蹤系統中解決了問題，就不會影響小的更改，應該自動增加更改。

假設開發者從未提交源代碼，除非問題跟蹤系統中的問題已經解決，問題跟蹤系統在此配置中是JIRA。這意味着除了任務之外，缺省，改進和新功能都是默認的問題類型。此外，我在這個配置中添加了一個持續集成工具，並且假設它是竹子（順便說一下，我之前從未使用竹子，我使用過Hudson），並且我正在使用Eclipse IDE和mylyn插件並加上項目是一個Maven項目（網絡）。

現在，我想通過說明下面的場景來闡明我想要做的事情。分析師（A）打開一個問題（I），這是一個與maven項目（P）相關的新功能。作爲開發人員（D），我收到一封有關此問題的電子郵件，並通過Eclipse中的Mylyn界面打開任務。我理解並開發與問題（I）相關的新功能。考慮一下，我是一個面向測試驅動開發的開發人員，因此我相應編寫了Unit，DBUnit和User-Acceptance（例如使用selenium）測試。最後，我將更改提交給源代碼管理。我認爲其餘的應該自動循環，但我不知道如何能夠實現這一目標？自動循環部分如下：

源代碼管理系統應該有一個post-hook腳本來觸發連續集成工具來構建項目（P）。在構建階段，應該運行測試代碼並生成報告。用戶驗收測試應在專用服務器上執行（例如，jboss或tomcat）。這個驗收測試的順序應該是在服務器上運行UA測試，然後生成UA測試報告並下載服務器。如果所有這些步驟都已成功完成，則應執行版本控制。在版本控制部分，maven插件或以前的版本應該從問題跟蹤系統中解決問題的數量，並增加相關版本片段（次要版本和修訂版本），最後附加內部版本號。版本的片段可以保存在清單文件中以便在用戶界面中顯示。最後但並非最不重要的是，CI工具應該在測試環境中部署它。這就是我想要的所有自動循環過程。

還有一個小問題：工件在生產環境中的部署應自動或手動完成，最佳實踐是什麼？

任何幫助|建議將大大appreaciated。 非常感謝。

Answer 1

讓我們從一個側面的問題開始：在自動部署到生產上，這需要簽署「業務」，無論這是誰。您的測試需要自動推送到生產有多好？他們是否足夠好，以至於你相信事情才能上線？你的宕機時間是多少？這可以接受嗎？如果你的測試錯過了某些東西，你可以回滾嗎？你是否在監控生產，以便知道你是否引入了問題？通常，足夠的這些問題的答案是否定的，以至於不能在那裏自動部署作爲構建/自動測試事件的結果。

至於跟蹤，你需要一些東西。你需要你所有的假設都是真實的（我懷疑他們是這樣，但是如果你到達那裏真是太棒了）。您還需要一個內部版本號，可以根據測試結果在構建時間後遞增。您需要使用bug ID標註源代碼更改。您需要構建系統來解析源代碼更改並進行關聯。您需要在構建系統中使用API​​，以便獲得與構建相關的問題計數。最後，您需要自己的一些腳本來執行查詢並相應地更新構建編號。

• 這是完全可行的，但真的值得擁有嗎？您對編號方案有什麼價值？