Sitecore is a complex piece of software by any measure. This series attempts to explore, demystify, and shine a light on some of the complexities involved in deploying Sitecore sites into an existing (and operational) Sitecore instance where source code is contributed by multiple parties.
When you start a Sitecore project it is important to understand and respect the environment it is going to be deployed into. What has been built and deployed (hopefully) works as the client expects it to. The client expects you to not change this.
Ideally the full source code is made available to your team but it is not required. One approach is to build your solution underneath the existing solution. What I mean by this is to first build your solution then apply the existing solution files over top.
Get a hold of what makes the current solution tick
The first step in the process is to obtain the files that are required to operate the existing instance. There are a number of components that are required to run the site beyond the standard Sitecore instance. Request these files from an operating instance of the site, production or perhaps the UAT/staging server. Listed in descending order of importance:
- Bin folder (most imporant)
- App_Config folder
- Views folder (if using MVC)
- Layouts (if using WebForms)
A bonus item would be a Sitecore package of the content tree (the whole thing), this should go ways to enable you to run the existing sites locally and include them in your smoke testing process.
Note there may be more items that are required depending on the footprint of those who have come before you.
Reference in legacy project
Create a project in your solution named "Legacy" and add all the aforementioned files to the project and nothing else.
Make sure the project can build then make the minimal modifications required to get your site to work. In simple cases this should be limited to ConnectionStrings.config, DataFolder.config and the Site definition configuration.
Each file that is modified should be have its original version stored with the file extension '.original', this makes it easy to roll back settings if need be, also it helps when including any modifications that were made in the release notes or documentation.
Configure build order and post build actions
Next up ensure that the legacy project is the last one to be built in the solution build order. Then modify the post build actions so that the project assets (not just the assemblies) are copied into the target Sitecore website folder. If you have your solution set up correctly this folder should be a default official Sitecore version release with your solution deploying into it (overwriting where required).
xcopy "$(ProjectDir)bin\*.dll" "$(SolutionDir)Website\bin\" /E /R /Y xcopy "$(ProjectDir)Views\*.cshtml" "$(SolutionDir)Website\Views" /E /R /Y xcopy "$(ProjectDir)App_Config\*.config" "$(SolutionDir)Website\App_Config\" /E /R /Y xcopy "$(ProjectDir)*.asax" "$(SolutionDir)Website" /S /R /Y xcopy "$(ProjectDir)web.config" "$(SolutionDir)Website" /S /R /Y
Now you have your solution building into the Sitecore solution then the existing instance assets and assemblies being merged in. This means that you are essentially running your site 'in' the existing instance.
Now you can fully regression test your site and features, if there are no problems then you can be reasonably confident that it will work in the target environment.
Check out the other posts in this series.
- Its a multi-agency world
- Building a legacy (project)
- Pulling yourself up by your bootstraps
- Configuration collisions
- Keep your items tidy
- Pack your things
Continue reading the next in the series Pulling yourself up by your bootstraps