2023年05月08日 21:37:00
剛剛過節回來，xy便找我討論配置管理計畫，我有點納悶，節前不是已經討論清楚了嗎？
老大提了個新的設想，得到了很多人的擁護，所以原來的被推翻了。xy找紙畫給我看，其實變化不是很多，只是基於現有的一些現狀，老大又做了些調整。
原來的設想是，主幹作為開發分支，存放的是新的需求變更和重大的缺陷，因而它是不穩定的，經過產品封版測試後，打出相對穩定的產品分支來，在產品分支上只做比較小的缺陷修改，針對該產品分支提出的重大的缺陷和變更將被推遲到新的主幹版本上。
現在的設想是：主幹是最新版本的產品分支（3.3)，在上面做缺陷處理，同時分出乙個新的開發分支來（3.4dev），用來放置新的需求變更和重大的缺陷，在開發分支上的新的需求和變更開發完畢後，經過測試後，將差異的部分合併到主幹上，然後標記出3.4產品版本來，同時打出新的開發分支（3.5dev）來，並找到上乙個版本（3.3）打出乙個新的產品分支來維護。
從配置管理員的角度，新的做法其實比舊的做法複雜了，並且新的做法存在一下幾個缺點和侷限。
1 由於開發分支長期不同步到主幹上，所以合併的難度增大，主幹上修改的缺陷極有可能和新的缺陷/變更發生衝突；
2 對開發分支的封版測試並不意味著新的產品版本的誕生，因而合併完畢後，還要進行更多遍的測試。
3 不太適合多個產品版本同時開發，
4 產品規劃策略應該是盡量只維護最新的產品版本和開發版本，且這兩個版本由乙個團隊來維護。
但是，當開發人員每天只面對的是乙個產品版本的缺陷，並且需求變更少於缺陷的發生頻率時，這又是比較合適的。目前的技術中心產品即是屬於這種情況，在新的方法中，開發人員不用去同步日益發生的大量的缺陷到主幹，這會讓他們感覺到一種略帶虛無的滿足。
同領域建模的理論一樣，配置計畫沒有對此之分，只有合適不合適一說。先推行之後再說吧。
配置管理計畫的新設想
2007年05月08日 21 37 00 剛剛過節回來，xy便找我討論配置管理計畫，我有點納悶，節前不是已經討論清楚了嗎？老大提了個新的設想，得到了很多人的擁護，所以原來的被推翻了。xy找紙畫給我看，其實變化不是很多，只是基於現有的一些現狀，老大又做了些調整。原來的設想是，主幹作為開發分支，存放的是...
電路 改進計畫 新設想
1 pmu adc iic等輔助電路全部用ps控制，pl全部釋放給dut。1 pmu sync sclk sdi sdo busy，務必新增sdo 2 adc sclk dout ready 3 iic scl sda，address 2 pmu告警 亮燈 beep，另外把alarm訊號隔離後引入p...
資料 配置管理
目前國內外常見的10種配置管理工具一覽 配置管理不是單純的指軟體的 版本管理,上面的資料介紹的主要是 級管理.配置管理的目的是為了準確交付，減少事故.當專案本身是由多個語言，多個部門來開發，採用了較多開源和第三方的軟體例項時，需要好的配置管理.配置管理之路 scmroad 軟體測試網 軟體測試管理 ...