How do you convert your office to build automation? [closed]

Question

The title should say it all, then I can solidify 2 more ticks on the Joel test.

I've implemented build automation using a makefile and a python script already and I understand the basics and the options.

But how can I, the new guy who reads the blogs, convince my cohort of its inherent efficacy?

Answer 1

Ask for forgiveness, instead of permission.

Get it working in private (which it looks like you have) and then demonstrate its advantages.

One thing that always gets people is using CruiseControl's Tray utility - people love it when they can see, through their system tray, that the build succeeded. (this is assuming you're in a Windows environment, that CruiseControl will work with your existing systems, etc.)

NOTE: If asking for forgiveness instead of permission will result in instant termination, you might not want to do the above. You might also want to look for work somewhere else. Your mileage may vary.

Answer 2

Implement build lights ... we did something similar with lava lamps and it was a huge hit. For added bonus marks give every developer a red light over their desk and have the right light come on when the build breaks.

Answer 3

Grab an old spare computer & put it in the corner of your office. Set it up to build your project. Write a small script that does:

1. Get latest version of all files.
2. If there was a file change, build
3. Notify you if there's a failure.

When you catch a break, compassionately get it fixed.

Consider adding a step to run unit tests, too.

If you can avoid scolding people for their mistakes, pretty soon people will be impressed with how reliable the build has been since you arrived. Build from there.

The trick is to spend very little of your time to generate a lot of value for your team, without pissing anyone off.

Answer 4

Set up an autobuilder. Once you have it building and running the tests automatically, it won't matter if you convince other people to save their own time :)

If you're using git for version control, here's an autobuilder that automatically finds the exact checkin that started causing the tests to fail: http://github.com/apenwarr/gitbuilder/

Answer 5

I would take a spare box, install a continuous integration server (Hudson or CruiseControl in the Java world) and set up a job that builds your application each time someone checks in some code.

You can either try to convince your coworker or just wait until someone breaks the build. In the latter case, just send the following email:

to: all developers

Guys,

I've just noticed that I can build our software using the 
latest version because of the following error:

    ...

I you want to be notified by our continuous 
build system (attached is the mail I received when
it failed to build our application), just let me know.

Usually it doesn't take that long until everyone is on the list

Answer 6

I would set up the automated build as a nightly process such that every night it grabs the most recent code revision, builds it, and generates a report. Now you will know first thing every morning whether or not the build is broken, and if it is, you can notify the team. If broken builds are much of a problem on your project, people will probably start coming to you first to find out if it is safe to sync to the latest code, since you will be the person who tends to know on any given day whether or not the build is broken (by the way, an automated suite of unit tests helps a great deal with this as well). With any luck, people will start to realize that your nightly build is a useful thing to have, and you'll be able to just set up your daily build report as an email that goes out.

Answer 7

James Shora has two great links:

For hardware http://jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

For "Humanware" http://jamesshore.com/Change-Diary/

( The history of how he did it. The read is long but changing an organization is harder )

Answer 8

When the build is needed by the team on a regular basis, it's pretty easy. You appoint a team member (rotated periodically) to do the build. If the build process is complicated enough, the team will on its own come up with a way of at least partially automating the build. In the worst case, you'll have to automate the build yourself, but no-one will be against the automation.

Answer 9

Demonstration is the best, and really the only way to change anyone's mind who is resistant to doing things differently.

Here we showed how useful automated builds are by having the ability for QA to grab a green light build straight from the build server and install it and test without any direction from the developers. They are able to continue working, they know that it at least passes it's unit tests. It helped integrate testing and development reducing time bugs were in the system.