Ant Build Templates: Process

This is the third in a series of posts meant to outline my Ant build script template. If you’re interested, it may be helpful to read the first two:

  1. Prelude
  2. Environment

As it was with the environment, so it is with the process. Ultimately, my script was designed and constructed to facilitate my process. With that in mind, it may be useful to know a bit about that process and the standards within it.

We work in a loose, Scrum-like environment. I don’t know exactly how to explain that except to say that we keep our iteration cycles short, but I don’t think anyone would consider our process a formal one. We’re still working on hammering that out. We define a project version and, in two-week cycles, conspire to deliver that version. At the end of each cycle, we build (no, we’re not rocking continuous integration yet) and deploy to staging. At the end of any such cycle, after seeing the project in staging, the business owner has the option of pushing that release into production. As soon as a project goes to production, the version is locked. Any future pushes to production increment either the major, minor or maintenance version.

Project version numbers are formatted as major.minor.maintenance.revision. This is pretty common, in my experience. When a project build is pushed to staging, it is tagged in source control (Subversion, in my case) as /tags/build/tag-name. Projects can only be pushed to production if the exact same revision is used as that which is approved in staging. When pushed to production, a tag is created as /tags/release/tag-name. For historical purposes, I find it helpful to know, at a glance, what revisions have been pushed to production.

That’s it. Somehow it seems more complicated from the inside, but I can’t think of anything else that’s relevant to the build script itself, so I’ll keep this short and consider it a win. Next up: Two Files or One? Now we start to dive into the fun stuff – the scripts themselves and the thought processes behind them.

Subscribe2 Comments on Ant Build Templates: Process

  1. Jim Priest said...

    Catching up :)

    So is /tags/build/tag_name and tags/release/tag_name the same?

    So do changes occur between the two?

    Push to staging – bugs are found, fixed and now it’s ‘released’?

    If it’s in staging, and approved why tag it again? Just curious…

    Great series!!

  2. Rob Wilkerson said...

    I like to keep my interim builds separate from my releases just so that I have an explicit record of what is – and has been – available publicly. When I deploy to staging a “build” tag is created. If that version is approved then only a “release” tag is created when it’s pushed. A second “build” tag is not.

    I make it a point to never push anything to production that hasn’t at least gone through a cursory check on staging.

    Does that answer your question?