We spent the last year or so building and maintaining a Continuous Integration (CI) system for our major development group. And it was incredibly daunting and frustrating, considering we had to build it around a legacy and problematic version control system like ClearCase Base.
In the textbooks it seems pretty simple: every commit (check-in) to the repository triggers a build, which in turn checks out the latest version of the repository from source control, and run the build process. This way, if a build fail, you know exactly who broke the build – the person who performed the last commit – and if it the build passes, you have full traceability between the build artifacts and the source code they were built from.
Now, let’s try that with ClearCase Base.
I spent the last week watching some ClearCase migration webinars and talking to some vendors. My first conclusion is: everyone – even IBM – want you to migrate from ClearCase, and will gladly explain why. Then, they will explain why you should choose their tool over the others. And lastly, they will happily do it for you since apparently they all have vast experience in migrating customers from ClearCase.
Although, I must say, a couple of the ‘smaller’ vendors did say that we should focus on mapping our processes first, then choose a tool which can accommodate this process. This is actually a major paradigm shift: from a file-based development to a process-based development.
So maybe that’s what we’ll do next: try to map the development process. In our case it would be the branching & labeling strategies, which are slightly different between the various development teams here. I expect that, once the process it laid out, we can devise the relevant use-cases, which will help to compose a list of requirements, and test scenarios.