What are the cool and interesting things that you do during build-automation?

Question

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.

Answer 1

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

Answer 2

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-)

Answer 3

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

Answer 4

Deploy websites directly to test deployment servers.

Answer 5

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 :).

Answer 6

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.

Answer 7

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

Answer 8

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/

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

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

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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

Answer 20

We build BizTalk 2006 projects :)

Answer 21

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.

Answer 22

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

Answer 23

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.

Answer 24

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.

Answer 25

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.

Answer 26

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

Answer 27

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

Answer 28

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

Answer 29

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

Answer 30

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

Answer 31

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