Thoughts on Application Lifecycle Management (ALM)

The cornerstone of a strong ALM process is based in Agile practices and principles.  Iterative software development is useful for breaking work up into small chunks that provides fast and frequent feedback to both the team and the customer.  Developing software using test driven development (with an emphasis on behavior driven development) allows developers to focus on behavior first as well as quality.  Developers will iteratively evolve the design of the software based on the tests, and will limit the amount of up front design.  Automated tests are executed as part of an automated build process that is in turn executed by a continuous integration server monitoring version control.  Developers should be checking in their changes frequently, triggering multiple builds, resulting in multiple feedback cycles.  All development should take place on the trunk in version control and branching should be limited.

Taking ALM a step further lies the continuous delivery practice of deployment pipelines.  Like with standard continuous integration, each change to source triggers a new build on the CI server.  With deployment pipelines, you are chaining together a series of builds, each responsible for validating a certain condition or set of conditions (like acceptance tests or coding style).  Each build should expand on the previous with an increasingly rigorous criteria.  The goal of deployment pipelines is validate a change to source to see if it is production worthy, i.e. a release candidate.  In some environments, deployment pipelines are automated all the way to production, where a change from a developer can go to production without a single person touching it.  To achieve this, automation and feedback are essential.  Unit, Integration, Acceptance and Performance Tests must all be phases of the deployment pipelines with rigorous criteria to keep a build out of production that doesn't meet the standard.  Managing code is also an essential part of the pipeline, which is achieved using static code analysis tools. In addition, automating the deployment of the application from source to the Dev, Test, Staging and Production is also an essential practice.

In regards to tools to enable this process, it is hard to come up with a list without assuming certain technologies and biases for/against open source.  For the sake of this discussion, I will assume a Java application where open source is king.  For version control, Subversion gets the job done, but distributed version control systems (git and mercurial) are extremely popular and gaining ground.  For Agile project management, unless you are on a distributed team, I recommend sticking with cards and a scrumboard and avoid complex tools.  For testing, there are a multitude of tools available, JUnit being the core of the testing world.  Mockito is an excellent and simple mocking framework, but JMock provides some valuable features not found in Mockito.  Selenium is a great web application testing tool (but avoid recording and use page objects), especially when coupled with a BDD framework like easyb or JBehave.  JMeter is a great tool for performance testing.  For build tools, I feel that Gradle or Buildr are better than Maven, which is better than Ant.  Gradle/Buildr build on the legacy of Maven and Ant and improve on them in different ways.  For continuous integration, I highly recommend using Hudson/Jenkins for most environments, but it lacks some of the advanced deployment pipeline features you can find in ThoughtWorks Go product (not FOSS).  For measuring code quality, I recommend Checkstyle, PMD/CPD, Findbugs, Crap4j and Cobertura for measuring code coverage. I also highly recommend Liquibase for database management and a tool like Puppet or Chef to manage your infrastructure.  In addition, I also recommend using Nexus as a binary repository for build artifacts produced in the pipeline.