配置管理失败的可能四个方面及对策

Four familiar aspect of failure is in software configuration management procedure, such as:
l Source problem
Example 1: Bob has written a software code, Tim changes the code continually, but Bob doesn’t know this, he as well as changes the code. Finally, the code is troubled. In this situation, if the code is protected by SCM tool, it can be changed when it is checked out, every thing is in order.
Example 2: Hard drive in Bob’s computer has crashed. His code is lost. So he have to re-write these codes. If these codes are checked in SCM tool, it is never happen.
l Build problem
Example 1: Some team members work on VC6.0 environment, another team members work on VC.net environment, they find different part of code cannot work fine together. We must formulate and achieve consensus on a set of standards for developers to follow so that the executables created will run correctly on required platforms and problems can be fixed quickly.
Example 2: It is correctly when Tim tested his code that refers to Bob’s code, but in second day, Tim finds some wrong with his code, because Bob changed his code in this morning. We must provide a mechanism for developers to share their code both among themselves and with those who build and support the product, and we must centrally build the product to ensure that what has been compiled can always be re-created from source code files.
l Deployment problem
Example 1: Our software product delivery many different customer, there are small different in these software, but it is difficult to identify when maintainer maintains them. We must create unique labels for every version of the software that's built and ensure that the labels are displayed in the software itself.
Example 2: Jose thinks that a bug he previously reported is fixed; however, he can't remember the exact steps he took to find it. Unfortunately, he can't check on the previous version of the software because the directory containing it was overwritten during the new build process. We must allow the team access to previous versions of the software.
l Version problem
Example 1: We have several branches in the code, we often work on different branch, but it is difficult that get correctly branch. We must provide a mechanism that allows your developers to work on more than one product version at time while minimizing the need to make redundant changes in more than one place.
Example 2: Bob's team has another copy of the source for the previous version, but they find it tedious and extremely accident-prone to make bug fixes in both versions of the software. We must provide patches to the current product while the new version is in development.