Project List of Deliverables in Sitecore

Companies often hire Sitecore developers and partners for their Sitecore instance initial implementation. After the project has been launched, ongoing support and maintenance can be organized by internal specialists or IT partner. And it is possible that customer doesn't know exactly which artifacts to expect as a result of implementation. At the same time, not all developers have the required experience and knowledge to provide a full set of assets for best-practice delivery and support process. We’ve prepared the list of outputs customers should ask from implementation partner.

Here is a minimum you should expect as a result that you can use and support in future:

Source code

It is a good idea to have it even if you do not know what to do with it. You might need to change something on your site with a different partner later or have a different company as a supporting partner. Source code can be provided as an archive or better as a repository in VCS. Ideally, you should have some running Continuous Integration (CI) system bound with a VCS. We recommend using GIT with ‘Feature Branch Workflow’ or ‘Gitflow Workflow’. Even more - it is useful for a customer to understand and control the source code workflow and know what version was released recently, what feature branches will form the next release.

Site root

It may be required in case if the implementation team has no access to the production servers or there is no production yet or any other reason why you do not have the site running on your side right now, but it will be deployed manually. Note that usually, the Sitecore site includes several servers with different roles (cm, cd, reporting, etc.) and different roles require different configuration files (sometimes other files may be different as well, e.g. binaries). We strongly recommend having CI which will apply all transformations and provide you with a set of prepared assets for all servers.

Database or items package

Typically implementation team will store all added or modified Sitecore items in VCS using popular tools like TDS (https://www.teamdevelopmentforsitecore.com/, https://himynameistim.wordpress.com/2015/02/26/sitecore-continuous-integration-with-team-city-and-tds/ ) or Unicorn ( https://github.com/kamsar/Unicorn, http://andrew.lansdowne.me/2013/06/07/auto-deploy-sitecore-items-using-unicorn-and-teamcity/) what allows deploying Sitecore project items to any environment via CI easily. Note that content items are usually excluded. It is a good approach to have a staging server where codebase and non-content Sitecore items are updated via CI while content is controlled by content authors. It allows to avoid issues related to inappropriate developers’ test content and works as an additional QA level. At the same time, it works as a content storage and preview version of CM (Content Management) server. But for simple projects, it is also possible to have a simple backup of all databases or Sitecore package with items and roles.

Documentation

Documentation can vary depending on project complexity, implementation, and content teams’ cooperation, implementation team involvement, etc. Some documents can be maintained by product owner team (e.g. Functional Design)

1. Installation Manual - describes steps to get a fully functioning Sitecore instance from vanilla Sitecore, required modules, code deployment, server configuration changes, required additional software, provided server roles configuration, additional databases, etc.
2. Technical design - describes technical details of a solution, used approaches, patterns, tools, etc.
3. Functional design - describes how site pages and features must behave. Can be used for development, QA, and support.
4. Content author/marketer Manual - describes pages and content items structure, fields, settings, custom applications, placeholder settings, extended Sitecore tools and rules, workflows and how to use them.
5. Security manual - can be required if complex roles model used to create several access levels for frontend and backend users.

Is that all?

No, the list should give you a general idea but it is not comprehensive or fully required. Not all Sitecore projects are complete website solutions. For example, it can be an isolated Sitecore module designed to work in different environments. And in that case, you will need prepared installation packages for all required Sitecore versions. A solution can also include Windows services, Web API applications, PowerShell scripts (for server shell or Sitecore PowerShell Extensions) etc. It is also possible to have ‘lean and mean’ solution ‘code today, deploy manually tomorrow and may be automated and documented sometime’. But such approach never works as expected and it ends up with poorly documented and dirty solution which become more expensive and hard to maintain later.

Questions or comments? Drop us a line here and share what you think.