January 31, 2014

The Importance of Continuous Integration in SharePoint Development

Continuous Integration is a wonderful and popular practice in the software development universe. Yet, for whatever reason, it seems much less commonly utilized in the SharePoint community. SharePoint (naturally) throws a few wrinkles into the process, but no substantial roadblocks, and the benefits of CI can be realized just as well on SharePoint projects as anywhere else.

I'll be writing a series of posts detailing the various steps of building out a CI process, but first let's just start off with an introduction to what Continuous Integration is all about, and when it can be most helpful.

A "complete" CI process should incorporate all of the following points, but implementing even just a few can lead to substantial increases in quality and efficiency.
  1. Task management (via TFS or another tool, integrated with your code repository)
  2. Automated builds
  3. Unit testing (of all code, server-side and client-side, preferably via test-driven development)
  4. A stable staging environment (which accurately mimics production!)
  5. Automated deployments
  6. Reporting/communication of build results
Automated builds save time and (assuming results are adequately communicated) ensure that other developers on the team won't have to deal with build errors caused by someone else. Unit tests help ensure that the code doesn't just build - it actually works. Linking code check-ins to documented tasks helps to quickly identify issues and their owners. And regular, automated deployments to a useful staging environment greatly reduce the risk of problems in production.

That sounds great, but obviously it takes time to write unit tests and build scripts, take snapshots of production to restore into staging, and keep tasks up to date. So is CI really worth implementing on every project? No - but it's typically a worthwhile investment in projects with:
  1. Multiple developers
  2. Medium-to-long timelines (not "one-off" projects), or frequent deployments for QA/UAT
  3. Complex codebases (e.g. a large number of Visual Studio solutions and projects)
Even for relatively simple projects, the initial effort required to implement a CI process can greatly reduce the length and effort required during the testing phase. You'll have fewer bugs to fix, and you'll be able to truly focus on resolving defects without having to constantly do manual builds and deployments to close things out.

SharePoint may sometimes complicate things, but it shouldn't stop us from following best practices in our development. Continuous Integration can help ensure quality, efficiency, and environmental stability. So let's start doing it!

If you've had any particular challenges with implementing CI for SharePoint, or any concerns around CI in general, I'd love to hear about them. I'll do my best to address any issues in future posts.

No comments:

Post a Comment