Application Lifecycle Management in SharePoint 2013 : Planning Your SharePoint Team Environments (part 2) - Centralized, Virtualized Environments, Cloud Environments

2.2 Centralized, Virtualized Environments

A centralized, virtualized environment is a development environment model where development environments are hosted on the centralized virtualization platform, and developers use remote connections to access these environments.

This model provides numerous advantages compared to environments hosted in the computers used by developers because this model provides centralized management of the development environments. Individual computers used by the developers in their daily work do not require powerful hardware. These computers are only for hosting client-side applications (such as Office clients and other productivity applications).

Figure 3 shows an example of a centralized, virtualized environment. Note the following in the figure:

• Individual developers don’t have SharePoint installed on their local computers. They connect to the development environments using remote connections.
• Development environments are hosted in a centralized virtualization host.
• All active developers have their own development environment, which can be accessed using a remote connection. The environment is located either directly in the corporate network, or it has two network cards for having an internal domain and still can connect to the corporate network.
• Source code and other artifacts are stored in a centralized source code repository.

FIGURE 3

Because virtualized environments are centrally managed, they can be easily and efficiently used based on the current usage requirements. When they are not needed, this hardware can be dedicated to other environments. This results in cost-savings based on the efficient utilization of your available hardware. Similar models can be used to suspend development environments while spinning up testing environments and performing overnight tests. Ensure that individual developers are not blocked because of a lack of access to their centrally hosted virtualized SharePoint environment.

Individual virtualized development environments should still have at least 16 GB of memory dedicated to them. However, overall memory can be more efficiently used by the physical virtualization host machine.

In large projects, centralized virtualization platforms are often nevertheless used to enable integration testing and QA environments.

Hosting development machines requires expensive hardware for the centralized virtualization hosts. In many projects, these environments have been purchased as part of the project setup phase. After the primary development phase has ended, the same host can be used for hosting maintenance development environments, or, alternatively, for other projects.

2.3 Cloud Environments

In this model, development environments are placed and hosted in the cloud and accessed from developer computers using remote connections. The biggest advantage of this model is that there’s no requirement to invest in on-premise expensive hardware, but rather to rent and consume from cloud-based services for the duration of the project.

Depending on service provider, the costs may be based on usage (in other words, the actual time when the cloud services are accessed). This minimizes secondary costs because you pay only for the time you use your environments. Using this model, you can spin-up your testing environments in the cloud whenever required.

From cost-management perspective, the biggest advantage is quite simply that developers need to have only a computer with Internet access and use remote connections to access the cloud-hosted development environments.

Figure 4 shows an example of a cloud environment. Note the following in the figure:

• Developers work from a computer with Internet access.
• Development environments are hosted in the cloud and are assigned to the same network segment as the cloud-located source code system.
• Source code systems (such as Team Foundation Server) are hosted in the cloud.

FIGURE 4

Development environments set up based on this model are extremely interesting options because they provide the potential for endless hardware capacity for your project and can be easily scaled up and out.

3. Identifying the Environments Your Testers Require

Efficient testing and QA require consistent and stable testing environments. Multiple testers can conduct testing in a single test farm because all are accessing the environment as users of the SharePoint 2013 system.

Testing is critical to the success of your project. Testers shouldn’t need to worry about setting up environments or configuring preliminary settings as long as documentation and configuration of environments is not part of the quality assurances tasks to be taken.

All configurations required for the testing environment should be automated as much as possible. This way, the tester can concentrate on manual tests and verifying that your customizations work properly, rather than spending time on nonproductive actions.

Ensure that testers perform tests on machines that reflect the operating system, Office System Suite, and browser version of the business. For example, different defects will be picked up on a Windows Vista, Office 2007, Internet Explorer 8.0 browser build as compared to a Windows 7, Office 2010 and Internet Explorer 8.0/ 9.0/ Firefox or Windows 7/8, Office 2013, and Internet Explorer 8.0/ 9.0/ 10.0/ Chrome/ Firefox/ Safari.

Testers should be able to access the daily build environment to follow up on the progress of task and defect resolution so that all code is immediately available for testing. This way, developers can receive feedback on their enhancements and bug fixes. This enables issues to be resolved as soon as possible before a build is available to a wider audience.