based on conventions, coupled with a moderate nuisance factor of tweaking those conventions, can dramatically change user behaviour. Initially, for instance, many of those new to Maven spent quite a significant amount of time, and produced a fair amount of XML, to change the standard settings to match their own environment, naming conventions, file paths etc.
Pretty soon, though, and especially as the ratio of green field vs. legacy projects increased, it simply became easier to stick with Maven's standard values and be done with it. Today, these conventions have become so standardised that they are supported not just by Maven, but essentially all other build systems out there, too.
It's not just users' preferences that were "charmed" into adopting standard conventions, though. In many cases, company standards previously seen as cast-iron were progressively discarded or modified if they could easily not be accommodated by the emerging de facto standards. Ease-of-use was able to triumph against abstract rules.
So much for the build process. What about deployment, today's critical hurdle for automation in the business value delivery chain? As previously mentioned, the current industry average is somewhere between "black box" and "step sequence". In terms of the descriptions of the build process evolution, the most advanced deployment automation systems are somewhere just beyond "reusable commands", in other words.
Which naturally begs the question: how do we get to a push-button state? What do we need to do to be able to reach the maturity level of build today?
Looking at what we encounter in the industry today, three critical aspects will be:
- Develop a common model
- 2. (Re)discover vanilla
- 3. Support a "clean build"
Develop a common model
Before we can advance to the 'model' stage, we first...well... need a model. Thankfully, a very simple one can suffice: Packages, Environments and Deployments.
There's nothing particularly magical to this, and indeed the concepts are commonly found in all organisations. But giving these things explicit labels helps not just formalize the ideas and gives developers and vendors something to support. It also creates a shared vocabulary and language around deployment, which is the first step to shared understanding and reusable functionality.
Indeed, the concepts are so basic that there does not appear to be much to say about them. Packages capture the components of the versioned item to be released, both artifacts represented by actual files as well as configuration, resource settings and metadata.
In accordance with release management best practice, packages should be stored in a DSL and should be independent of the target environment, so that you have one "gold standard" package running in Development, Test, QA and Production.
Packages also mean that we can version everything, not just the application binaries but also the related configuration and environment settings.
Development and Test just mentioned are examples of Environments, simply collections of infrastructure - physical, virtual, long-running, on-demand, whatever - that applications run in as they progress through the ALM cycle, potentially with approvals or other checkpoints governing the transition from one to the next.
Deployment, then, is perhaps the one concept not immediately widely understood. A Deployment represents not just the activity of getting a Package running in a certain Environment, with a start and stop time, executing user, status and so forth.
Rather, a Deployment also documents the way in which the Package's components have been deployed and, if applicable, customized. For instance, a Deployment will record that a certain EAR file in the package has been deployed to the following set of target servers or cluster, or that