In this chapter, I provide an approach to establishing a disciplined code promotion and deployment process. I provide considerations for planning for change management and designing a release process that encourages maturity and discipline. I also introduce concepts related to automated integration testing, promoting code through testing and staging environments before deploying to production, and building rollback plans.

A key point I stress in this chapter is determining your tolerance level for deployment risks and consciously designing your release management process around that so it is the right balance and fit for your needs and situation.

After reading this chapter, you will know how to:

• Plan a code promotion process through different environments
• Automate builds and integration testing
• Determine your tolerance for deployment risk
• Build your release management maturity
• Design a user acceptance testing environment
• Implement a change management process
• Plan for rollbacks of customizations

Promoting Code Through Environments

There is a reason why you would not let developers develop and deploy their solutions directly in your production environment, and that is because you do not want them to interrupt service while they are working through issues and trying out ideas. Instead, they can develop and test in isolated environments and then a release manager can deploy their solution to the production environment in a managed and controlled way once the solution is stable and ready. This process of moving code through different environments on its way to the final release is what I call code promotion.

I use this metaphor in a similar fashion as you would for job promotions: as a regular worker performs well in their current role, they eventually get promoted to a new role with more responsibility. Similarly, as a developer’s solution performs well in a preproduction environment by passing tests and proving its stability, a release manager can promote the solution into the next environment for further testing and preparation until it is finally promoted into the production environment and released for use. This offers you a release process that physically separates development and testing from production use, and this helps you to keep your production environment more stable as a result.

You use different environments through the code promotion process to move the release testing conditions closer and closer to the production conditions. This process reduces the risk that a customization will break the existing production environment because it tests the compatibility before you release the solution. One reason why you need to test the compatibility is because there could be a gap between the environment your developers build their solutions on and the production environment where you will ultimately deploy their solutions.

It would be expensive and it would slow down the development process if you maintained an exact duplication of the production environment and its data for each development environment. Instead, you need to compromise and give your developers an environment that you optimized for the development process. Usually this means that your developers do development on a single isolated server without any or very little data. However, before you release any solutions, you also need to test compatibility with the production environment at some point as well as compatibility with other custom solutions in development.

If you have a team of developers, you have to merge the different solutions your developers are currently working on, since they each are developing on an isolated server in their own development environment. The only way to merge their changes as they go is to have them develop on the same server in a shared development environment, but this would end up having developers interfering with each other. For example, one developer might package and deploy a solution to try out some functionality he or she just built, and this would trigger an application process to restart and cause the system to slow down unexpectedly for the other developers on the server. Hence, most developers do their development on their own isolated development server or virtual server.

To keep all these development environments lightweight and optimized for productive development, most developers also do their development without any content, or at least without a complete copy of the masses of content in the production environment. This helps to keep developers productive and their environment lightweight, but somewhere in the release process you have to bridge the gap between the lightweight development environments and your production environment. As I mentioned, I bridge this gap through a process I call code promotion.

Code promotion takes custom solutions and gradually promotes them through different environments to move the test conditions closer and closer to the production environment. This allows your developers to be productive while it mitigates the risks involved with having development environments that are not identical with your production environment. How many environments that you use to promote your code through will depend on your own processes and how disciplined and thorough your testing procedures are. The following lists some examples of environments you might include in your code promotion process, progressing from an isolated development environment to move closer and closer to conditions that mirror production, and finally into the production environment itself:

• Development environment
• Build or integration environment
• Test and quality assurance environment
• User acceptance testing environment
• Preproduction or staging environment
• Production environment

You can certainly expand or contract this list of environments based on your own needs and your processes, but this should help to get you started with what environments you might include and what your code promotion process can entail. Two environments are obvious and standard for any development team: the development and production environments. For me, the integration environment is the next critical environment, because this is where you can merge all the custom development from each of your developers to ensure the solution continues to build after any changes and that any automated tests continue to pass.

Automating Builds and Integration Testing

This is one of my favorite steps in the entire development process; yet I rarely see teams adopt it and take full advantage of its potential benefits. The more you can automate, the better; and the more feedback you can garner from an automated process and automated tests, the higher quality your end product will be. Integration is the stage to have the system perform any automated work to provide constant feedback on any bugs or inconsistencies it catches early. It is automated, so that means you do not have to think about it unless the process flags an issue for your attention. However, it does require some upfront planning and configuration to set up a highly functional and automated integration stage, and this might be why some people skip over or minimize this step in their release process.

The integration stage offers you an opportunity to implement an automated build and continuous integration process. This will help you merge all of your developer’s code together frequently – at least once per day, but ideally after every check-in. Adopting an automated process will help you catch compatibility issues early, and if it detects an issue, the system can open and assign a bug to the developer automatically.

An effective continuous integration process requires developers to check-in any of their changes frequently during the day. I have been on several development teams where the developers check-in vast changes after long stretches of developing functionality and affecting many files in the solution. Do not do this; check-in small changes and often. The smaller the changes and the more often everyone checks in their code, the easier it is to merge changes together and maintain compatibility. Frequent check-ins also means frequent change sets in your source code repository, and this means that you will have a greater granularity of options to rollback code to a previous state. Similar to how frequent database backups help you to minimize any data loss, frequent check-ins and change sets help you to minimize any loss in the code your developers produce.

It also enables a development team to work with a high degree of concurrency. Rather than a single developer locking a file or series of files with an exclusive check-out lock so they can make a lot of changes without worrying about merging the files later, several developers can check-out and make small changes to the same file concurrently. By checking in their small changes often, they will not face a significant burden to merge their changes. And better yet, everyone’s changes are frequently merged and integrated with each other, giving your team constant feedback on their code’s compatibility.

I like to perform an automated build every time a developer checks in code to the source code repository, and if something breaks or causes a failed build, the build process can create a bug and assign it to the developer. I usually do my development by creating unit tests, as I code in a test-driven development fashion similar to how I described in Chapter 14, and with these unit tests checked in, I set the automated build process to also run a suite of automated tests. If a test fails, I have the build process create a bug and assign it to the developer checking in the breaking change.

Unit tests can come in many flavors. Most are quick to execute and they do not require any additional resources beyond the processing of a couple methods. These are those lightweight tests that use mock objects to test a specific unit of functionality. This tests the bulk of your solution’s functionality and you can execute them frequently and the testing process will only take a few seconds. I group these tests into a suite of fast executing unit tests and these are the tests that I run frequently during my development process. These are also the tests I configure the automated build and integration process to run after each check-in. However, I also want to create automated tests that take longer to run and test other things, such as tests that validate the mock objects by using the actual objects and testing functionality that interacts with the heavier system and network resources.

In addition to unit tests, I also create tests that test a greater scope of functionality than a unit test. The following lists some of the automated tests that you might create and include in your solution:

• Unit tests
• Continuous integration tests
• Web user interface tests
• Load tests

Some of these tests are lightweight and can execute very quickly; others involve additional resources such as database connections or long running processes and they take longer to execute. I generally organize my tests by first dividing them based on how quickly they execute. I might also group and organize them by additional factors based on things such as the test type or feature area, if organizing by granular categories is useful. I organize and group my tests by creating different test suites in Microsoft Test Manager within Visual Studio. This allows me to configure the build process to run those quick tests in a designated test suite as part of every automated build process when a developer checks in code. This keeps the build process running efficiently during the day with frequent code check-ins. I then configure another automated build that I schedule as my team’s daily build, and during this build I have the process execute the other longer running test suites as well.

These different types of automated builds offer a reasonable compromise between thorough testing and a high performing continuous integration process. This compromise is still current and provides constant feedback, as it has a daily build that executes each automated test alongside the build for every check-in that executes a subset of tests for those fast running unit tests. You will catch most of the breaking changes with the unit tests you include in the suite that runs after each check-in. For all the rest, you are never more than a day away from the system identifying a breaking change with a failed test. And if a developer is ever unsure if they just introduced a breaking change and they do not want to wait a day or two, he or she can queue a daily build on demand or execute a suite of tests in their development environment.

If you use Microsoft Team Foundation Server (TFS) as your source code repository and configuration management system, then you have an excellent application lifecycle management tool to automate your build and integration process. You can deploy SharePoint environments with the TFS build agent, and then you can configure build processes to use those build agents and automate a deployment to an environment. You can also configure a build process to take additional actions after a build, such as running a test suite or performing code coverage analysis for your tests.

Figure 16-1 illustrates the continuous integration process and the relationship between the development environments, Team Foundation Server, and your integration environment. As a developer checks in code to the source repository, it triggers an automated build in the integration environment. The build process compiles the solution and deploys it to the SharePoint integration farm, and then it executes automated tests to validate the solution. If the build fails or any tests fail, the build process opens a bug and assigns it to the developer who checked in the breaking change.

I find a disciplined and automated integration process can make a significant difference on the quality of the overall solution that developers produce. My ideal process includes a continuous integration of code as developers contribute to the solution. It also includes a constant accumulation of automated tests, such as a suite of fast processing unit tests that the system can run after each check-in and suites of longer running tests that the system can run during a daily build cycle. This builds out a great procedure to contribute to your deployment risk mitigation strategy, but whether it is a fit for your team and processes depends on your tolerance for deployment risk. If you have a high tolerance for risk, then you may find building suites of automated tests add too much overhead to your process. Conversely, if you have a low tolerance for deployment risk, then you will find the automated tests catch problems and mitigate risks long before you release code to production. In the next section, I look at tolerance for deployment risk in more detail.

Understanding Your Tolerance for Deployment Risk

So far in this chapter, I have described a formal and disciplined process for deploying any customization into a production environment. You can even get more disciplined and add more rigor to the process. At the same time, you might have less or none at all. You might just want to crank out solutions without any testing and deal with any issues or inconsistencies as your users discover them as they use the solutions in production. Although that is not my approach, I do know a lot of people who conduct their release management processes with more ad hoc and loose (or non-existent) testing procedures. These types of people have a higher tolerance for deployment risk than I do.

I sometimes refer to a high tolerance for deployment risk as running with a cowboy mentality. This comes from an image of a cowboy in the old Wild West, riding a horse through prairies and making decisions on the fly. The cowboy rides free, exploring the west without any supervision or formal processes. They explore and they react. Cowboys get the job done, one way or another, often through quick decisions and immediate solutions, and through their own stubborn notions of how to get things done. They do not mind things going wrong, because mistakes happen and they will fix them if they do, but they do not want to waste time worrying about the details when they can implement solutions instead.

Some people have a high tolerance for deployment risk and they would rather deal with issues if and when they come up rather than slow down the process. These people may feel comfortable with developing changes directly in production without performing any testing. Of course, when things go wrong, they will feel stressed just like anyone else, but they fight through the issue until they are finally satisfied with the solution. This is just their process and approach because they either do not know any other way or they are comfortable with their high tolerance for deployment risk.

Other people have a low tolerance for deployment risk and they would rather minimize any change rather than risk introducing an incompatible change and breaking their production environment. They will only feel comfortable with a formal and thorough testing and release management process, and even then they still might not be at ease with a release. If the cowboy is the carefree roamer who deploys changes on the fly, these other folks are the settled and stable rocks who maintain reliability with their low tolerance for deployment risk.

Everyone else will fall somewhere on the spectrum in between the high and low tolerance for deployment risk. Where you and your organization falls will determine how formal your testing and release management process will be. The following lists some questions to help you understand your own tolerance for deployment risk:

• Do you insist on deploying every customization to a preproduction environment before you deploy it into production?
• Do you separate the development and testing duties into different individuals?
• Do you have a formal and predictable testing process for customizations?
• Do you follow a change management process that you use to plan and track every change?
• Do you generally feel confident that a deployment will go as you planned?
• Do you have a rollback plan?

The more of these questions that you find yourself answering no to, the higher I would say your tolerance for deployment risk might be. This is not necessarily bad or uncommon, as I have worked with many clients who could probably answer no to most or all those questions. Some people just work that way and they do not want to get bogged down in process or they cannot afford to delay releases with any extra testing, as in this case the costs of doing so would be higher than the costs of introducing bugs. They are probably aware that things can go wrong and they just accept the risk because they are more interested in deploying new functionality quickly.

If this sounds like you and you are satisfied with it, then I am satisfied and I will leave your processes up to you. For me, I would find this too stressful and chaotic. I would want to add some formality and process to increase my comfort level. Basically, what I would do, and what I have done, is work on increasing my release management maturity. In the next section, I share some tips on how you can build your own release management maturity.

Building Your Release Management Maturity Level

You can build and evolve your level of maturity for release management by refining your processes and adopting disciplined procedures throughout your entire application development lifecycle. A mature release management process relies on your development and testing standards, such as those I discussed in Chapter 14. It also relies on automation and a configuration management tool that facilitates the disciplined and desired behaviors you want.

The configuration management tool I use is Team Foundation Server (TFS), which allows me to define workflows and processes, and it provides a rich set of automation capabilities. TFS is just a tool, so you cannot expect to deploy it and have it magically fix any broken development processes. However, it does integrate work item tracking, test suite management, build automation, and other features with the source code repository. This level of integration between the rich toolset can add a level of maturity to your release management process.

With the right tools in place, you can continue to mature your release management by defining different processes and establishing different automated steps in the process. TFS can enforce or support your standards, and this helps to hold the quality bar high for the team. Furthermore, it helps with onboarding new developers to the team and the team’s development standards quickly as code check-in policies and unit test results provide constant feedback and guidance on the new developer’s development style.

One key indicator for how mature you are with your release management is how thoroughly you test customizations throughout the development lifecycle. As your developers build components, they can write unit tests to automate the testing of specific functionality. This will make a huge difference for the code quality and for your overall release management, because you will accumulate a test suite that you can configure to run automatically and alert you to any breaking change.

Beyond developers writing unit tests for their code, you can also include dedicated tester roles on your team. People often refer to these roles as quality assurance (QA), because they are on the team to validate and ensure quality before the team considers a component code complete and ready for deployment. Quality assurance resources can act as gatekeepers and as crusaders of quality, as they work to test different aspects of a customization.

Quality assurance extends developer unit tests with additional integration, coded user interface, and load tests. This helps you build out a more complete test suite of automated tests. The more testing and quality validation your quality assurance team automates, the more this investment pays for itself with each daily build. This grows your maturity for release management and it cultivates a high performing continuous integration process.

I like to automate as many test cases as I can, because then these tests can repeatedly run and provide feedback without any involvement or even having to think about them (until a breaking change causes tests to fail). This is a mature state for a team to reach, but you cannot automate all tests, as some will need a person to click through and validate the results. TFS can help you with these test cases as well with the manual tests you can create. Your quality assurance team can then manually conduct those tests and record the results.

Incorporating and enforcing development and testing standards with code check-in policies, automating tests as part of a continuous integration process, and including a quality assurance step to test and validate quality are all things that you can adopt to mature your release management processes. But do not stop there, because there is more that you can do. One thing in particular is to add another gatekeeper to test the quality and validate that the developers are developing the right solution. I refer to this stage as user acceptance testing where actual users test and validate a customization by using it in a test environment.

Designing a User Acceptance Testing Environment

Have you delivered a solution that meets your users’ needs, that solves an actual problem for them, or have you simply managed project scope and delivered some vague functional requirement? If you design it right, user acceptance testing (UAT) is your chance to find out. For me, I want to know that I am solving actual user problems and adding real value to their work, and I find the UAT stage of my release management process is the key point to validate and confirm this.

In my experience, it is important to separate the UAT environment from the development and integration environments. Even though the environment is not production, you still need to provide the users with a positive experience for the system’s stability and the functionality of the solution. Other preproduction environments may be buggy and tend to offer a less than optimal experience for end-users. You do not want to leave them with a bad impression, no matter how much disclosure you give them about how beta software runs differently than production.

Give your UAT testers stable software that is ready for production. It should be feature complete, at least for the area they are testing. These testers are not your bug testers nor are they your quality assurance department. These are your customers and you are using UAT to get their feedback on whether the solution you built meets their needs. If they accept it, then you should be able to deploy the solution into staging and then into production without any rework or changes. That is how complete you need to make your solution before you promote it to the UAT environment.

You have a few options on how you can set up and implement your UAT environment, and which you choose depends on the experience you want to provide to your users for their testing. Specifically, you can choose whether or not you want to replicate their existing site experience. The following lists some options you can choose from:

• For new applications, you can use a basic SharePoint site without any unnecessary data to focus on your solution’s functionality.
• For enhancements and extensions to existing applications, you can restore a backup of the users’ site to your UAT environment and deploy your solution to this site for testing.
• For new applications that you want to test in context, you can restore a backup of the users’ site to your UAT environment.

User acceptance testing is an opportunity for your users to let you know whether or not you built the right solution; it is not the time for you to defend yourself or to argue about the requirements. You are conducting UAT to collect user feedback and identify opportunities to make improvements and better meet their needs. I find it is best to prepare myself with these expectations so that I approach a UAT session seeking feedback and suggestions on where I can improve rather than with trying to push a solution or manage scope.

I like to make the UAT environment accessible so that it works the same for users as their experience with production. As part of this, I configure the preproduction Active Directory domain to trust the production domain. This way the users performing the tests can use their regular account and work in much the same way as they are used to. This removes some of the testing complexity and complications for them, which frees them up to focus on the solution and whether it meets their needs.

Regular users might not be familiar with TFS and its process to submit bugs. Again, to avoid complications and distractions during UAT, you might consider having a business analyst capture and submit any issues that come up during UAT for the users. This frees up your users to focus on using the application and on working in their normal way while someone else captures their feedback into the system for the team.

Ultimately, with user acceptance testing, you want users to work in their normal way and report how well or how poorly the solution meets their needs and fits with how they want to work. If you have done a good job with analyzing requirements and engaging stakeholders for constant feedback, then very little should come up during UAT to surprise you. However, this is your last chance to discover and correct any areas in your solution where you might be off the mark.

Using Multiple Environments for Testing and Staging

More preproduction environments can give you more practice with testing functionality and compatibility. They can also give you more practice with testing the deployment process. They allow you to focus on different things and incorporate different gates in your release management process. However, you can eventually go overboard.

There is no single correct number of preproduction environments that will work for everyone. The rule of thumb I use is to have enough environments in your release management process as are necessary for you to feel comfortable and to align with your tolerance for deployment risk. For some people, the number of environments will be much higher; while for others, this number will be minimal.

At the very least, you need a preproduction environment. You need a place to test the deployment process and the solution’s compatibility with the existing production environment, and you need to perform these tests before you release the customization in production. You are playing a dangerous and reckless game if you do not have at least one environment for testing before production. If this is the case, I suggest that you are not the only one who does this, but now is the time to do yourself a favor and setup a preproduction environment and start testing before you deploy to production.

As I mentioned earlier, I like to gradually work my preproduction environments closer and closer to match the production environment. This will range from my development environment, which is not much like production at all besides sharing the same components, all the way up to production itself. The number of environments in between depends on the project, the size of the development team, and the complexity and scope of the custom solution.

I noted some of the different preproduction environments earlier, but here I will describe a couple of them in more detail:

• Staging environment : A staging environment is the closest representation of the production environment and it is the final stop before you deploy a change into production. I usually setup staging as an exact duplication of production to conduct a final compatibility test with the deployment process and the custom functionality.
• Testing environment (s): You can have a range of testing environments, from automated testing in integration to manual user acceptance testing. You might consolidate these into a single environment or across many. I usually setup testing to resemble as much of production as I need to perform the tests.

These different environments all lay the infrastructure for your change management process. They provide you with testing options to identify issues before you release a change into production and cause stress for users. They also provide the environments where you can define gates as part of your change management process. In the next section, I look at some additional considerations for change management and your change management process.

Considerations for Change Management

Your organization might already have a change management process, and it may or may not be formalized. Change management applies to all of IT as a discipline, not just to SharePoint. IT standardizes a change management process to define all steps and procedures involved with controlling changes to IT infrastructure. Its goal is to minimize the impact to service availability and stability by defining standard steps and procedures to manage every change and mitigate risks of the changes causing a negative impact on the IT infrastructure.

A change management process typically involves IT stakeholders who meet for regular change management committee meetings to review the details of each change and approve or reflect on proposed changes. From there, if approved, the change is scheduled and applied to the IT infrastructure. An effective change management process generally involves the following stages:

• Change details reviewed and assessed by IT stakeholders
• Approval granted for change by IT stakeholders
• Change introduced through process with minimal risk to systems
• Process results of a component or configuration change
• Change provides business value through ongoing system use

Your SharePoint change management process fits within your existing IT service change management process, if one exists. If your IT team does not have anything formal for managing changes, then you can build out and manage your own process with the same formality and standardization as you would if your department had a change management process to follow.

The key benefits you realize from a change management process include your focused planning for the change and the extra perspectives that can help you consider potential risks associated with the change. Change management also ensures communication so that other IT teams are made aware of your proposed change and they can identify if the change will cause any conflict with their service area. It adds an extra check to help protect the stability of your SharePoint service.

You may have noticed me mentioning use cases at different times in this book. I find they are a useful tool for capturing and communicating details about a process, assumptions surrounding the process, and how to handle any exceptions or extensions to the scenario or user story. In the sidebar, I share a sample use case that I use for customization deployments. This can help you get started with designing your customization deployment process, and with building use cases in general.

Considerations for Rollback Planning

In Chapter 11, I discussed rollback planning from the perspective of planning to back out of an upgrade or any patches. The underlying need is no different for deploying customizations, as you should always have a plan to undo any change that did not go as planned, whether the change is a service pack or a custom component. You can use a similar process for custom components as the one I shared for rolling back patches or upgrades. Essentially, that rollback approach included backing up the SharePoint servers and databases and restoring those backups when you need to rollback a change.

However, the challenge with this approach for rolling back a custom component is that you need to schedule downtime with your SharePoint farm. If your rollback plan is to restore a database, then you need to prevent users from making any changes on the farm while you introduce the change so that you can restore any backups and rollback if the change does not go as planned, otherwise you would overwrite and lose their change. Depending on your tolerance for deployment risk, you might find this approach excessive for every little change. On top of that, it just might not be practical in practice even though it is an option.

What this means is that you will need to think through your rollback options on a case-by-case bases for each custom component. The following lists the general options I consider as part of my rollback planning:

• Can I simply deactivate a feature to rollback a change?
• Can I deactivate and remove the solution package to rollback a change?
• Does the customization add any artifacts to the SharePoint server that I need to clean up through a rollback script, such as deleting list items or files?
• Does the customization modify any data or configuration settings that I need to reverse through a rollback script?
• Does the customization change any visuals such as page layouts or web part positions that I need to reverse through a rollback script?

As you can see, my primary rollback plan to back out of any customization changes is to create a rollback script. Typically, this is a PowerShell script that reverses any changes the customization introduces. I have also used the SharePoint API in a console application to reverse these types of changes, particularly before the days of PowerShell, but this approach is still useful. A console application can capture the state before applying a proposed change, so it has the state information to reset and reapply data and settings to when you need to rollback.

Rolling back customizations is slightly more complex and involved than simply restoring server state and database backups, although that approach will also work. Scripting the process will work best, especially if the customization introduces any artifacts such as data or configuration settings. However, your rollback process might be a set of manual steps instead. For example, your rollback process for a component might be to navigate to a site and deactivate its feature and then manually delete any data or reset any configuration changes it made.

You have several options to rollback changes from customizations. The important thing is to think through those options and build a rollback plan before you deploy a customization as part of your release management processes. Once you have a rollback plan, then you need to test and validate it in a preproduction environment to ensure you can back out of any change. With all this in place, you are ready to release your custom component with confidence.

Consultant Comrade

A consultant brings their experience and expertise to help a client solve a particular problem, whether with SharePoint or with processes around SharePoint. The application development lifecycle and code promotion processes are no different, and as a consultant you can help your clients mature their processes. However, a consultant needs to exhibit his or her own mature processes before he or she can transmit the knowledge and practice to a client. You need to lead by example, and then once you fine-tune your own application development lifecycle and code promotion processes, you can champion them with your clients.

A caution though: establishing development practices can quickly unravel a project’s scope and consume a budget. It is exciting and important, and it can add a ton of value for your client. However, if it is not in in the project’s scope and you have not budgeted time for the activities, this will sink you. The trouble is that consulting activities to establish a mature development practice come early in a project delivery, when you still have a lot of budget and time, but before you get started on the actual project and flush out all the requirements and how much effort they will take. Getting sidetracked with designing development practices up front will leave you chasing from behind for the rest of the project until you finally run out of budget.

This is where it is good to lead by example. If you already have a mature set of processes for development and release management, such as those I described in this chapter, then you can show your client and involve them in the process. And if you do not have these processes already, then you need to work on building them on your own time. A new project that does not have any budget or time allocated for this work is not the place to attempt building processes.

Conversely, if you already have mature development and release management processes, then you are in a great position to consult clients on how to copy and establish similar processes. You need to plan for this and budget for it in the project’s scope. I have been on a couple of projects where the client noticed my team’s process and they wanted help to adopt it as well. Both times they had a new SharePoint development team and did not have any process. As valuable as this consulting engagement is, I have found that you should always deliver it under its own project and an explicit scope; otherwise it will take you off track and your project delivery will end without as much success.

Typically, I would organize this type of engagement with a Team Foundation System (TFS) deployment followed with configuring all the processes and policies I want to establish as part of the development standards I covered in Chapter 14. Then, I would design the integration environment and configure a TFS build agent to automatically trigger a build and run any unit tests for each developer check-in.

The TFS build process can also work with provisioning new virtual servers and deploying the solution there. A couple of times I have included this option for the daily build and you can even use the templates to provision new development environments when new developers join the team. This takes some effort to setup and configure, so it is probably only useful on large teams with multiple workgroups.

Once the infrastructure is in place, then you are ready to work with and start coaching the developers. This process is really an extension of the development standards I mentioned in Chapter 14, where now you are adding in TFS and a sophisticated set of policies and automated processes such as continuous integration builds and unit tests. This automated aspect is what enforces and reinforces any of your client’s standards, and it ultimately leads to a higher quality of code.

I think there is great opportunity for a consultant to help clients establish infrastructure such as TFS to support mature development and release management processes. Your clients might not need everything and all the processes I shared might be overkill for their needs, but every little bit will help. It will also align your clients with your own development standards and release management processes. It will also help to set your client up for success with future application development to extend their SharePoint service.

Inside Story: Notes from the Field

A while back, I was on a development team where we were building an application that integrates with a user’s personal MySite portal. My client wanted a custom application to centralize and control communication and approvals. Essentially, if they create a new policy or procedure or they change one, then the application tracks that and notifies each user on their MySite. The user then can review these policies and procedures from their MySite and accept them, and the system will track their acceptance.

It is certainly a nifty application, and one that was also useful for ensuring users receive and acknowledge other types of communications as well. Another team worked on the reporting aspect of the application, so that a manager can review whether his or her direct reports have reviewed and acknowledged a notification. The team built a variety of reports to extend the application for managers and executives. This added complexity and risk because that team was integrating with the components and workflow that my team was still developing.

We designed a continuous integration process to constantly build and deploy the SharePoint solution packages that made up the application. This was our first line of defense because it continuously merged every customization from the very beginning of the development process. This continuous integration process was practical and effective because it automated a lot of steps. This meant that continuous integration would not cause a burden on the team and it would not be tempting to drop or skip parts if the team gets too busy and falls behind, because the process is automated and did not cause any extra overhead.

My suite of unit tests also provided insulation (as did every team’s suite of unit tests for their code). When a developer on either team introduced a breaking change that caused a test to fail, the system assigned them a bug. The developer could then look at the failing test and use that information to correct the issue. This process catches compatibility issues early in the process and it provides instant feedback to developers to guide them in correcting any breaking change.

Now, having a continuous integration process such as the one I described in this chapter certainly helps a development team during the initial development for all the reasons I mentioned. But it also helps any future development teams that need to extend or enhance a custom application, because they can start using the automation right away. In particular, they can use the suite of automated tests to help them to avoid introducing any breaking changes to the existing code base that the developers may not be familiar with.

I think every stage of your release management process is important and will benefit you with increased stability and sustainability in your SharePoint service. However, I like continuous integration the best and this is where I place the bulk of my release management design efforts because so much quality control can be automated in this phase. Start with a highly functional and automated continuous integration environment, and build out your release management strategy from there.

Wrapping Up

In this chapter, I discussed considerations for planning a change management process and designing a release management process that encourages maturity and discipline in your deployment practices. I looked at how to automate integration testing and how to promote code through testing and staging environments to ensure stability before you deploy it to production environments.

Customizing your SharePoint service involves facilitating end-user customizations, designing development standards, and managing a release process. This fourth part of the book covered broad topics such as establishing sponsorship, facilitating end-user customizations, designing development standards and testing processes, building an information architecture, and planning your release management processes. With this information, you can handle those enhancements that require customizing and extending SharePoint, and this will help you add rich new functionality while lowering the risks involved with deploying custom components.

As we conclude our journey through these action-focused governance topics, I leave you with one final tool. Next, you will find an appendix where I have summarized rapid concepts from each chapter in this book. I organized the appendix so you can review each chapter at a glance to refresh your memory of the key points I discussed, and then I included a checklist of actions you can take as they relate to each chapter’s governance topics.