Comments on: Local builds and build servers http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/ Strong opinions, weakly held Sat, 25 May 2013 16:53:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Dominik http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4477 Dominik Thu, 29 Mar 2012 07:28:00 +0000 http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4477 IMHO this is hard to achieve this with Teamcity, but someone can put .BuildServerconfigproject-config.xml into source control to get it restored without teamcity backup mechanism. IMHO this is hard to achieve this with Teamcity, but someone can put .BuildServerconfigproject-config.xml into source control to get it restored without teamcity backup mechanism.

]]> By: StarTrekRedneck http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4469 StarTrekRedneck Wed, 28 Mar 2012 12:50:00 +0000 http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4469 I like the independence that the script gives you, and I agree deployment seems like a completely orthogonal concern. Have you considered putting the deployment script/application in its own repository? Viewing the script as its own app could give you additional freedoms. I like the independence that the script gives you, and I agree deployment seems like a completely orthogonal concern. Have you considered putting the deployment script/application in its own repository? Viewing the script as its own app could give you additional freedoms.

]]> By: Chris Patterson http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4348 Chris Patterson Fri, 02 Mar 2012 15:08:00 +0000 http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4348 If it's already setup in your build script, it makes sense to keep it there. If you were doing it manually and wanted to automate it, using the TeamCity build steps makes the most sense - because it's easy, you just plug some fields and done. If TeamCity were to go away after that, you would then take the hit of writing the script to make it happen. With TeamCity, you could also make the build step optional or based on something in the log file (such as a version number, etc.) as to when it is pushed (nm, that's some icky coupling). I realize you're pushing to NuGet from master every time, but consider having a develop branch where the latest and greatest bits are sourced and pushed as -prerelease. This way, edge users can pull the latest and greatest, while you can spend a little more time testing the master build before pushing it to GA. Just a thought, I realize we discussed this already yesterday. :) If it’s already setup in your build script, it makes sense to keep it there. If you were doing it manually and wanted to automate it, using the TeamCity build steps makes the most sense – because it’s easy, you just plug some fields and done.

If TeamCity were to go away after that, you would then take the hit of writing the script to make it happen. With TeamCity, you could also make the build step optional or based on something in the log file (such as a version number, etc.) as to when it is pushed (nm, that’s some icky coupling).

I realize you’re pushing to NuGet from master every time, but consider having a develop branch where the latest and greatest bits are sourced and pushed as -prerelease. This way, edge users can pull the latest and greatest, while you can spend a little more time testing the master build before pushing it to GA. Just a thought, I realize we discussed this already yesterday. :)

]]> By: Anonymous http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4347 Anonymous Fri, 02 Mar 2012 03:21:00 +0000 http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4347 Let's pretend that some day teamcity.codebetter.com will be closed down. And so? What you would to do then? Let’s pretend that some day teamcity.codebetter.com will be closed down. And so? What you would to do then?

]]> By: Anonymous http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4346 Anonymous Thu, 01 Mar 2012 22:35:00 +0000 http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4346 I have very good experience with having the build/deployment script under version control. It's easy to debug and you can change the actual steps to deploy without changing the high-level API (rake tasks). You might want to have a look at Machine.Specifications and Machine.Fakes, both run on CodeBetter CI and push NuGet packages straight from the release build configs. I have very good experience with having the build/deployment script under version control. It’s easy to debug and you can change the actual steps to deploy without changing the high-level API (rake tasks).

You might want to have a look at Machine.Specifications and Machine.Fakes, both run on CodeBetter CI and push NuGet packages straight from the release build configs.

]]> By: Anonymous http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4345 Anonymous Thu, 01 Mar 2012 21:58:00 +0000 http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4345 Nah, not with TeamCity. Nah, not with TeamCity.

]]> By: Bob Archer http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4344 Bob Archer Thu, 01 Mar 2012 21:38:00 +0000 http://lostechies.com/jimmybogard/2012/03/01/local-builds-and-build-servers/#comment-4344 Can't you version control your build configuration? We use ccnet and each project has a ccnet.config in it's project folder that is version controlled and the primary ccnet.config basically sets some global paths and stuff and then includes all the projects ccnet.config files. Oh, and the top level ccnet.config is in svn as well. We even have a build project that looks for change to ccnet.config, gets them and ccnet has a filewatcher that reads new config files whenever it seems them. Can’t you version control your build configuration? We use ccnet and each project has a ccnet.config in it’s project folder that is version controlled and the primary ccnet.config basically sets some global paths and stuff and then includes all the projects ccnet.config files. Oh, and the top level ccnet.config is in svn as well. We even have a build project that looks for change to ccnet.config, gets them and ccnet has a filewatcher that reads new config files whenever it seems them.

]]>