Subversion working practises.
-
This week we switched over to subversion (from source safe). :-D I spent yesterday reconfiguring the build server (cruise control .net) to work from subversion. Thing is, the build server runs with the trunk. Today I branched the trunk to start work on some new features that have been requested, so when I commit changes to my branch the build server doesn't do anything. Is this a common problem? Should I change my build server to run on the branch we are currently working on. But then what if different devs are working on different branches? Should we have multiple build servers instead, one for each major development branch and one for the trunk? Or do I just accept this, and encourage devs to regularly merge back down to the trunk so things get built. I'm wondering if we should have a standard "unstable" branch, and two build servers. one for unstable branch and one for the trunk. Disclaimer: This isn't a programming question, I know how to do these things, I'm just not sure which is the best process. I'm interested in what other people are doing.
Simon
-
one approach is this: Have seperate 'trunk' and 'release' branches. Your build server would build out of /release. All development and updates occurs in /trunk. If a developer wants to make small changes they'd do that in /trunk. If a major change is taking place - i.e. experimental changes that might have a major impact, the developer would create their own branch, and merge back into /trunk when they're done. When you want to cut a new release, you 'svn' copy /trunk over into /release (keeping the svn history in the process) - or choose which bits of /trunk you want to release (or even an interim release-candidate) This way your release process is highly controlled and you can easily revert back to known released versions at any time without having to worry about the mess that can occur in trunk with multiple developers merging in their separate branches.
That is essentially what I have set up currently. (Although slightly different names) The sticking point though, is what branch does the build server run on. It's currently set to run on what you are calling the "release" branch. but this means we don't get the benefit of continuous builds and automated unit test runs on our development branch. So I basically need 2 build servers don't I? Or is there a happy medium somewhere. (We only have 3 devs, including me, so 2 build servers seems like overkill)
Simon
-
That is essentially what I have set up currently. (Although slightly different names) The sticking point though, is what branch does the build server run on. It's currently set to run on what you are calling the "release" branch. but this means we don't get the benefit of continuous builds and automated unit test runs on our development branch. So I basically need 2 build servers don't I? Or is there a happy medium somewhere. (We only have 3 devs, including me, so 2 build servers seems like overkill)
Simon
Ah I see... yes in that case you'd need two build servers. Definitely seems like overkill for 3 devs - but it'd scale well if you grow in size, and it shouldn't be any overhead for you once it's set up. Does seem excessive though. Maybe just one build server that has both trunk + release brances checked out, and the server builds one, then the other, all on the same box?
-
Simon Stevens wrote:
when I commit changes to my branch the build server doesn't do anything
How did you handle that before ? I can't see why moving from SS to SVN should affect the way you can build on the build servers.
:-D We didn't branch with SS. (Branching is SS is confusing, and apparently temperamental, so we just didn't do it. It was one of the arguments for switching to svn - support for proper reliable branching) All development was just done, and checked straight in to the main branch, so the build server just built that.
Simon
-
This week we switched over to subversion (from source safe). :-D I spent yesterday reconfiguring the build server (cruise control .net) to work from subversion. Thing is, the build server runs with the trunk. Today I branched the trunk to start work on some new features that have been requested, so when I commit changes to my branch the build server doesn't do anything. Is this a common problem? Should I change my build server to run on the branch we are currently working on. But then what if different devs are working on different branches? Should we have multiple build servers instead, one for each major development branch and one for the trunk? Or do I just accept this, and encourage devs to regularly merge back down to the trunk so things get built. I'm wondering if we should have a standard "unstable" branch, and two build servers. one for unstable branch and one for the trunk. Disclaimer: This isn't a programming question, I know how to do these things, I'm just not sure which is the best process. I'm interested in what other people are doing.
Simon
Wow, I can't believe someone else is using CruiseControl.Net - I thought I was the only one! This is our setup:
-
Surround SCM to manage our code, but the concepts are the same
-
We have one constant task, ConfigGenerator
-
ConfigGenerator runs a CCNet plugin which runs a csscript[^] which does three things:
-
generates our known builds, such as the trunk
-
queries the issue tracker for what code changes are currently active.
-
using the same named issue for a branch, we now know what branches are in active testing or need building.
-
For each of these we write out a block to the config.xml file
-
After all this, CruiseControl.Net reads in the new config xml file, and recognises there are new builds to be done.
The benefits for this are:
- We can easily have per branch build scripts, thus building earlier versions as well as current
- People can sandbox all individual development
- We have our intranet also link to cc.net, which allows us to single click and publish a download to a web site to allow customers to access urgent interim builds.
- Regression test CC.Net projects are automatically generated along side branch CC.Net projects. That means they can be run independantly of all others.
- Our trunk remains clean and known good almost all of the time. People can check in willy nilly to their own branch at no risk.
- In general it's awesome.
-
-
Thanks. It just seems like a bit of overkill for a department with 3 developers (including me). :laugh:
Simon
Simon Stevens wrote:
It just seems like a bit of overkill for a department with 3 developers (including me).
That's cause it probably is - you didn't say there were only three of you :-) I was thinking more along hte lines of 10-20!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Ah I see... yes in that case you'd need two build servers. Definitely seems like overkill for 3 devs - but it'd scale well if you grow in size, and it shouldn't be any overhead for you once it's set up. Does seem excessive though. Maybe just one build server that has both trunk + release brances checked out, and the server builds one, then the other, all on the same box?
James Brown wrote:
Maybe just one build server that has both trunk + release brances checked out, and the server builds one, then the other, all on the same box?
Yeah, I thought about that, but I don't think it will work. They'll basically be checked out into two separate folders, and it will end up with references getting crossed over. on the dev pc you have: c:\source\project1\bin c:\source\project2\bin project 2 references a project 1 binary. Everything works fine, you check it in. on the build server: c:\source\project1\bin c:\source\project2\bin c:\releasebranchsource\project1\bin c:\releasebranchsource\project2\bin project 2 reference in the release source branch will be pointing at c:\source\project1\bin, so the build of the release branch will end up pointing to the other branch. Maybe it won't, maybe I'm wrong and it will work fine. But there are definitely parts of the build process that are script files that rely on the full path being the same. Maybe that's the problem though, maybe I should be changing those script files to work independent of paths. Thanks for the help though, I'll look into it.
Simon
-
Wow, I can't believe someone else is using CruiseControl.Net - I thought I was the only one! This is our setup:
-
Surround SCM to manage our code, but the concepts are the same
-
We have one constant task, ConfigGenerator
-
ConfigGenerator runs a CCNet plugin which runs a csscript[^] which does three things:
-
generates our known builds, such as the trunk
-
queries the issue tracker for what code changes are currently active.
-
using the same named issue for a branch, we now know what branches are in active testing or need building.
-
For each of these we write out a block to the config.xml file
-
After all this, CruiseControl.Net reads in the new config xml file, and recognises there are new builds to be done.
The benefits for this are:
- We can easily have per branch build scripts, thus building earlier versions as well as current
- People can sandbox all individual development
- We have our intranet also link to cc.net, which allows us to single click and publish a download to a web site to allow customers to access urgent interim builds.
- Regression test CC.Net projects are automatically generated along side branch CC.Net projects. That means they can be run independantly of all others.
- Our trunk remains clean and known good almost all of the time. People can check in willy nilly to their own branch at no risk.
- In general it's awesome.
ccnet rocks, I can't believe more people don't use it. I love having it auto run a full build, all unit tests and fxcop reports any time I check in any changes. It's a step beyond nightly builds that I find really helpful. and I love the instant feedback to the cctray app. So basically, you have a custom plugin that regenerates your ccnet.config file any time it detects changes, and creates different ccnet projects for each branch? Cool. I think my main problem is our build process is totally dependant on the path it is in. If I copied all the source and scripts to a different directory the build wouldn't work. OK. I think I might work on making things path independent, then I can just have the build server build multiple branches.
Simon
-
-
ccnet rocks, I can't believe more people don't use it. I love having it auto run a full build, all unit tests and fxcop reports any time I check in any changes. It's a step beyond nightly builds that I find really helpful. and I love the instant feedback to the cctray app. So basically, you have a custom plugin that regenerates your ccnet.config file any time it detects changes, and creates different ccnet projects for each branch? Cool. I think my main problem is our build process is totally dependant on the path it is in. If I copied all the source and scripts to a different directory the build wouldn't work. OK. I think I might work on making things path independent, then I can just have the build server build multiple branches.
Simon
Yep, you summarised it far better than I. The automatic generation thing is so great. It just means that everybody's individual work is built in precisely the same process as the full release builds. We have confidence in giving interim builds to special clients because we know it's just like a full build, just manually tested less. CCNet rocks. It's not the only system out there, but we like it. Oh, and just for reference, we only have 3 or 4 developers in our team, so it's the same size as you. And it's a perfect fit for us. The next step for us with CruiseControl is to separate the regression tests and builds on to a separate machine, and start toying with ways of doing concurrent builds with confidence. You are right - the first step is path independence. We achieved that by stick nearly everything in to source control. One check out is 95% of the way to getting a complete build.
-
:-D We didn't branch with SS. (Branching is SS is confusing, and apparently temperamental, so we just didn't do it. It was one of the arguments for switching to svn - support for proper reliable branching) All development was just done, and checked straight in to the main branch, so the build server just built that.
Simon
OK. I am not doing any SW development at the moment. In my previous company, the build server got the path of the branch as parameter and could build any branch. There was a simple web interface for all developers to customize the build, including the path.
-
Yep, you summarised it far better than I. The automatic generation thing is so great. It just means that everybody's individual work is built in precisely the same process as the full release builds. We have confidence in giving interim builds to special clients because we know it's just like a full build, just manually tested less. CCNet rocks. It's not the only system out there, but we like it. Oh, and just for reference, we only have 3 or 4 developers in our team, so it's the same size as you. And it's a perfect fit for us. The next step for us with CruiseControl is to separate the regression tests and builds on to a separate machine, and start toying with ways of doing concurrent builds with confidence. You are right - the first step is path independence. We achieved that by stick nearly everything in to source control. One check out is 95% of the way to getting a complete build.
Phil Martin... wrote:
You are right - the first step is path independence. We achieved that by stick nearly everything in to source control. One check out is 95% of the way to getting a complete build.
Yeah, all our build scripts and 3rd party stuff are all source controlled too. I'm assuming most of our build scripts can be changed fairly easily, it's just a matter of working through them. So the .net references thing (here[^]) won't cause a problem then? We have a library project that contains an assembly that most other projects reference. Thanks for the suggestions.
Simon
-
OK. I am not doing any SW development at the moment. In my previous company, the build server got the path of the branch as parameter and could build any branch. There was a simple web interface for all developers to customize the build, including the path.
That's an interesting idea. Thanks. I'll look into it.
Simon
-
Phil Martin... wrote:
You are right - the first step is path independence. We achieved that by stick nearly everything in to source control. One check out is 95% of the way to getting a complete build.
Yeah, all our build scripts and 3rd party stuff are all source controlled too. I'm assuming most of our build scripts can be changed fairly easily, it's just a matter of working through them. So the .net references thing (here[^]) won't cause a problem then? We have a library project that contains an assembly that most other projects reference. Thanks for the suggestions.
Simon
Again we handle this by sticking it all in source control, and when CC.net does a checkout for building, it grabs everything it needs to do a build in isolation. We can still branch at different spots, but the way we have it all set up is if a branch is taken at a child spot, it grabs the code from the parent branch for the rest of the tree. We made this decision based on our priorities of quality over efficiency. I'm sure we could have come up with a way of sharing builds across branches to speed up compile time. But we weighed it up, and it was more important to us to have a absolutely definitely known good build rather than one that takes 5 minutes instead of 10. Not sure if that helps or not though.
-
Thanks. It just seems like a bit of overkill for a department with 3 developers (including me). :laugh:
Simon
It's still not such a bad idea to keep development, test and production code apart. It stops a lot of the issues where one person's change stops everyone else's from working. VirtualBox or VMWare would mean that you don't have to have multiple physical boxen. If you're testing hard you can always recover some resources by shutting down the virtual instances that you are not using.
-
Again we handle this by sticking it all in source control, and when CC.net does a checkout for building, it grabs everything it needs to do a build in isolation. We can still branch at different spots, but the way we have it all set up is if a branch is taken at a child spot, it grabs the code from the parent branch for the rest of the tree. We made this decision based on our priorities of quality over efficiency. I'm sure we could have come up with a way of sharing builds across branches to speed up compile time. But we weighed it up, and it was more important to us to have a absolutely definitely known good build rather than one that takes 5 minutes instead of 10. Not sure if that helps or not though.
It does. Thanks. I think I just need to experiment a bit, and get my builds totally independent of path/location etc. Cheers.
Simon