We’ve also . . . → Read More: use continuous integration, but what about the customers?]]> We continue to integrate more and more of Extreme Programming in our development process. One of the things we’ve found particularly empowering is continuous integration.

• don’t branch your code
• only commit things that work
• in order to do a bigger project, break it into incremental pieces so it works the whole time

We’ve also added a requisite code review by another team member for anyone committing to our repository.

By doing this we don’t spend time doing

• we avoid time-consuming integrations
• we avoid a long QA process
• we avoid “throw the first try away” instances (sometimes this is still the best way to go, but it’s no longer the default)
• Most importantly, we force design to occur earlier rather than later.

All of this has improved the overall quality of the commits to the codebase and the thought that goes into them. We have fewer patches that are more likely to fix/solve the intended problem. In all aspects of the process, it’s been welcome to the developers, the maintenance team, and most of all the customers.

Unfortunately, we’ve been unable to get to a fully continuous deployment process. The quality and smoothness of the deployment hasn’t reached a point where we can simply apply the latest changes from our repository to our production servers. The problems we’ve found are:

• changes from the development team are very well tested and likely working, but we’re not completely sure
• necessary changes to the system outside of the code

• configuration file changes
• database schema changes
• additional daemons/services

In order to alleviate these problems, we still apply patches to our production code, which one might call a branch, but I prefer to call it a projection of our codebase. Since it doesn’t evolve on its own, rather only a subset of the commits to our repository. How can we bridge this gap? Is that the job of the QA department?
[tags]xp, continuous integration, qa[/tags]