Best Practices building a build on Bamboo for .NET solutions

Hi everyone,

I am testing Bamboo for my team and i am looking for some best practices for before i dig into it. Let me tell you couple of facts about what i have to deal with :

  • We are building around 200 projects C#/C++ projects that is scattered thru different Visual Studio 2008 and 2010 solutions.
  • At the moment our nightly build script is made in Visual Build and the same script is used for the Continous Integration (we use some variables to define whether it's a nightly build or CI)
  • Both nightly build and CI is run by Cruise Control.
  • All our projects publish their dll/pdb files to one folder inorder for our application can find the components.
  • When Daily Build is done it publishes all it's components with the executable into a folder structure on a network drive which the developers can get in the morning by running an windows batch file (xcopy from network drive)
  • During the day the Continous Integration makes sure that all the projects touched or the projects where their references are changed get's build.
  • The output from the CI is also copied to network drive which developers can get during the day as above.

My questions are as following :

  • I think it's better to ditch the script i have now and start over (because it's a bit messy) so the quesiton is should i create a task for each project/solution in bamboo calling msbuild from Bamboo or should i make a Windows Batch file for each project then call that from bamboo ?
  • When one reads books about the build topic usually they recommend that one has a possibility to do a build on any machine for example on the developers machine, we can do that today because the script is made in Visual Build and can be launched from any machine but what if we move all the contents to Bamboo ? What's your take on this ? How do you do this ?
  • We publish our output (dll/exe) to network drive, would it be better to let Bamboo take care of this and putting these in the Artifacts (i guess that's what the artifacts is for or am i mistakin ?)
  • How do you guys keep the build scripts safe ? Today we have the build script inside source control but what do you do when it's scattered thru Plans / Jobs / Tasks in Bamboo ?

I guess these are my questions as a start. I will add if we start a discussion.

/donnib

1 answer

Hi donnib,

  1. You could keep the same script if you wish. However using the MSBuild Task is also a good way of executing Visual Studio builds. There is also a task for building Visual Studio projects which is a little simpler than using MSBuild directly.
  2. Remote agents are the way you can offload builds on to other machines if your main build server is too slow or you want the capacity to run many builds at once. If you want to run the build on a remote machine, you will need a remote agent intalled on each remote machine. However, you will not need remote agents if you run the build on the same machine as the server.
  3. Yes, you are right :) You will need to configure Artifact Sharing for Bamboo to collect and store the dll's and exe's that your build produces.
  4. You can use Bamboos automatic backup to schedule regular backups of Bamboo. However, if you want to keep the build scripts in source control, you can always store scripts that are used in Bamboo in version control and have Bamboo execute them using a Script Task.

I hope this helps!

Thanks
James

@James thanks for taking the time to answer.

Do i get some kind of flexibility using the tasks inside Bamboo vs External task or script ? I mean is there any benefits such as seeing a better progress, logging, failure etc is better using the Bamboo taks ?

/donnib

The advantage to using Tasks is that you are able to configure everything your script does in the Bamboo interface without writing a script.

Suggest an answer

Log in or Join to answer
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,069 views 0 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot