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