Imagine this workflow...
- You open your project in your IDE.
- The IDE automatically updates your working copy with any new changes on the server.
- You begin your work, using TDD or "test after".
- You run your tests and they pass.
- The locally passing tests trigger the process of your changes being sent to the CI server.
- The CI server does a full build + test run.
- If the full build/test completes, your changes are automatically committed to the VC server. The commit message is the concatenation of the new test names.
- Your teammate's IDE polls the VC server for changes once per minute, and automatically updates his working copy when new changes are available.
- His IDE is smart enough to merge changes in a way that does not disrupt his typing. Projects are updated "silently" and merges are performed successfully even with files that are open with unsaved changes.
- This process is repeated thoughout the day between all team members.
The concept here, is that passing tests trigger integration. The benefits are less excise of having to do updates and commits, as well as a better sense of "trust" in the latest version because it is always compiling and passing tests. The test-driven commit encourages effective test writing.
This obviously puts the burden on the codebase to be testable. Some parts of the application, UI for example, are notoriously difficult to test. This "Continuously Integrating Version Control System" (CIVCS) would need ways to manually trigger commits as well. Plus for updating non-functional parts of the application, such as your spinning company logo graphic.
Also we need an IDE that can load changes to a project file without interrupting the user. VS 2005 is horrible at this. One way to cheat this would be for the CIVCS IDE plugin to simulate the changes being made manually though the UI.
There are a few places where our currently tools aren't quite ready to make this a reality, but I don't think we're that far either. I image it would be rather easy to add a feature to Resharper's test runner to trigger a process if all the tests pass. TeamCity already has a feature to do a "pre-tested commit." Determining new tests should be as easy as comparing all the test names to the previous build's list of tests. Polling for changes... trivial. Merging changes without interrupting the user... ok we need to work on this one. The "only tested code" concept could be handled with a branch that gets sync'd with the main branch. Most of the puzzle pieces are there. We just need someone (*cough* Jetbrains *cough*) to put them all together. Thoughts?
04-03-2008 9:39 PM