The randomnoun SDLC

The SDLC is the Software Development Lifecycle. It defines the various states that a piece of software goes through before you, the end user, get your grubby mitts on it.

Every software company has one, and everyone does it slightly differently.

Here’s mine, which I’ve taken the liberty of hyperlinking when I start using strange words.

• There are four regions, or environments [1]. These are:
  • Development (DEV): an internal region where the software developer writes, tests and debugs new code, typically in Eclipse.
  • Test (TST): an internal region used to aggregate all changes made by developers (if there’s more than one), to perform internal QA and integration tests before anything is seen by clients (where a ‘client’ here is the person or organisation who’s paying for the code to be developed).
  • Acceptance (XPT): a public region where changes to the application can be viewed by client management without being seen by the rest of the world. Clients perform their own QA in this region before approving the site to go live.
  • Production (PRD): the publicly-visible, “live” application

  I like to colour code these in vaguely the same order as the American Defence Condition colour codes, which I also justify by associating blue with development (which is borderline blue-collar work in my book), green for TST (since green is universally acknowledged as the colour for wonderfulness, inferring that anything you do in test is just peachy keen with me), reddish for XPT (since you really should have sorted out your bugs by the time it hits this region), and white for PRD, which is, of course, where no bugs ever occur ever.

• All randomnoun projects start out in DEV.
• Application code is migrated in the order DEV → TST → XPT → PRD
• Application data is initially migrated in the order DEV → TST → XPT → PRD, but is occasionally anonymised and reverse migrated from PRD back to XPT back to TST back to DEV.
• All projects are source controlled (usually in CVS), and dependency managed by Maven
• All projects are continually integrated (in bamboo)
• All projects have build artifacts stored in a repository (nexus)
• Some projects have issue trackers (in jira)
• All projects are deployed/migrated from region to region by vmaint
• All project servers have environments managed by vmaint
• DEV → TST transitions are performed by copying the latest “snapshot” build artifact from nexus onto the TST server, and performing any environment / database updates.
• TST → XPT transitions are performed by performing a maven release, then copying the release build artifact from nexus onto the XPT server (+ environment/database updates)
• XPT → PRD transitions are performed by copying the release build artifact from nexus onto the PRD server (+ environment/database updates)
• All projects have DNS assigned by randomnoun for internal (DEV, TST) regions, and by namingwords for external (XPT, PRD) regions
• All project servers are hosted by randomnoun for internal (DEV, TST) regions, and by AWS EC2 for external (XPT, PRD) regions
• All deployed applications are capable of reporting their maven release numbers (and bamboo build numbers, if applicable)
• All project servers are monitored by vmaint, nagios, munin and MRTG
• The user interfaces of all web-facing projects are HTTP monitored by vmaint, nagios, and some by pingdom

So anyway, that’ll probably do for now. I’ll probably write up some more enthralling text on the individual bullet points above at a later stage.

Stay tuned.

[1] much like the 7 stages of man, or, probably more accurately, the 5 stages of grief, which at least has acceptance in there somewhere.