• automated user acceptance: Currently continuous deployment is mostly (only?) used with online off-the-shelf applications that don’t have a customer (=user) acceptance test phase. So, with bespoke software development for a specific customer you might only be able to automatically deploy as far as a UAT environment.
• security requirements: You could write a test for every possible group of attacks you can think of and run them against your running application.
• interfaces between companies: These interfaces should hopefully be clarified before testing an application. In any case issues regarding these interfaces can be detected by automated end-to-end tests.
• user documentation: OK. You got me. I don’t have an answer for this one. However, I don’t really see user documentation as part of the deployed piece of software. Probably because I am a developer and I like to write code, not documentation. Don’t get me wrong, I understand that user documentation is an important part of any application, but it doesn’t influence if the application itself is correct or not. It is an accessory that helps the user understand and use the application, but it is not part of the application itself.
• releases spanning multiple applications: Again, any issues here can be detected by automated end-to-end tests against all participating applications.
• no developer touches life system: I don’t know why you would have a requirement like this in the first place, but let’s say you do. As I see it there are two givens here, (a) your code is developed by developers and (b) your code should eventually end up in your production system. Let’s for a moment assume that you can automate all testing, then you would want to eliminate all manual steps between the developer committing the code and the code being deployed to production. And that is exactly the idea behind continuous deployment, to get rid of unnecessary manual steps. So, technically when doing continuous deployment the developer is not touching the life system any more so as he did before, it’s just that the manual steps in between him and the life system have been automated.
• testing the tests: There are different categories of tests, unit tests for your code units, end-to-end tests to test your running application and anything in between. These should hopefully cover for each other to some extent. But you are right, if your tests are crap, then they don’t say anything about your application. In my opinion, continuous deployment can only work together with test driven development and a very disciplined team that is experienced with developing this way.

I would like to make it clear once more: When talking about automated tests I am not just talking about unit tests, but also about functional tests that test your deployed and running application. Furthermore, doing continuous deployment requires a high level of discipline from a development team that knows what they are doing.

Interesting Idea, but how to automate user acceptance? How to automate security requirements? How to automate interfaces between companies? How to automate updated user documentation? Or production docuemtnation? How to guarantee that release units spanning multiple applications / dev groups with different policies work together well? How about the requirement that no developer ever touch the life systems? If it is automated, this is equivalent to direct access? Who tests the tests? And how?

I don’t mind having a simple & lean release process, but aiming at a fully auztomated process where a developer commit updates the production environment after X automated tests is not a quility target.

I’m currently using Gerrit (http://gerrit.googlecode.com/) and Hudson for something like this. Current workflow is something like this:

1. Change is pushed into Gerrit
2a. Hudson notices the change and runs a build reporting results to gerrit (http://blog.hudson-ci.org/content/pre-tested-commits-git).
2b. Change is manually reviewed and tested. Reviewers/testers can pull the change for gerrit for testing.
3. If change is good, ie. Hudson job is success and reviewers show green light, change is submitted to Gerrits main repository.
4. Hudson notices a new change in Gerrits main repository and deploys a new version into beta server.

I tried to explain this with flow chart in little blog post http://softwarefromnorth.blogspot.com/2010/04/almost-continuous-deployment-with.html

I’m using beta server because our customers didn’t want to have this on live server. Beta and live server are swapped biweekly, though, meaning that beta comes live one and live server is cleaned.

this software life-cycle process demand sounds familiar to me. That is a common wish of customers.
In a SOA landscape this topic is known under ‘Governance’. Life-cycle management is part of it. But its not only good for SOA. If your software landscape consist of many artifacts, you need a solution to ‘govern’ it.
Governance tools allow do design a life-cycle process for every artifact. For every process step you can add design time polices. That can be approval policies as you mentioned or notification jobs.
From my experience that is still a very theoretical topic. Although there are software solutions for this, I have never seen any in production. And unfortunately I don’t know an open source solution for it.
In the near future I have the challenge to build up such a life-cycle management for a customer. Maybe I can contribute some hands on experience then.

Viele Grüße,
Jochen

I am happy to say that yes, I think, I have been able to stay friends with my former boss. I was in fact out for dinner with him last night and I am still managing to keep in touch with many of my former colleagues by having the occasional lunch with them and by making the odd appearance in the company’s football team.