Concurrent Development
Bookmark :
I have recently had conversations with several groups of Notes developers looking for a tool to support the way they want to work. The situation involves several developers working on the same database, making changes for various reasons. Everybody has adopted a practice to manage multiple developers in the same database, whether it is using design locking or passing the coding pencil. The problem is that they want to release selected bits of functionality without releasing other bits that may still be being tested or developed. Current practices that these teams have used include cutting and pasting individual design elements, turning on the prohibit refresh flag, and many other schemes that can cause more problems than they solve (cutting and pasting can cause replication failures of design elements, prohibit refresh can be left on inappropriately, etc.).
But consider this--how thoroughly can something be tested if you are selectively pushing design changes into production? If you test your changes and then only put some into production, how do you know that what you put into production didn't somehow rely on something you didn't move? (more)
The only rational way to approach this problem is to plan your Notes development around a release date. If you have two features that will take different amounts of time to complete, you need to manage each effort individually. This means that before you start having multiple developers make changes to the same database, you need to create a database for each effort. As each project is completed coding and testing, the last project done must be merged into the first project to be completely tested.
Note that this provides some incentive to Notes developers--if your project finishes first, your testing is related only to your project. The second place team has to test their features and the features from the first team.
But wait a second--I said "merge". Doesn't that mean cutting and pasting which I already said was bad? Not really. With proper version management techniques, and not just source code control, you can do some pretty cool things to merge two databases together. Here's a hint though--it involves rolling back some changes. But that still leaves the nasty situation where both projects made changes to the same design element. And let me tell you, you do not want me to automatically merge these two things together.
In the mean time, pick-and-choose release processes really depend on parallel development efforts in separate templates, and proper version management solutions.