But It Only Needs To Be Done Once!

Not true. The project that inspired me to write this book started out as a fairly straight-forward SharePoint site. One week before the deadline, however, it was a mess: bugs were only occurring on certain environments, code wasn't being checked in to TFS, URLs were hard coded, etc. I was pulled off my beautifully-deployable, smooth-sailing project to instead save another one which, as we love to say in the industry, had caught fire.

When I got the latest version of the code and deployed the solution in my local environment to see where we were at, I quickly uncovered two nasty (and all too common) issues: first of all, the thing didn't compile due to missing references; secondly parts of the site were created manually directly in the other developer's machine. Needless to say that it was one of those on-boarding nightmares where you get the latest, and then spend the rest of the day getting it to build.

Once I finally had the site up, practically nothing worked. I'd spend some time on a bug, only to find that the issue I was chasing down was being caused by a list not existing or a referenced user control that was never added to the Visual Studio project. After figuring that out, only then could I address the actual defect. So I started a little deployment script that grew with each bug I fixed to ensure not only that the logic was now working, but also that all dependencies were there for the particular piece of functionality affected by the bug. Before I knew it, I had automated the provisioning of over 75% of the site, and was well on my way to writing this book.

When it was over, I asked the developer, with as subtle a patronizing tone as possible, why he didn't script out the creation of any of the lists, sub sites, or web.config modifications that the core functionality of the site required in the first place. His response was that he felt it wasn't worth it to script everything out, since these tasks only need to happen one time. And to a certain extent, he was correct: the links list that backed a dropdown control in one of his web parts (for example) indeed only has to be created once in production so the users could have it...

And once in the client's test environment so the testers could test it...

And once in the client's dev environment so IT could see it...

And once in our internal dev environment so the PM could try it...

And once in our web designer's local environment so she could approve it...

And once in his local environment so he could build it...

And once in my local environment so I could debug it...

Can I write a feature receiver that provisions a list faster than I can log into seven environments and do it through the UI? You bet. And will I make at least one mistake copy-and-pasting column names, configuring views, and setting up security manually seven times? You bet. So beyond having to worry about deployment from the standpoint of getting code working on multiple servers, we also need to make sure new members of the team can get-latest-and-build so as to be productive from the their first billable hour on the project.

This is another example of a deployment tool only getting us so far. I love TFS and have championed it as not only the source control repository for developers, but also as the task manager for PMs, the bug list and test scripts for QA folks, and the CI infrastructure for architects. However, using TFS correctly doesn't alone cure the first-day-on-the-project blues; we need to consider intra-team deployments as well as server-to-server deployments.

I'll go into all the detail of some helpful methods and conventions when we start looking at code, but for now I want to emphasize the importance of the portability of your project among the members of your team. And this goes for all projects, not just SharePoint solutions. Never develop in a vacuum; even if you are the only person on a project, consider yourself a team of one. If you are an architect, make it a goal of yours that anyone in the company can hit a breakpoint in Visual Studio within five minutes of rolling onto your project.

And once this is all done, you can factor it into a utility project (discussed later) and reuse the hell out of it. Even though all applications are different, there are only so many ways to provision a list or add a column to a content type. My company has taken this idea and based our entire SharePoint project onboarding process around it. Everyone gets off to a great start with a home-grown Visual Studio template armed with hundreds of provisioning helper methods!