Before you start building a custom Microsoft SharePoint solution, you need to ensure that the development environment is set up correctly. Once you have got the hardware, make sure that you document the entire configuration. It will help in creating a second environment, and also when have to recreate your development environment. Although it is possible to build a development environment by using a standalone server installation of SharePoint on a single server, for practical reasons, the developers would at least need a domain controller, a database server, and a SharePoint server.

If your development environment is installed in an existing domain, you won’t have to build your own domain controller as you can use the existing one. Many organizations require at least three SharePoint Farm environments viz. development, test, and production. Custom-code applications need to move from the development environment to the production environment where they will ultimately reside. Test development is most useful when it accurately reflects the configurations of the production environment. However, not many native SharePoint tools may not be available to keep these environments in sync. So, the developer may do a backup and restore from one environment to the other but this is not always beneficial. The best approach would be to identify specific differences between environments and make decisions based on the situation of each case.

Configuration vs. custom coding

With the staggering variety and richness of SharePoint, ranging from InfoPath to workflow, and search to business data connectivity, a developer may have to decide whether to configure SharePoint, or rely on custom coding. Sometimes the project requirements are so specific that custom-developed code is required. When building SharePoint systems, more often than not some element of custom code will be involved. The developer should ensure that the custom approach meets best practices and design patterns, and is also robust enough and maintainable to meet the challenges of the project. The quality of these customizations, and the codes used to build them will have an impact on different aspects of SharePoint platform including performance, security, maintainability, and stability.

Developing custom web parts with extended functionalities

Earlier, SharePoint code could only be deployed as a ‘full trust farm solution’ that had frequent issues related to coding. After a quick fix solution called ‘Sandboxed Solutions’, SharePoint introduced a better approach called ‘App Development Model’ that permits only client-side code, or server code running on an entirely separate platform away from SharePoint. Best practices dictate leveraging the out-of-box features whenever possible, since the solution will be faster to develop and easier to maintain. When out-of-box web parts are insufficient, the developer may create their own custom web parts, based on the ASP.NET web part infrastructure. This is where the value of the SharePoint development company begins to pay off.

Delivering value to the users

In particular, Microsoft-certified SharePoint development partners, such as Flexsin Technologies, can be particularly useful as the SharePoint development company would have access to SharePoint product team resources that other organizations may lack. Web parts also enable users to combine or filter information, create compelling 3-D charts, and also improve upon application navigation. The developer could get a large percentage of the required capability from the Web Parts, and can focus their attention on extending Web Parts through custom actions, or by coding for the additional functionality. This approach by the SharePoint development company enables the users to customize their own sites and applications. The developers benefit by reducing their backlog of tedious customization requests while still delivering value to the users.

Third-party tools may be unknown or only offer a partial solution to the requested functionality, so the developer may choose to create a new solution, rather than incorporating the existing one. One could certainly build a custom web service from an external SQL server database, using Business Connectivity Services (BCS) to extract data.

Managing change requests

Tools are available for the SharePoint development teams to manage change requests, the most recommended one being the Team Foundation Server or TFS. Whatever be the tool used, the following process should be followed:

Request tracking: TFS allows the developers to document each request and monitor the progress towards its completion by adding notes, attachments, and status information through work items whose parameters and type can be customized and configured as required.

Source control: It is important to maintain a well-documented and repeatable SharePoint development lifecycle. This will not only serve as a way to securely store source code for custom code development but also provides an audit trail for each part of the process. TFS-enhanced features, such as Changesets and Annotation, can be used by the developers to add functionality to the source code.

Build automation: It will automate many mundane but necessary tasks for each new build of the solution, freeing the developer’s time to focus on the problem domain. Automation gives end users a certain level of confidence as the results can be examined by all. TFS Build Server provides for all these features that can be configured to address some deployment challenges, such as the drop location of a resulting WSP file.