Continuous Deployment - Neat Idea, but not generally applicable

Continuous Deployment, as I interpret it from this particular article, is basically automating your production pushes to come straight from your Continuous Integration environment with NO human intervention in between. I will leave it to you, the reader, to check out the full article before continuing reading my post.

To paraphrase the author, this method of development involves building and testing all commits in your Continuous Integration environment followed immediately by an automated deployment in to your production environment automatically, and that such a methodology actually encourages very strict and rigorous automated testing and discipline from developers. I believe him. It is a lofty goal and is an extremely neat concept. There are cases where I'd probably see myself recommending and implementing such an approach - think of a smaller start up with limited resources whose production systems don't necessitate 24x7 availability or correctness according to a specification (perhaps Twitter in the early days?).

However, in the general case, I don't know if Continuous Deployment is such a wise goal - at least to a production system. I for one don't even encourage it in my own shop to our development environment since I want to maintain some semblance of stability in that environment where deployments are timed and roughly scheduled simply due to the number of disparate groups who rely on them for testing and working on their own components and systems (this is a side affect of an SOA architecture). Continuous Integration encourages constant integration somewhere, which means deployment ought to be happening somewhere for automated integration testing - to me that environment shouldn't be to your production environment. I for one think that automated deployment followed by automated integration testing should be segregated from live environments consumed primarily by humans, be they developers, testers, business users, or external users/customers. Most organizations have environments containing specific versions/combinations of their systems, each with different roles according to their development process. Updating one automatically at the point in which any developer makes a commit is too loose for an organization of larger size with many systems and many teams where there is usage and testing (manual or not) of a given environment going on seemingly at all times.

That's not to say that deployment shouldn't be automated... it should. But the ability to deploy, in the general case, should be held in escrow by a human to at least enact a deployment on a push button basis. Otherwise, I believe too much burden (that being almost all) falls on the developers for owning deployments to an environment - a task they should be mostly decoupled from.

There is something else that rubs me wrong about Continuous Deployment. There aren't multiple validation factors being applied to the sanity of a given build. Automated testing, be it unit/integration testing at build time or monitoring via an alert system (e.g. Nagios) is indeed quite awesome, but it shouldn't be the only check. Automated testing, much like manual testing, is fallible because it too is ultimately orchestrated by humans (someone has to write those tests!). One method of testing by itself can't be trusted - I have seen it all too often where an automated test picked up what QA guys did not catch (or picked it up much more quickly) and when QA guys spotted failures that the automated tests did not account for. Going full hog on Continuous Deployment gives you a single point of failure on testing, and in my honest opinion, is no more reliable than manual human testing by itself where correctness is concerned.

Again to summarize I think Continuous Deployment to production is a neat idea and applicable in certain cases - but I wouldn't suggest getting all hot about it unless you are willing to accept the risks it might bring with it to your organization.

IRC - The Online War Room

My last post, Bootstrapping a Development Team, drew at least one comment from my friend waz. He suggested that a team also needs a synchronous communication mechanism such as IM or IRC - a virtual water cooler.

I made the mistake in my last post of taking internal communication for granted and did not make mention of the means a team may take to synchronously communicate to one another online. I have long been a member of the converted, spending lots of my online time on irc in development related channels (mostly public channels on freenode) and have even used irc as a major communication mechanism for the last year long project I was involved. I thought it was a wonderful tool for the job - especially given the amount of remote development we were conducting.

However, when explaining my usage of irc for professional and development purposes to non irc denizens, I could never find the appropriate analogy for it. I can thank Neal Ford for giving me one now. During Ford's leading keynote at TheServerSide Java Symposium '09, he talked about developer productivity and how cube farms are detrimental to developer productivity. I couldn't agree more. Of course, every developer would love to have their own office space, but this is not possible given limited office size. So instead he explained the concept of a "war room", or an open room full of nothing but developers where the only conversation revolves around the project - it is pretty popular over in the Agile world, it seems.

So what piece of technology can encompass that same concept for communication? It is not IM and email, which are so riddled with non-development noise that it is hard or impossible to filter and can easily lead to distraction for the concentrating developer who is short on time and has precious mental cycles to spare. The best solution would be irc. It is synchronous, channel based, filterable, and most clients support nick highlighting so that only messages directed to you are highlighted - easily allowing a conversation to take place within a conversation. I'd take it one step further than the virtual water cooler analogy that was given. I dare say that irc is the quintessential online war room for developers. I would also ammend my previous list of things needed to bootstrap a development team and place irc as a must have.

Bootstrapping a Development Team

I have been trying to have brainstorming sessions lately. Basically, I give myself about five minutes everyday to brain dump tons of ideas on how to solve a particular problem or how to come up with a creative use of a particular tool or platform. One day, I started pondering all of the technologies I would need, outside of personal machines, languages, and developer tools that I would need if I were to bootstrap a development team.

Here's the list I came up with:

• Essentials:
  
  • Issue Tracker - You need to have a bug base of some kind when developing software. This can double up as a task management/monitoring system also.
  • Version Control System - I'm of the opinion that no development on any project should be done without some form of version control.
  • Wiki - Use this to encourage documentation of everything.
  • Continuous Integration - Gives your team a one-stop shop and authoritative source for producing and unit testing your builds.
  • Backup solutions and Disaster Recovery plan - Make sure everything that is critical to your project development and release to the outside world can be recovered in less than a couple of hours maximum (and even less depending on what it is that you are doing).
    
• Essentials for Web / Server-side projects (since there will be N number of servers to work with):
  
  • Server Management Tool - Use tools like Puppet or Capistrano to automate as much as you can regarding server setup.
  • Server Monitoring - Central system to handle the monitoring and alerts for when your systems reach an undesirable state (for example, Nagios)
• Sorely needed, but not deal breakers:
  • Test coverage tool - in this day and age, anyone writing code ought to be aggressively writing unit tests. It is very useful to have metrics to see how effective your unit tests are.
  • Code review tool - code reviews are extremely useful, but also time consuming when done formally. Having them conducted asynchronously in some kind of server side tool would help streamline the process.

I tried on purpose to not mention any specific technologies in this post, with the exception of server management since most folks may not be familiar with what I was talking about. I may do a little "best of breed" or "most bang for your buck" case study later at some point to discuss the various implementations of the aforementioned technologies.

What are your thoughts? What would you include or exclude from this list?

Adding Environmental Variables to Netbeans

Short story - I loaded a fairly large multi-module maven project into my Netbeans 6.5 IDE and hit an OutOfMemoryException when running `mvn clean install` on the parent pom. Simply put, running all of the goals on this project requires more than that default 256m of max heap size that automatically gets allocated for maven. It is an easy fix when running mvn from your shell - just use:

`export MAVEN_OPTS=-Xmx512m`.  

Unfortunately, the maven configuration in Netbeans doesn't allow you, through menus at least, to set this. In order to set environmental variables such as this, you'll need to add them to ~/.netbeans/6.5/etc/netbeans.conf. E.g.:

jwhaley@thirdeye:jwhaley$ cat ~/.netbeans/6.5/etc/netbeans.conf 
export MAVEN_OPTS=-Xmx512m