views:

1870

answers:

31

I am just curious to see what others are doing during build-automation other than usual compile, build, run-tests, etc tasks that might be helpful and inspirational for others to consider and look into such as:

  • Generating code documentation
  • Using code-metrics to measure build quality and fail the build if established metrics are violated.
+4  A: 

We apply a digital signature to all the binaries we produce. The build script does that automatically.

sharptooth
+37  A: 

Firing the executables off to http://virustotal.com for a virus scan against all the major anti-virus engines.

Not that we think our exes contain viruses, but sometimes you get a false positive and you don't want it to be a customer that finds it. 8-)

RichieHindle
+1: Nice idea :-)
Jon Cage
+1 What a great idea!
Roee Adler
I doubt that is so important...
Yacoder
It's not important.. unless you trigger a match and then it definitely _is_ :-)
Jon Cage
+17  A: 

Ours has a twitter account so we can check its status anytime from anywhere

David Sykes
And you need Twitter for this?
Adam Byrtek
What could be easier?
David Sykes
hudson build server
geowa4
+5  A: 

Deploy websites directly to test deployment servers.

Lou Franco
+12  A: 

Here are some things I've done, do, or plan to do:

  • Update a traffic light (using an X10 gadget) to indicate build status (green=good, yellow=building, red=whoops!).
  • Generate code documentation, then update the project wiki with the documentation.
  • Other project wiki updates such as posting the current version number, providing a download link, and so on.
  • Deploy to (and roll-back if necessary) a test server where manual testing is done. I've typically done this using VMWare so the "deploy" is really the creation of a new VM instance.
  • Automatically move tickets that are "pending build" over to QA for testing.
  • Create defect reports for failed tests, failed builds, and compiler warnings.
  • Tag the build in version control (also apply version info).
  • Schedule a review after X or more failed builds within Y days. (e.g. if three fails occur in one week, we need to meet to figure out what's going on)
  • Schedule a "pizza and beer" party for error-free weeks.
  • Play a loud "ca-ching!" sound over the PA system whenever a feature we know will lead to a new sale is completed. At my old company, our sales group loved this useless feature :).
James
The traffic light idea is really good, we do it in our office as well and it gives a really good overview of the current state of the build. The addition of an UBS transmitter controlling six sets of traffic light power sockets around the office spreads the knowledge of the current status of the build.
Stefan Thyberg
+2  A: 

Various projects I've been on had large public displays of who last checked in and who broke the build. We did this with Build-o-matic and I wrote Team Piazza to display the same information for Team City builds.

Nat
+12  A: 

Create a report for any TODO/FIXME etc. that might be scattered around the code.

Mark
More info on this please :) Great idea!
Pure.Krome
We use Hudson along with the Task Scanner Plugin: http://wiki.hudson-ci.org//display/HUDSON/Task+Scanner+Plugin
Mark
A: 

working on one of the other pressing deadlines or catching up on email (wait that is not cool, or interesting...) ok fine, here is what I really do: http://samurai-ryan.mybrute.com/

shogun
I am not asking what you do when the build is in progress. I am asking how you customize your build process which involves coding, writing scripts, thinking, designing, etc.
Mehmet Aras
I also play on mybrute when waiting for a compile :) haha. that site sucks balls though :( always down/breaking. fail :( .. yet .. i .. still .. play .. it ...
Pure.Krome
A: 

We have a web app and have put performance testing and will be putting HTML/CSS validation into the test scripts.

Jeremy French
+2  A: 

Managed Code:

  1. Update all AssemblyInfo files with a consistent version
  2. Run StyleCop and FxCop and check that the code is both beautiful and well behaved!

Native Code:

  1. Run depends.exe across the binaries and check that no dependencies on the debug runtime have crept in - happens all too often
  2. Use manifest.exe to dump the manifest files and check for debug dependencies - those things get everywhere!
  3. Generate python bindings for C++ code using SWIG
Simon Steele
Do you know assemblies can share (as links) AssemblyInfo files? Means you only have to change AssemblyVersion in one place and it can propagate across all assemblies. See http://stackoverflow.com/questions/438782/assembly-versioning-using-cruisecontrol-net/471309#471309
Si
+17  A: 

We have a Staples easy button that we've hooked up to fire off the build when pressed.

Jeremy Cron
Wow never heard of that before... definitely want one! :)
fretje
you need to delay the speakers to when the build passes.
geowa4
+1  A: 

For Java development we use:

  • JUnit complemented by Cobertura (Cobertura identifies which parts of the code are lacking test coverage)
  • Find Bugs - tool that scours the code looking for bugs and vulnerabilities
  • Hudson tool (see hudson.dev.java.net [I can't post hyperlinks yet!]) which manages the building and testing of software. It has a feature like AoP's (above) traffic light - Blue-successful build and all unit tests passed, Yellow-successful build and some unit tests failed, Red-build failed.

Hudson also

  • Manages software building via plug-ins to SVN, Continuus, etc
  • Maintains a history of all builds - allowing our Junit tests and Find Bugs results to be displayed in trend graphs
  • Sends emails to all interested parties whenever the build results in a changed state (e.g. Blue to Yellow, Red to Blue)
  • All information is presented in a simple internal web page
Steve M
I was on a project that used Hudson. I thought it was pretty cool. I think those people changing traffic lights are crazy. How will they feel if they cause an accident?
Nosredna
There aren't real traffic lights. It's software installed on their machines.
Geo
+4  A: 

A few things.

  1. Upload pdb's to Symbol/Source Server <- invaluable for debugging winqual crash dumps
  2. Run Tests on Installers deployed into VM's through CC.NET
  3. Create a base VM for testing through CC.NET and deploy it to all QA
  4. Take a copy of that VM image and using EggPlant perform Automated UI testing
Alex
A: 

We had a build script that automatically tagged the build and SVN and deployed the application to WebSphere application server.

Owen
+3  A: 

Substitutes the version number in the SVG splash screen and then renders it in Inkscape.

Paul Fisher
A: 

For Java, you can also use Ivy to automatically grab any missing libraries. For example, if you use Hibernate, you may or may not want to include those libraries in your release.

xeon
+5  A: 

Automatically advance your issue workflow.

We wrote a custom plugin to our Bamboo CI server that gathers all the JIRA issues related to the build (determined from svn commit comments) and checks their status in JIRA.

Once the build succeeds (and deploys the app to a running server), any issue in the "waiting to be built" workflow stage, is automatically advanced to the "built and available to test" stage, which triggers an email to be sent to the tester assigned to the issue.

This means our testers receive issue notification emails not when the developer checks in the code, but when the fix is running live on a server and the tester can actually do something about it.

Brian Laframboise
That sounds awesome!
Dan F
Sounds VSTS to me :P
Ruben Bartelink
is your plugin source code opensource/available? thanks
webwesen
@webwesen No, and I wouldn't be allowed to share it. Also, it's stopped working since we upgraded to Bamboo 2.5 which is something I should go fix :-)
Brian Laframboise
A: 

Reset a test db in Post build step:

  • prepare a set of files (using TemplateFile task)

Use these files to

  • delete the test db
  • take a backup of the central db
  • restore it to a new test db instance
  • run initialization sql scripts in test db (using Sql.Execute task)
  • convert (using Xml.XslTransform task) xml data files to sql files (inserts)
  • run them on the test db

After this we have a clean test db, with the correct schema, all the fixed data from the central db and then some extra test data.

Would be better if the schema and fixed data would also be in comparable data and sql files, but that's WIP. The central db isn't yet, but should be in source control.

jan
+1  A: 

Running unit-tests and code analysis tools like NDepend, Gandarme. Results are published by CC.Net

shatl
+1  A: 

We build BizTalk 2006 projects :)

thijs
I bet the downvoters never tried to do that themselves. I have tried and it is a nightmare. Well done!
Sergio Acosta
A: 

How about embedding a build-time timestamp into each built image?

<ItemGroup>
  <StampFile   Include="BuildTimestamp.cs"/>
</ItemGroup>

<Target Name="BuildTimestamp" 
        Outputs="@(StampFile)">
  <Message Text="Building Timestamp..." />
  <Touch
     AlwaysCreate = "true"
        Files="@(StampFile)" />

    <WriteLinesToFile
        File="@(StampFile)"
        Lines='public static class Build { public static string Timestamp = "%(StampFile.CreatedTime)" %3B }'
        Overwrite="true"/>
</Target>

You could extend this to include Machine name, phase of the moon, etc.

Cheeso
A: 

A few things we've done:

  1. Digitally sign all exes
  2. Archive pdbs
  3. Create installers using WIX
  4. Produce complete .iso files for software that is distributed on CD or DVD
pjbelf
A: 

Here are some things that I usually have in Continuous Integration:

  • computing code metrics and performance statistics (captured by our framework, while tests are executed;
  • running code-quality tests that enforce certain development guidelines (i.e.: class naming, immutability, allowed references);
  • updating online documentation that is generated from the code;
  • putting install packages (WiX & ClickOnce) to the deployment server and updating manifest needed for auto-updates;
  • updating "Download" page for out open-source projects;
  • notifying all involved parties about the build and results.
Rinat Abdullin
A: 

We use 'checkstyle' (http://checkstyle.sourceforge.net/anttask.html) to generate a report for the code that could be newly checked-in and not reviewed (formally) before the developer builds. Also, I have written a few custom tasks that do the following:

  1. Check for the DB Connection properties and tries to make an actual connection to DB (simple JDBC code) and report if any user credential issue etc. are present.
  2. Add the username and Timestamp of the last build to the code
  3. Send a notification to our Corporate IM Client (custom list) with the status of the build

There are several more tasks that are there but they are specific to the internal environment related settings.

Vinnie
+2  A: 

We do a binary compatibility analysis (using reflection) against our latest public release to make sure we don't introduce binary breaking changes by accident. Whenever we are forced to a breaking change, we add the specific api to the list of "accepted breaking changes" so that the next build can skip testing that. When it's time for release we have a complete list of the APIs that break in the new release.

fredrikt
+1 trying to do the same with Clirr for Java. However, it's somehow annoying as there are lots of problems with nested classes and woven aspects, rendering Clirr unusable for some modules.
mhaller
A: 

We have a Nabaztag/tag showing if any errors occur on the build-server.

corné
For more information about the Bunny, check out http://stackoverflow.com/questions/709906/how-have-you-ever-interacted-with-a-nabaztag
peSHIr
+6  A: 

Pull a random image off failblog.com to attach to the 'build failed' email.

mattnewport
Of course everyone is waiting to the build to break so they can get a funny picture in the mail. =)
Sergio Acosta
A: 

I am really surprised nobody mentioned updating config files! We update our config files b based on the environment we are building for using the build script. It saves atleast 20 mintues it would take to replace all the connectionStrings and appSettings. Other things we do are:

Update Version number
Move to Test Servers
Run code analysis
Email build status
Run some database scripts

desigeek
We (and many teams I know) use property files for different target environments. This bypasses the need for replacing anything after teh build. The buildproject already gets triggered with the correct value so the package is built already for the correct target. I guess it depends on how the build scripts are written.
Critical Skill
A: 

I haven't read more than half of the answers here, but I hope some of these are "new":

  • Installing and upgrading an older version to check file differences from a new installation (tests our deployment upgrade configuration)
  • Deploy our core application and external system adapters to a custom Jboss (included in the project/release), start it and run SoapUI test suites to verify end-to-end functionality (also an extra test for our deployment automation)
  • Apply delta scripts to a previous database version and then make a structural comparison to a new installation so that new tables, columns etc. gets created during upgrades
  • Publish our release documentation in Confluence (we basically run our complete release script each night), as a preview of the next release from trunk
Mirvnillith
A: 

We do a lot: with MSBUILD

  • Getting sources
  • Update Assembly info with time stamp and last changeset in file info and version info
  • Compile:)
  • Run Tests with Galio
  • Create test report with current time stamp and publish it on IIS
  • Create a Zip packages of all necessary binaries
  • Publish Zip packages on SVN
  • Unbind SLN file from TFS
  • Delete all bin/obj files
  • Publish source code on SVN
  • Send email, after build success or failure
  • Deploy application using NANT scripts
Leszek Wachowicz
A: 

Apart from versioning, signing and testing etc already mentioned here a number of times, we also:

  • run spdisposeCheck for sharepoint-dll's
  • run sigcheck (from sysinternals) to create a nice overview of versions and applied certificates
Bart Janson