Published on Feb 23, 2016
The configuration management is an important process in the software development life cycle. There are several functions associated with this process. Source Code maintenance, Product/Components builds, maintaining the build machines, reproducibility/traceability of builds are some of the important functionalities of the Configuration Management Process. This process is useful where the Components or the products have a huge code base and involves the project flowing across different teams.
Need for a Configuration Management System
A configuration management system is not just a system where the source code gets compiled. It is a system that keeps in track of all the changes made to project by different development teams. Apart from maintaining the source code the system keep in track of the source code based on time, thereby having traceability from the start of the project. This feature is particularly useful when the team introduces features, removes features and modifies features to the software. The configuration management system is also responsible for releasing products/components to the outside world and to other teams with in the same organization.
Configuration Management Process :
The build requestor requests the build on the WebSite. The details include the name of the product and the version.
The next step is to determine the build number. The build number is typically incremented for every build. As mentioned before the build number is required for traceability and for product release purposes.
After determining the build number, it has to be updated in the source base so that the build number is reflected in the build.
Now the latest source code of the project is downloaded on the build machine along with the latest build number
A label is created for the latest source code. This is very important because the label takes a snap shot of the source code used in that particular build.
The next step is to build and link the source code.
After building and linking the system is checked for errors. If there are errors then the requestor is notified with the status. If the build is successful then the binaries are posted into a common server where it will be made available.
The process gets complicated when there are several products requiring several builds. This whole system can be automated by using BPEL. Automating this system will make the build process more efficient and scalable; also the modules can be independently developed so that they can be imported by other systems.
The most important to consider while running the email mode through the BPEL process is to see if there is any fire walls. It is essential that the firewall be turned off before running the email module.
Another important point is to make sure the ipconfig /release command is issued before deploying the email module. The BPEL process manager will not deploy if static IP address is assigned to the machine.
Another important problem with the basic email client set up is that emails cannot be sent across domains.
A combination of firewall and static IP address assignment in the production network may prevent the email module from working. The Fig 5 is a sample error that can occur when having a fire wall running on the machine