投產服務與軟件產品的部署有關,是對項目服務特性的要求。運營企業中可能同時有多個應用系統,相互之間往往具有很高的耦合度,一項新業務的推出,往往需要多個軟件產品配合修改和同步投產。因此,從業務角度來說,一個新的業務產品的實現,需要多個軟件模塊(產品)的支持,不同投產單位中這些軟件模塊(產品)的版本配合關系不同。那么對于運行中心來說,需要面臨同時滿足業務產品和軟件產品的雙重要求,既要保證業務產品的完整性和多樣性,又要保證軟件產品的一致性和兼容性。因此,對于投產管理來說,也有同樣的配置管理的要求,是必須在企業級來考慮的。
配置管理中的版本管理和變更管理
配置管理中要記錄、控制、報告各種屬性(配置項)的變化狀態,這就是配置管理中的版本管理和變更管理,有變更才有不同的版本,版本又成為變更控制的主要對象,這兩者是緊密關聯的。
首先要澄清一下版本的概念。在配置管理中,每個配置項的每個狀態都可以稱為一個版本,配置項的演變過程就可以體現為一棵版本樹。而我們平時經常說的版本,實際是指軟件產品的版本,不是具體配置項的版本。一個軟件產品版本是由眾多配置項組成的,每個配置項最多只能選取它的一個版本組成一個特定的產品版本。因此,在我們平時談到“版本”時,需要明確是配置項的版本還是軟件產品的版本,否則容易在溝通中帶來混淆。既然版本管理是配置管理中的一項內容,那么對于在軟件產品版本管理中遇到的各種實際問題,就需要放在配置管理這個大背景中,基于配置管理的理論、方法和工具來考慮,才能逐步理清。
項目中的變更管理是大家都已經很熟悉的工作,從概念上來說,變更管理也屬于配置管理工作的一部分。在軟件開發項目中,無論是功能需求的變更、技術需求的變更還是服務需求的變更,也都可以將變更要求與配置項建立對應關系,演變成為配置項的變更,配置項在變更前后形成不同的版本,這樣就使得變更管理能夠有的放矢。如果不能將變更要求落實到具體的配置項上,項目中許多的變更控制就難以具體落實。
具體來說,在每一項開發任務中,都需要首先設定開發基線,確定各個配置項的開發初始版本,在開發過程中,開發人員基于開發基線的版本,開發出所需的目標版本。當發生需求變更時,通過對變更的評估,確定變更的影響范圍,對被影響的配置項的版本進行修改,根據變更的性質使配置項的版本樹繼續延伸或產生新的分支,形成新的目標版本,而對于不受變更影響的配置項則不應發生變動。同時,應能夠將變更所產生的對版本的影響進行記錄和跟蹤,必要時還可以回退到以前的版本,例如當開發需求或需求變更被取消時,就需要有能力將版本回退到開發基線版本。在曾經出現過的季度升級包拆包和重新組包的過程中,其實就是將部分配置項的版本回退到開發基線,將對應不同需求的不同分支重新組合歸并,形成新的升級包版本。
延伸閱讀
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/