The discussion in this section
examines the environments required for SharePoint projects and how your
solutions flow between these environments.
1. Environments for Large Projects
In large projects, more environments
are required than your production environment. The main reason for
additional environments is to provide a reliable QA process to avoid
downtime and lost business productivity in your production environment.
Figure 1 shows the common stages most large projects use to verify the quality of the solution.
Automated Build Environment
The automated build environment or daily build environment
is used for daily automated integration testing. This environment is
built automatically with the latest code from the source code system
and, combined with virtual machine snapshots, can be used for daily
testing and verification, depending on your environmental usage model.
The automated build environment is usually
created from scratch on a daily or weekly basis using your
customizations. Where your customizations include site definitions or
web templates, these can be created relatively easily as large site
hierarchies to mimic your future production environment. Therefore, you
can smoke-test your project code and customizations before they are
released to the next stage (for example, to your dedicated test
environments).
Testing Environment
The testing environment
is either the same environment used for automated builds, or, in larger
projects, it is a large, dedicated SharePoint testing farm where
specific release builds can be tested. For example, the test
environment can be used for weekly builds to enable business and other
stakeholders to keep track of development progress.
Similar to the automated build environment, you
can start by re-creating the site hierarchy on each release. After your
initial production release, your test environment would be used to
mimic the upgrade of the customizations already in production.
Although separate testing environments are
typically used in larger projects, a dedicated testing environment is
highly recommended for all projects that use third-party solutions or
development customizations.
Quality Assurance Environments
The quality assurance (QA) environment, the User Acceptance Testing (UAT) environment, and the preproduction environment
should mimic the production environment from the point of view of a
server layout and configuration so that each of these environments can
be used to carry out the required testing. The environment should
follow the same guidance for accounts and network-level configuration.
This way, you can use this environment to ensure that, if
customizations work in this environment, they should be fine for
production usage as well.
2. Identifying the Environments Your Developers Require
There are various adaptations of
setting up team development environments for SharePoint 2013
development. However, this depends heavily on the project size and
requirements. Development environments should be standardized between
the developers to avoid any issues with different versions of
SharePoint 2013 or with any other third-party extensions.
Standardization also helps to avoid unexplained issues occurring on a
developer’s machine.
If virtualization is used, you can quite easily
create new development environments for developers. These can be hosted
on beefy servers, or alternatively, depending on your virtualization
software, hosted on your developer’s machine. It is often more
time-efficient to create a new environment (from an image), rather than
trying to solve the issues caused by developer tinkering.
Generally, the setup of development environments
should be automated as much as possible using scripting and other
automation so that new environments can be created as fast as possible.
It is strongly recommended not to share a single
SharePoint environment between developers. SharePoint development
involves IIS application pool recycles, repeated WSP builds, and code
debugging against SharePoint. These cannot be isolated in a shared
SharePoint instance. Overall developer productivity will suffer.
2.1 Virtualized Dedicated Environments
This model is based on using
virtualization software on the development computers to host an
instance of the SharePoint and development environments.
Development environment isolation avoids any
issues with developing multiple projects at the same time. You can use
a native server operating system during the development phase, which
minimizes any issues caused by the operating system platform. This
increases the overall knowledge of developers about the native
operating systems used in SharePoint production environments.
Windows 8 now supports client-side Hyper-V and
can host a virtualized instance of your SharePoint 2013 development
environment. For users using Windows 7 and Windows Vista (SP2)
operating systems, other virtualization vendors provide software to
virtualize and host the SharePoint development environment. In this
scenario, a local instance of SQL Server, SharePoint 2013, Visual
Studio, and any other tools are installed on the virtual machine and
hosted on the developer’s computer.
Figure 2 shows an example of a virtualized dedicated environment as described here:
- Each developer requires a powerful computer to host the
virtualization environment. According to the Microsoft recommendation,
at least 16 GB of RAM is required for your virtualized instance.
- A SharePoint development environment hosted on the developer
computer can be accessed either by using remote connections and a
desktop or by using Hyper-V. Virtual environments are either located
directly in the corporate network to facilitate access to enterprise
resources (such as Team Foundation Server) or environments that have
two network cards (one for the internal domain and environment and
another for accessing corporate resources).
- A centralized source code repository (such as Team Foundation Server) is used to store all developed source code.
- Physical servers (or set of virtualization host servers) host testing environments and other services.
From the developer’s point of view, this is a
flexible model because all other applications used in daily work (for
example, Office client applications) can be easily accessed and used,
and the virtual instance of your development environment can be turned
off when not required.
Another benefit of this model is the ability to
snapshot your development instance after it has been configured. This
enables the developers to roll back to a previous state or
alternatively a clean state before starting a new project.
A key consideration is whether the development
machine’s main purpose is for development associated with a single
project, or if it will be used across a number of clients or projects.
If the physical machine is based on an image and is solely for use on
one project, the risk is reduced. With constant development, the
quality of a SharePoint 2013 instance degrades and becomes
“fragmented.” Even with a re-install, these problems may not be easy to
eradicate (for example, Registry edit problems).
Dedicated computers require sufficient hardware
to host the virtualized environments. Lack of sufficient hardware can
impact the virtual SharePoint machine’s performance and may impact
development productivity. If the virtualized development environment
creation is automated, overall productivity will be better because
developers can take new, clean development environments when needed. An
automated, virtualized environment configuration can ensure that
there’s a new, clean environment available (with the latest source
code) within 15 minutes.
Numerous different virtualization techniques are available to choose from:
- Because SharePoint 2013 is 64-bit only, it must support hosting
64-bit operating systems. According to Microsoft, this model requires a
minimum of 16 GB (24 GB is preferable) of memory to ensure that both
client and host operating systems perform adequately. More memory
equates to better productivity for each of your developers.
- Ensure that you provide hard disks that perform because these will
host the virtual machines. If your organization still uses Windows 7,
one option with Windows 7 is the Boot from VHD option, which enables
the virtualization environment to be loaded as the primary operating
system when the computer is started. With this option, the overall
hardware requirements can be lower than mentioned previously.
Nevertheless, the storage capacity must be sufficient to host multiple
virtualization environments for different purposes.
One of the advantages of this kind of
model is that individual developers don’t need to have connectivity to
the corporate network during development. This model enables easier and
more flexible development, regardless of the developer location.
