Project planning and application lifecycle management
One of the most important and often overlooked thing to cover in planning phase of the projects is the application lifecycle management (ALM) for upcoming portal. In this context I don't mean just the lifecycle management for the customizations, rather for the full process and environments. Every single project done with SharePoint technologies (WSS/MOSS), should define the clear rules and practices to manage the process as early as possible.
By setting the ground rules immediately in the planning phase of the project, you can take them into account during the technical planning of the deployment and of course also in the operational planning. Following image and table defines one example process, which follows the continuous integration model for SharePoint development (Continuous integration in MOSS development using TFS).
Following table defines the steps and phases one-by-one.
# |
Phase / Element |
1 |
Developers develop individual features and functionalities based on of the technical specification using their independent virtualized environments, which have access to the TFS server for work items, source control etc. Virtualized environment have to be in-sync with the production environment concerning the licensing and patching. Customizations developed with enterprise license; don't necessarily work in standard environment. Patches and service packs should be also keep in sync. Ensure that it's somebody’s responsibility to keep the virtualized environment up to date. |
2 |
TFS Server used to store source code and other project related information. Developers can also sync their environment using the artifacts stored in TFS. It's obvious, that developers have to have ensured connection to the source control repository. |
3 |
SQL Server instance of the TFS, used for actual storage of the different artifacts and document. Ensure that this database is fully managed, monitored and operational; otherwise the development cannot be conducted. |
4 |
Development integration server, which is used to verify the builds from the TFS, preferable using automated build process. Server should be kept in sync with the production environment. Integration server is used for integration and deployment testing. Also the initial functional testing for full package should be conducted in this environment. |
5 |
Project members (for example project manager, testers and even customers representatives in some cases) can follow the progress of the project and give feedback based on the builds deployed. Define the ground rules for accepting the deployments to quality assurance environment from the integration environment. If the development happens in ISV premises, this server is most likely located also there. It's not however good practice to have similar server in these cases also at the customer premises, so that it can be used to deploy pilot or draft versions of the solution. This way we can establish communication channels concerning the upcoming features as soon as there's something to deploy. This approach minimizes surprises at the end of the project and the customer representatives can use the environment for training purposes as early as possible There has to be clear rules to follow for accepting the deployment for following phases. |
6 |
Quality assurance environment used for functionality testing and acceptance testing. In ideal world this environment is identical as the production environment, so that it can also be used for load testing. Quite often though, the environment is virtualized for more convenient maintenance. Load testing can be nevertheless conducted also in virtualized environment, if project performs the initial load testing (base line testing) during the first version of the portal. This way the future load testing results can be compared to these base testing values. In sense of licensing and configuration, the environment should be completely identical to production. This ensures that if the deployment is successful in this environment, it will work also in production. |
7 |
SQL Server of the quality assurance environment. Obviously the configuration should be identical as for the production. Operational setup should also follow the production, so that full portal behavior can be observed also in this environment. |
8 |
MOSS environment used for production purposes. There should be clear responsibilities and operational guidance for this environment to ensure that possible issues caused for example customizations can be solved in timely fashion. One of the key things to document and to follow is the version handling model of the customizations (how things are updated). As written earlier, there has to be crystal clear model for deployment of new versions and guidance to follow in case of any issues encountered. |
9 |
SQL Server for the production, which is fully managed and monitored 24/7. In case of any issues, there should be clear guidance on how to proceed. Backup and restore process should be verified in quality assurance environment and if possible also in production environment, before going live with the portal. |
Considerations
Following chapters defines few points to consider when the full process is planned. I also want to raise few pointers, which I have personally run into in multiple partners and customers.
Are the code and SharePoint artifacts in safe place?
It should be clear that the all of the customizations developed for SharePoint portal are stored in some source control system, like Team Foundation Server. You don't want be in situation where the customization are gone, due failure in single laptop or desktop. Also consider and ensure that the source control system is in safe hands. If there's critical issues in the production, which requires instant code level fix to be deployed, you need to ensure that the source control is up and running.
Basically this means that the source control system should be high available or at least there's a backup plan to access the source code in timely fashion, so for example possible SLA's can be achieved.
Is the process high available?
We need to go through the steps in the process to ensure that there's no single point of failure in the process. Technical failures can be fairly easily identified, but we also need to consider the steps, which require human intervention. You don't want to be dependent from single persons, which could compromise the environment for example during summer vacation. There needs to be a back up person for each critical responsibility, with sufficient knowledge concerning the possible tasks to be done.
Is there clear model to update the customizations?
Setting up the initial version of the portal is quite straight forward, but the possible updated versions have to be carefully designed. It's quite common that after the initial version, there will be additional functionalities included in the portal. At some customers, there are quarterly releases, which enhance the functionalities provided for the end users by introducing new possibilities and options. If the upgrading model is not clear before the initial customizations are deployed, life can get complicated. Can we use the in-place upgrade of the solution packages? Does the end users use SharePoint designer in production? Every decision has it's effect and there for we need to ensure the model already in the planning phase.
Personally I've seen way too many SharePoint deployments, which have been build up nicely, but when we need to update any of the customizations, the life get's over complicated.
Is the customization deployment model scalable?
The usage of the solution package in deployment of the customizations can be considered as the de-facto way of deploying ANY customizations to the portal. By using solution packages we can ensure that in case of increased load for the MOSS farm, we can scale the farm out, by adding additional servers. If the deployments are done manually, there's too huge risk for human errors and the servers won't be in-sync. Manual deployment would require also huge amounts of additional actions to be conducted when the new server is introduced to the farm.
Summary
I listed only few pointers to give you an idea of the things to cover in you project. Of course model and required processes is fully dependent on the scale of the deployment. If you only use closely out of the box SharePoint installations and the modifications are done using SharePoint Designer, you don't necessarily have to think through these kinds of things. For large scale projects, the models and processes have to be planned carefully. It's not rocket science and you should not over think the processes, but by planning a head, you can ensure the long running service, which will be definitely worth of investment.