views:

108

answers:

2

We have a new build machine to start using for our programming team. We are still trying to figure out how we want to organize everything to get the best configuration for building EXEs and DLLs.

We are using VB6 and VB.Net 2005, and VSS2005.

We were thinking of making working folders set for each project, release and support tickets. Does anyone have experience with a similar set up? What were your likes/dislikes? Any recommendations (New VSS IDs, folder configuration, setting working folder, updating/building files)?

+3  A: 

be agile - just grow it and and don't be afraid to change as you go a long. Pick something very simple to start with and see how it goes.

Here is my simple environment. Decide what you want to do on a desktop to implement the joel test question #2. This in my experience is pivotal. Once you can do the complete build and test on a desktop with one (or a couple of) clicks then you have the basis for an automated build machine.

The trick is get this going quickly using what ever tools are at hand quickly - e.g. VSS and Cruise control, MSBuild etc, and tune. You should be able to get a pretty good (80/20 rule) in a few days of iterative effort.

Edit: Just to answer comment.

Yes you are correct is is be very beneficial to learn from other people experiences (not just their practises). However having set up build environments in may different companies I can say the best thing is once you start with some else's complexity you end up fighting other peoples requirements and assumptions. Yes I've now got experience and I can use that as a metric to start easily.

Preet Sangha
It's often quicker to start by spending a few minutes learning from other people's experiences first, rather than finding all the gotchas yourself the hard way.
MarkJ
One of those gotchas: stay away from VSS. I have personally experienced way too many VSS crashes and corruption issues to trust it again. Use SVN, git, TFS, mercurial or even CVS instead--they're all much safer (and featureful too)
rpetrich
OK, +1 now. I found the original answer a bit brief - I like the new version though.
MarkJ
A: 

Watch out for issues when building VB6 components that depend on each other - see discussion in this question.

MarkJ
This is why I wrote a general-purpose VB6 build tool (in VB6 no less) a few years back ;) We use it to build 50+ projects with lots of interdependencies between them. The tool automatically figures out the correct compile order and even fixes broken project references without any user intervention. The entire thing runs in 10-15 minutes. Our single-click builds are light years ahead of the manual compile process we had previously.
Mike Spross
You wouldn't like to share that tool I suppose? :)
MarkJ
@MarkJ: Although it works pretty well, I'm somewhat ashamed of the actual code. I was younger and stupider back then, and it was an internal-use only app, so the code is somewhat of a mess in places. I keep telling myself I will clean it up and open-source it someday. Someday...
Mike Spross
That's how I feel about all code I wrote more than 6 months ago! Why not open-source it first and clear it up later?
MarkJ