If you are a developer, you might have heard from your manager every once in a while “the release you deployed last night had several major issues, please roll-back to previous version”. If you are a tester, you might have heard “how can there be such major issues when we spent so much time in testing before moving the site to live?”. If you are project manager, you might have heard your client say, “It was very embarrassing situation for me when I was giving demo and application had so many major problems. I am disappointed!”. Being manager, you may have heard your CEO say, “we need to be careful with estimation next time since the project exceeded it’s budget big time!”. Such phrases are not very unusual in software industry specially the small-medium size companies and working offshore using agile methodology. You hear such phrases and you feel like banging your head against wall asking yourself just one question WHAT WENT WRONG!!!!
The answer mostly is very simple in all such scenarios and that is lack of “CONFIGURATION MANAGEMENT”!!! Wikipedia simply defines it as: “the task of tracking and controlling changes in the software”. These changes are not limited to code and database but also to documents like requirement documents, design documents, meeting of minutes, project schedule, project size, test plan document, test cases etc. Those of you who are unaware of the term may still be wondering “What configuration management has to do with the issues described above?”. Let me list the main reasons of the scenarios described above:-
- the developer machine’s configurations are different from live server
- the configuration file may not be updated as per live server
- the database scripts haven’t been executed on the live server
- the required lookup data wasn’t there on live server
- there may be some external components like Google Maps, Facebook Connect, Quickbook which require URL. That URL is still pointing to developer’s machine
- old code is updated on the server
- the last release was tested without updating test plan/test cases
- there were some changes in requirements/design which weren’t taken into consideration properly
- project scope changed but the estimate isn’t revised and tracked properly
- there were some notes communicated by client in his last meeting which were pre-requisites of the deployment and those notes never caught the eye of the developer/configuration manager
- and so on…
Ah! Now you see the problem, what’s the solution??? I will propose a simple recipe that can facilitate companies to overcome all such issues easily.
Required Ingredients: version control system, development server, testing server, deployment guide (other resources like developer’s machine, code, database, project files etc are assumed to be implicitly present)
Software Configuration Management Process:
Step 1: Project is kicked-off and kick off email is sent to all stakeholders. A repository is created in version control system with project name and all stakeholders are assigned appropriate (read/write) permissions.
Step 2: All project files (code, db scripts, schedule, test plans) are placed in a pre-defined folder structure which is created when the repository is created.
Step 3: Developers start working on their machines (development workspace) and check-in the code in version control system on daily basis with some comments. Other stakeholders can also place their files in version control whenever they want or on some event mentioned in project schedule.
Step 4: When they have to send a release to tester, they apply a label on version control on code and database folders. For example, 0.1 (0 indicates no release to client and 1 indicates first release to tester). They send the patch details to configuration manager.
Step 5: Configuration Manager picks the patch from version control and deploy on tester’s server. Tester start testing the release and report bugs in some bug management system.
Step 6: Developers fix the bugs on the code they are working on and when they are scheduled to send the second release to tester, they apply another label. For example, 0.2. They again send the patch details to configuration manager and mark the bugs as fixed in bug management system.
Step 7: Tester verify the bugs, perform regression testing, and test new feature developed.
Step 4 though Step 7 keep repeating until a release has to be sent to client
Step 8: Developer apply another label on version control system. For instance, 1.0 (means first release to client). The patch information is sent to configuration manager which then deploy it to staging. All deployments are performed using deployment guide containing detailed information about how to carry out the deployment step-by-step.
The above process is mainly about the code and database. You can apply labels on other configuration items like test cases, requirement document, project plan etc. The main purpose of applying all these labels is to baseline the work so that if there is any change, it can be properly tracked, escalated, and addressed. A configuration management board can be formed which may include project manager, client, development team lead, and configuration manager. The purpose of this board will be to approve changes on baselined items.
I would just like to conclude this with a note that this is just a scaled-down version of standard practices for small-medium companies. There is a lot more that can be done on top of it and definitely that has it’s own advantages but there is always a cost associated with such measures. A careful and step-by-step approach may lead to the required maturity level which cost-effectively supports a more mature configuration management process.