Dan Barrett said: > ... we've got a fairly > complex > app at work (tons of J2EE components), and I'm nominally in charge of > CVS/builds/etc. on top of coding. We have three boxes: dev (for > developers > only); test (for testers / the boss / a select number of pilot users); > and > of course, live. All code on CVS is the most current. Dev gets rebuilt > every night > automatically (`tag -R 'build_DD-MONTH-YYYY-HHMM'` and then built by > telling > Ant to assemble that tag name). Test and live get trickier. Once the > boss > identifies features that need to be added or bugs to be fixed, we'll > actually build a release by hand-tagging files -- that release is put > out on > test and messed with. If it's cool, it gets promoted to live. Once we > hit a major release (*.0), the stable code becomes its own branch. > Trunk remains sexy new stuff, branch is the end-of-life stuff that's in > use > by actual users. Any bugfixes to the branch get merged into the trunk. > This works fine because your stable code sits in a nice safe backwater > and > the developers are free to hammer on the trunk. Moral of the story: > whilst your dev box can easily be built automatically, > once your app gets complicated enough you will have to have a real live > human sit there and assemble a build / release. As for the common > commands, for which of them would you like examples?
Dan, thanks for your insight. It sounds like your situation very closely parallels my own. I have a slight difference in that I'm using PHP which doesn't need to be compiled. But it seems all that you said applies. Let me outline briefly the way I perceive you're set up and then ask a couple of questions: 1. Main trunk is for testing. Everyone works off the main trunk. This is nice because it's very easy to work off the trunk. 2. Items are tagged for testing at some interval. 3. Once tested, items are tagged for release (or using my terminology, as "clean" or stable) In another e-mail, Kaz Kylheku stated: > ... You don't want to be trying to move changes > from the trunk to a branch. ... > The big difference from your approach is that the servers are not just > updated willy-nilly; it's a decision that is made. ``Okay, we have done > some useful work on the trunk and nothing seems broken. So let's tag > it, and update the testing server exactly to that build.'' This seems to jive with the above statements by Dan, and it makes sense to me as well. So my questions now center onto tagging and how it works on large (for me) projects such as this. Some parts of the site are stable and will not need to be changed for a considerable amount of time. Other areas of the site get frequent changes. Is it possible (or desirable) to do something similar to the following: 1. Test everything and bring it into a good stable release. 2. Tag the whole application. 3. Work on a few files, test and deem as stable and ready for release 4. Give these new files the same tag as the previous stable release Item #4 being the key. My fear is that we will never have the whole application in a tested and clean state again after #1 is accomplished. Maybe this is a design mentality that I need to change. Additionally, doing QC on the entire application is very time consuming. It takes days for a small team to test everything. Jouni Heikniemi said: > Ps. If you think manually updating the site is problematic and don't want > to bother with versioning, you can add a cron job which does something > like "cvs update -r READY-FOR-PUBLISHING" on a regular basis. Then > you can just "cvs tag -FR READY-FOR-PUBLISHING file1 file2 file3" to get > updated and tested files live. This implies that I can standardize on a tag name and tag everything as CLEAN or similar and just keep that updated onto the live webserver. > Pps. Website versioning is greatly underestimated. It slows down the rate > that users see the enhancements you make, but it makes managing the site > much easier AND increases quality. Consider this :-) Yes, QC is becoming more and more of an issue. When you're pre 1.0 feature completeness is most important; now that we're past that hurdle, quality control is taking more and more of my time. Thank you for your input, Dan Barrett, Kaz Kylheku and Jouni Heikniemi for your quick and useful responses. Matthew Nuzum www.bearfruit.org [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
