Was having lunch today with a friend of mine and one of his colleagues when the topic of my current work came up. I told him that I was working on a new feature of our product and had spent the last chunk of time integrating it with the existing codebase. Greg commented that if I was performing continuous integration I wouldn't have run into this problem. My reply was that we were and I went on to explain why I was having problems.
On the walk back to the office however, I thought some more about the question and it struck me that I'd misinterpreted it. On reflection I think that perhaps there are two ways that we could have completed this work and continuous integration means more than just good tests running in a continuous build environment.
Separate Implementation Method
This is the approach we took. Basically, we came up with a high-level approach, decided where we were going to hook it in, then built up the code to match the existing functionality (using a bottom-up TDD approach). We then (this is the situation I'm in now) tried to hook it into the exising code base, where I discovered we did not currently have access to required details.
Integrate Always Method
Using this approach we would break the system up front by integrating our new code directly into the existing code base. The more code we had written, the closer the system would be to completion. We wouldn't need to perform after the fact integration and we'd more easily know when we where finished.
Summary
In hindsight, we could have taken option 2 and saved ourselves the hassle. One problem with it is as we are working on a production system, we cannot break current functionality as maintenance releases are frequent and business often changes priority by pulling us off and on "sub-projects" according to their need. For us, this approach requires access to a separate source branch (which we have) in order not to break the system. To me this highlights some lessons I've obviously forgotten...
