11

What tools do you use for Automated Builds / Automated Deployments? Why?

What tools do you recommend?

casperOne
  • 73,706
  • 19
  • 184
  • 253
ferventcoder
  • 11,952
  • 3
  • 57
  • 90
  • Depends on language and platform, I'd say... – Thomas Sep 19 '08 at 04:29
  • I would agree only to a point. As long as your builder can actually build the language. Deployment scripts don't matter with the language, but only with the location of where the code is going (linux, windows, etc) – ferventcoder Sep 19 '08 at 05:50

20 Answers20

9

Hudson for automated builds. I chose it because it was the easiest to setup and demo. A system that's too complex and isn't slick-looking won't impress management enough to get them on-board for automated builds. Especially in a project that has a lot of inertia.

schwerwolf
  • 250
  • 1
  • 7
  • 20
  • Whe are using hudson here too. It is so much good and has some plugins to analyze data that our build creates (like test reports, coverage tools and some other code analysis). – marcospereira Sep 19 '08 at 05:35
5

We use TeamCity, from JetBrains. They also make Resharper And IntelliJ.

We use it for building our .Net applications, and it has been quite easy to set up, connect to TFS, and run additional tools from. It is very polished, and actually kinda reminds me of this site. Found it much nicer than CruiseControl, and for our team size it is free. If you need lots of different builds, more per-user builds, and so on then it costs a bit (but still quite reasonable).

Andrew
  • 8,322
  • 2
  • 47
  • 70
  • The new version looks even nicer, though a little more complicated on the interface side. You can check it out on the TeamCity site... the free version now allows 20 different build configs, a step up. – Andrew Oct 11 '11 at 11:42
5

NAnt for builds (but MSBuild, Rake, almost anything would be fine) and CruiseControl.NET for deployments. I'm currently working with the new Cruise from ThoughtWorks studios as it provides a better way to stage the various pipelines and let's me deploy any version I want to a target environment.

Bil Simser
  • 1,713
  • 1
  • 19
  • 27
4

Funnily enough I just spent two weeks overhauling (read implementing from scratch) our nightly build process. Great fun (no, really). I toyed with the idea of installing Team Foundation Server, but we use Perforce for source control and I didn't think it was worth the hassle.

Our process is now a set of Powershell scripts that run on a dedicated build/test server that do the following on a scheduled task:

Wipe out the entire source tree (check that you didn't have anything checked out first!)

Bring down the entire source tree from Perforce (from the last labelled build)

Generate a change report (by syncing to HEAD and watching what comes down)

Build the App

Index the PDB files to the Perforce sources

Store the binaries and symbols in a dedicated symbol server

Run the test projects

Build the installer

Label

Send out emails to the group with status reports on all of the above

Works well.

lesscode
  • 6,221
  • 30
  • 58
4

make and bash on linux

make and cmd on windows

BCS
  • 75,627
  • 68
  • 187
  • 294
4

Visual Build Pro

Maltrap
  • 2,620
  • 1
  • 33
  • 32
4

We use a combination of build tools and continuous integration server:

Build tools:

  1. Maven
  2. SBT
  3. Gradle
  4. Rake

Continuous Integration Servers:

  1. Jenkins
  2. Hudson
  3. Travis CI
marcospereira
  • 12,045
  • 3
  • 46
  • 52
3

For our Windows-compilable stuff, we use FinalBuilder.

Peter K.
  • 8,028
  • 4
  • 48
  • 73
3

Automated Build Studio.

Instead of letting you mes with scripts or xml files, it comes with predefined graphical macro operations that allows you to create tasks easily.

Graviton
  • 81,782
  • 146
  • 424
  • 602
  • ... but we're programmers here. – xanadont Sep 19 '08 at 05:44
  • 2
    We're programmers, so we are lazy enough to use the most intuitive tools to get our job done. If that means no scripts no code, so be it. – Graviton Oct 28 '09 at 02:59
  • We're programmers so we're lazy enough to use the BEST tools to get the job done with the minimum possible effort. Intuitive isn't necessarily part of the picture - efficiency and cost/result tradeoffs are. VI is a lot better than notepad, ant better than make, java better than visual basic, even though the latter is more intuitive in all three cases. All depends on what job you need done. – Calimar41 Jun 11 '14 at 08:14
2

UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.

Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!

http://code.google.com/p/uppercut/

Some good explanations here: UppercuT

More information

UppercuT is a conventional automated build, which means you set up a config file and then you get a bunch of features for free. Arguably the most powerful feature is the ability to specify environment settings in ONE place and have them applied everywhere, including documentation when it builds the source.

Documentation available: https://github.com/chucknorris/uppercut/wiki

Features :

ferventcoder
  • 11,952
  • 3
  • 57
  • 90
2

CruiseControl for automated builds. Works great.

Paul Reiners
  • 8,576
  • 33
  • 117
  • 202
2

For automated builds, I think the best tool going right now is JetBrain's Team City. The free version has all the features you'll need for most 5-10 person teams. Set up is easy, configuring new projects is painless (relatively), and most importantly, it's reliable.

For automated migrations, nothing beats PowerShell.

Don
  • 677
  • 5
  • 10
1

I've had success using buildbot, triggered by a post-commit script on a subversion repository. This has been used for both automated builds and automated testing.

Andrew Edgecombe
  • 39,594
  • 3
  • 35
  • 61
1

At work we use good ol' Ant to build our Java servlets.

easeout
  • 8,665
  • 5
  • 43
  • 51
1

We used to use Visual Build from Kinook software, but recently with our new application we switched to MSBuild since it had better integration with TFS and the ability to create custom tasks.

Kevin
  • 1,141
  • 16
  • 27
1

The GNU Autotools definitely. The autoconf and automake are de-facto standard for unix systems.

grigy
  • 6,696
  • 12
  • 49
  • 76
0

ANT for both build and deployment/installs.

Makes a great cross-platform installer.

Mads Hansen
  • 63,927
  • 12
  • 112
  • 147
0

We use Hericus Zed Builds And Bugs Management for our automated builds.

We have 4 branches of code, each with java, c++, C#, cross platform compiles and installers for 5 OS's.

Steven M. Cherry
  • 1,355
  • 1
  • 11
  • 14
0

Make for the builds. Debian packages for deployments (since our production servers runs it).

skinp
  • 4,157
  • 4
  • 27
  • 20
0

TeamCity running NAnt scripts for building/packaging and PowerShell for deployment.

I've found that using NAnt, powered by TeamCity, instead of the native TeamCity runners allows us to have a much richer build process (eg. css minimiser, etc). It also means the full build/package process can be run on any developers PC instead of just the TeamCity servers making it much easier to customise and debug problems in the build process.

Jason Duffett
  • 3,428
  • 2
  • 23
  • 23