Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control. (source)
Should your project/team use CI? Yes, yes, yes. This is one of the key feature of using an automated build process.
This is how a build definition for CI that will only compile our codebase looks like:
Only the prepare and build steps. Then we need to go to the “Triggers” tab and enable the CI option:
Right after each developer check-in, a build will be queued, and the code compiled. In case there’s a compilation error we’ll be notified about it. Of course, we all build the solutions before checking them in and don’t need this CI build. Right?
And because we all know that “Slow and steady wins the race”, but at some point during a project that’s not possible, so this kind of build definition can help us out. Especially when merging code between branches. This will allow us to be 100% sure when creating a DP to release to production that it’ll work. I can tell you that having to do a release to prod in a hurry and seeing the Main build failing is not nice.
