Best Practices in Building/Stage-In

Question

What are the best practices in building/stage-in process? I tried to use a CVS repository to have employees stage in their projects then a pair of actual builders will check them out and compile, completing the elevation to production.
I'm experiencing challenges, however - namely:
1) Our organization's process is that should development activities continue, the developer needs to formally check-out the production copy, compiled by the builders.
2) Eclipse build paths are relative to the computer of the developer, so references to JAR's are invalid and need to be resolved manually.
- I attempted to use a shared folder, mapped to a drive (Drive T:\) but is there any better way of making sure the correct JARs are referenced and that the references will still work after commit.
3) CVS Conflicts arise when we try to check in a project (from production) that already has a newer copy committed by a developer (bawal ito - pero for the purposes of SIT, we needed to test this case)
Also we're using Eclipse Build. Is there any better process of building?
Thanks a lot for your help.

Answer 1

801661 wrote:
1) Our organization's process is that should development activities continue, the developer needs to formally check-out the production copy, compiled by the builders.No idea what you're trying to say here.
2) Eclipse build paths are relative to the computer of the developer, so references to JAR's are invalid and need to be resolved manually.
- I attempted to use a shared folder, mapped to a drive (Drive T:\) but is there any better way of making sure the correct JARs are referenced and that the references will still work after commit.Not sure what you mean about "references still working after commit."
3) CVS Conflicts arise when we try to check in a project (from production) that already has a newer copy committed by a developer (bawal ito - pero for the purposes of SIT, we needed to test this case)No idea what you're saying here. The whole notion of "checking in from production" does not compute.
In general, however, any time two developers work on the same file, there's a chance for conflicts. Most VCSs come with a conflict resolution/merge tool.
Also we're using Eclipse Build. Is there any better process of building?An IDE's build can be fine for individual developers' intra-day builds, but for nightly builds that are to be promoted to QA or Production, you'll usually use build tool, such as ant or maven, possibly driven by another process-managing tool such as cruisecontrol.
Other than that, I'm not following exactly what your processes or problems are, so I'll just try to offer some general tips that have worked for me.
1. When it's time to cut an official build from the lastest checked in code, briefly disallow checkins, whether by shouting over cube-tops or by administratively enforcing a lock on your VCS. (I don't know if CVS supports that or not, but most VCSs should.) The buildmaster labels the current state of "main" or "trunk", and may even preemptively create a branch that's rooted there. Once the label has been applied, checkins can be re-enabled. This is all often done automatically late at night.
2. The bulidmaster does a fresh checkout against the new label, and builds from there.
3a. For 3rd party jars that your application uses, create spot in the repository, e.g. /thirdparty, and stick the jars in there, using whatever directory layout and version is appropriate for you. When you label for a build in step 1, make sure you label the thirdparty tree as well, so that you can always get back to the proper version of the entire repository for a given build.
3b. Alternatively, there's a tool called maven that can automate and simplify (after an initial learning curve) the management of those dependencies.
4. For paths that are needed by the developers' environments, pick a standard location. Developers can either go with that, and all its attendant simplicities, or they can arrange things how they want, but they are still individually responsible for a) getting their work done in a timely fashion, b) managing their own environment, without being able to rely on the common knowledge of the rest of the group, and c) not doing things that rely on their particular arrangement and hence end up breaking for everyone else.
5. CVS, while serviceable for simpler projects, lacks some advanced features that other VCSs have. Subversion is a pretty good free tool. It was based on CVS, I think, or at the very least, its commands are almost identical to CVS's in a lot of cases. Perforce is somewhat more feature rich, I think, but quite a bit more complex, and not free. Git is supposed to be gaining popularity, and is free I think, but I've never used it. Clearcase is very powerful, but it's also expensive, and pretty much requires a full-time admin.