- Configuration Management and Source Code Control
- Coordination
- Version Control
- Database Configuration Control
- Working Without Source-Code Control Software
- Larger Projects
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Working Without Source-Code Control Software
Source code control software is great for managing big projects, especially those distributed over the Internet. It's good for managing branch versions and for managing fine-grained changes. The downside is that it requires some effort to install. The popular CVS server software isn't readily available for the very common Windows operating systems, though you can always compile it yourself. (Clients for Windows are readily available, but usually end up working against a server running on Linux or some other UNIX.) Commercial source code control software costs money—sometimes a lot of it. Following are the techniques I use to coordinate a team of up to 15 programmers.
Part of the configuration manager's job is to be able to compile and test the entire system. That means keeping the One True Copy of all the source code, compilation scripts, database schemas, help files, images, etc.
Building a system consists of more than just compiling the source. You may have to rebuild help indexes, copy files into particular locations, install database schemas, etc. The more you automate this task, either through custom scripting or with tools like Ant, the more easily you can replicate the compilation process.
For Java projects, I keep my Java source files and other resource files (images, help files, resource property files, and so forth) in a single directory, with the resource files stored in subdirectories according to the package name.
During compilation, I compile the Java source files into a different directory. That directory mimics the organization of an installation. I also copy the images, help files, and so on into that directory, using a single recursive copy command. That is, in effect, "compiling" those files.
The process may even take more than one step. Sometimes, the source files generate a program used to process some of the input resources into a compiled form for more efficient access, security, etc.
Every developer should maintain a complete copy of the source tree and be able to run the compilation scripts. Not only does that mean plenty of replication in case of disaster, it means that the compilation process is well understood rather than posing a risk of being lost. It also means that, at the very least, changes submitted to configuration control will compile. (I hate it when somebody makes changes that don't compile against the source tree. How could you have tested it fully if it doesn't even compile?)
Sometimes the changes are too frequent to maintain the complete source tree. In that case, you should at least keep a copy of the interfaces to check against so that you're sure your changes will compile when they're submitted to configuration management. In C/C++, that means .h files. In Java, that means compiled binaries. You ask all the other programmers to try not to change these too often, or (in the case of Java) to make only "binary compatible" changes.