Detecting language please wait for.......
Note: This document does not cover the development of any solution in detail, only the issues directly relevant to the deployment process.
While developing a solution several items and item types will be created, developed, and tested. A complete inventory of these items must be maintained throughout the development cycle, and experience shows that this might be complex to achieve in a retroactive effort.
Using SDL Tridion's "Where Used" functionality will help ascertain the relationships between items, but may not be sufficient due to the decoupled nature of Content Manager/Content Delivery environments.
You could, for example, rely on a compiled assembly that must be deployed to the Content Delivery Server, and this may not be "visible" to SDL Tridion's "Where Used".
The following is a sample table that could be used to track the development effort.
The Item Type column will identify part of the location for the item, while Item Location specifies the rest.
For instance, c# Template Building Blocks are always stored under Building Blocks/System/Templates, while c# assemblies is the name of the sub folder.
Item Name defines the real item name as displayed in Tridion.
Once a solution has been sufficiently tested within Dev and deemed ready, the Technical Lead for the development effort must use the SDL Tridion Content Porter to export all the required items as listed in the "Solution Building Blocks" spreadsheet.
Using the Content Porter you can easily select the items you want to export by expanding the navigation tree (left pane) and using the check boxes on the right to select the individual building blocks to Export.The export should be clearly labeled in the following format
If more than one export is required in the same day, the index number should increase sequentially so that release numbers are easy to reference.
It is recommended that a specific file share be used for storage of these exports. This will allow for an easy follow up and audit of changes and change history.
Launch Content Porter Client by activating it from the GUI Ribbon Toolbar
Choose "Start export wizard", click Next
Click "Add" to setup a new server if none have been setup before. The "Enter SDL Content Porter Server Information" comes up. Fill in the current DEV CMS server you want to connect to and click OK.
On the "Enter SDL Tridion Content Manager user credentials" enter an account with sufficient rights to perform the export required and click OK.
Content Porter client will now connect to the environment setup using the credentials provided and save the server information. Select the environment you want to export from and click Next.
Exclude filters for "Default Items", "Workflow", "Security" when performing a regular template and/or schemas export to reduce the number of items exported and processing. Click Next.
Begin selecting items to port from their owning publications (eg. schemas from level 010 Schemas, templates from 020 Templates) by clicking on the plus sign in the left panel to expand the item menus. Once the desired items have been listed in the right panel, mark the checkbox.
Note that mandatory dependencies are automatically selected, for instance parent folders of an item. Should you wish to exclude these dependencies, right click on the parent folder(s) and select "Children Only" or "Selected Children Only"
For a clearer view of what needs to be selected, click "Item Filter" and check the item types you do not wish to see on the screen. Note that if an item has been previously selected, it will still be selected even though it is hidden by the filter check. When all items for export have been selected, click Next.
Content Porter will apply a timestamp to the package. Select a different location for storing the package if desired by clicking Change. When ready, click Next.
Should an error occur, for smaller packages, choose to be notified as soon as this happens, otherwise skip and continue. If the export must be treated as a transactional process, choose Abort on error. Click Next.
Review the export settings, choose to save a configuration file if you anticipate running the export again, then click Start to begin.
Content Porter begins to export the items and provides status on progress.
When the export completes, note the status and click Next.
Review the items reported as exported to match against what was tagged for export (remember the count will include dependencies) and click Finish when ready.
Before any deployment, it is highly recommended to back-up the Tridion Content Manager Database. The fastest way to restore the environment may very well be to restore this database, depending on the number of items that have been updated.Using the Content Porter, import the building blocks into SDL Tridion, paying special attention to Schema validation errors such as the one show below:
This means that the content, as created in DEV cannot be created in QA, what typically indicates that a schema change was done in DEV and not propagated to QA. This must be evaluated together with the Technical Lead, and the component in question may have to be re-exported.
Any component with a dependency on this one will also fail to be imported, so a complete new export may be required.
Launch Content Porter Client by activating it from the GUI Ribbon Toolbar if it is not already running
Choose "Start import wizard", click Next
Click "Add" to setup a new server if the import environment has not been setup before. The "Enter SDL Content Porter Server Information" comes up. Fill in the current QA CMS server you want to connect to and click OK.
Content Porter will connect to the server using the credentials provided and prompt to select a package for import. Click "Browse".
Navigate to and select the previously generated export package.
Fill in a description to identify the package, click Next.
Unless you are exporting updates or new items for workflow, security or default templates, these items can and should be excluded from the import to shorten the amount of items Content Porter will process. Select them and click Next.
Navigate to and select the items to import from their owning publication.
Right clicking on organizational items in the left panel, brings up a menu, which allows additional filtering for items to be ported. This menu can be used when, for example, there is metadata associated with a folder, structure group or publication which perhaps differs by environment and should not be updated during import.
Running in transaction mode will only commit the import if no errors are encountered.Running the import in discovery mode will allow Content Porter to analyze the intermediate package and target environment to find potential problems ahead of the actual import. Click Next.
Choose to be prompted in case of an error if you want to fix issues as soon as they are reported.Choose "Yes" to update the items selected for import.Choose "No" to avoid updating dependencies of items not explicitly selected. Warning: Note that if an item contains component links or references templates which do not exist in the target environment, they will be imported along regardless of opting out of updates. These items will be added at the same level as the item imported instead of their owning publication to allow the item to be updated/created, therefore potentially create blueprint conflicts on future imports.
Click "Save Configuration" to create a reference file containing the current selection for import. This will be useful on subsequent imports should they be necessary as well as for "Undoing" committed imports.
For easy filing and selection later on, name the configuration file using a current timestamp and description of current release. Click "Save" to store the file locally.
Click "Start" to begin the import.
Content Porter will start processing the package for import according to the options selected so far and report progress for each import stage. Once this is complete, click "Next".
Items imported and/or updated are counted and the findings shown as a final summary. Check these numbers to ensure selections match actual updates bearing in mind updates to dependencies (eg. folder updates for components or structure group updates for pages ported).Click "Finish" to return to the main menu.
Due to the nature of Tridion items and their interdependence (see image below) many items are potentially impacted by a "simple" update. Especially where Schemas are involved, possibly all templates may have an issue.
The only way to successfully test a Tridion-based deployment is to re-publish every item linked to the updated/created items, and this may require some "detective" work.1. Finding the list of items updated/created.a. This list should have come from the Development team, in the form of an Excel file.2. Finding the list of potentially impacted items.a. Find the items listed in the Excel file within the Content Manager.b. Use Tridion's "Where Used" functionality to get a list of potentially impacted items.c. Re-publish every item within this list, monitor for publishing errors using the Tridion Publishing Queue.3. Test the published application's behaviour, as described by the Development team.
The QA team may want to look at ways to automate part of this testing.
Once QA has approved the deployment, steps 3.3 and 3.4 must be repeated for the Production Environment. The deployment package must be the same that was imported into QA, and must not be an export from QA. This ensures that the exact same items will be deployed into Production, and not items that may have been modified in QA.
The final section of this guide contains useful troubleshooting tips.