SharePoint development platform, provides the capabilities
to develop, deploy, and update customizations and custom functionalities for
the SharePoint sites. The activities that take advantage of these capabilities
all fall under the category of Application Lifecycle Management (ALM).
“ALM is a continuous process of managing the life of an application
through governance, development and
maintenance.”
With the options like BCS, Client OM, Sandbox solutions, WCF
based Service Applications and Claims based authentication SharePoint has also
significantly evolved as application development platform which opens up a
number of extensibility options for the developers. With the power and
flexibility to use these tools and customizations the question arises is how to
effectively and efficiently manage the activities taking into account the
lifecycle of application starting from requirement gathering to release management
with consistent quality.
The entire process involves setting up SharePoint with
visual studio, TFS, Build automation, Deployment and automated testing.
Setting up DEV
environment
To take the full advantage of development capabilities, SharePoint
is installed on all development machines. We use scripted installation of
SharePoint (SPAutoInsaller) which
helps to maintain a similar environment for all development machines and helps
the team to configure SharePoint easily.
TFS as a source control
With Visual studio as a development tool, the integration to
source control is much easier as the IDE is easily integrated to the TFS. The
team creates and works on team projects, checks in the code directly from
Visual Studio to TFS.
TFS for build
automation
CI builds are configured to ensure that every code that is
checked in passes the build with the configured build standards. On every code check-in
the build server to pull down the latest source code, compile the code, run any
static analysis rules, executes all unit tests and integration tests on the
latest code and report any errors along the way. This is a great way of
ensuring that even if the developers locally don’t run the static analysis
rules or unit tests they will be run here and also ensures that all source code
is checked in and is working as expected.
TFS for Code analysis
Code analysis rules help teams to ensure that coding is done
according to the standards defined and are followed without fail. The default
set of rules are built into Visual Studio which can also be tweaked to meet the
specific needs of the teams. Apart from the built in rules which are common to
all projects, additional rules like SPDisposeCheck
that analyzes the code to see whether all SPWeb
and SPSite objects are disposed
correctly can be added to the rules. These rules are run on both Visual Studio
and TFS to ensure continuous quality.
Automated
deployment
Automated deployment is triggered as part of the build
process, or as an unattended service to deploy solution packages. The
deployment process is a combination of batch files, PowerShell commands and xml
configuration files. It is a great way to update the test machines with latest
version of the software every time a new version is checked in.
Automated unit,
smoke and regression testing
Testing is also configured as part of the CI build process
or a nightly build process depending on the teams requirements. Most of the
unit tests are executed on every check-in build and regression tests are
executed as part of the nightly builds. Team focuses on creating and
maintaining a clean set of test cases that help the team get an early feedback
on the quality of the product after every release to the test environment.
No comments:
Post a Comment