Deploy an Upgrade of SAP Commerce
The deployment phase of an Upgrade Project is rather different from the Project Delivery Framework. The biggest difference between an upgrade deployment and your first deployment or subsequent deployments to production is you're likely going to :in our
- Deploy a new version of the platform– this should be accounted for in your continuous delivery process.
- May require an upgrade of third-party tools (e.g., Java, DB) to remain compatible with your target version. You should have already tested this using the correct versions in the Testing phase.
- Perform some data migration. New item types will be created, removed, or changed. This will affect your existing data, so part of your deployment plan should include prepping production data during the deployment using Update Running System, Clean Orphaned Types, direct SQL scripts, impex scripts, SAP Commerce Administration Console (Scripting Console).
- Ability to "soft launch" is severely limited because there is only one system running your site(s). Also, because you are upgrading an existing system, the ability to let your customers see the source version of your site and others see the target version will be difficult, due to the data type changes. Having a single schema for two different versions is achievable, but it requires a lot of work and is prone to a lot of potential issues. It is better to have a rollback plan in place.
Table of Contents
During the Testing phase, you should have tested and certified a full run of your deployment plan. If you do not have a deployment plan, please review the "Update Deployment Procedure" of Upgrade Engineering phase. The deployment plan is key to a successful upgrade because it should contain all activities in a step-by-step order that the entire deployment team is familiar with. Once the go decision has been made, the deployment plan can be executed.
The probability of some of your data needing to be migrated during an upgrade project deployment is higher, compared to a normal code deployment. The only other times you may require data migration would be at the first-ever deployment and for other deployments where a customization would have warranted it (e.g., you introduced a new data type). With a major upgrade, you're most likely going to have to make changes to your data model. Your deployment plan should account for these data changes, including the step the particular data migration activity should occur. Sometimes, your data might need to be changed before the target version is deployed. You might also need to enrich the data after the code has been deployed. Where possible, these should be automated as part of the build process, but it might require manual execution of IMPEX (preferred) or direct SQL statements (last resort). You might also need to update your dclean up your type system.strategy, based on the new features available in your target version. You should also take advantage of the upgrade to
As stated above a "soft-launch" of the target version can be difficult without having two separate environments that would then need to be synced up. For an upgrade, it is better to have a rollback plan in place should something go wrong during the deployment. This would ensure the site is returned to its "as-is" state, including no loss of existing customer/order/product data. This is done by taking a backup of the database and performing a snapshot of all media files, as one of the initial steps in your deployment plan. If there is a failure and the team decides to roll things back, the database should be restored to the backed up version, media files should be restored from the snapshot, and all nodes should have the source version of the code redeployed.
Before the deployment, the team should establish a point and time-box within the deployment plan where a rollback is a secondary option. The primary option should be to stick with the upgrade and to use the determined time-box to try to resolve any of the known issues. If the time-box expires and the issues have still not been resolved, then a rollback should occur. The reason for doing this is that issues can come up when deploying to production, but if the team has made it through a majority of the steps it might be worthwhile to try to resolve the issues, instead of taking the time and team resources to execute the rollback. Having a go forward point and a time-box set ahead of time, will create less confusion during the deployment, as everyone is aware of the parameters they are working with.
Your backup strategy is only as good as the last time you tested it. Make sure you are taking backups and testing the restore process periodically (see "Go-Live Checklist" deliverable attached to Go Live Readiness for SAP Commerce Cloud)
Production Regression Test
Once you have successfully deployed your target version and migrated data, you should run through another round of regression testing to ensure the upgrade did not break anything in production. Even though you ran through regression tests in the Testing phase, there is a possibility that something might work in lower environments, but may not in production. Most of the times issues are seen with integrations. By executing a regression test in production, you can ensure the customer experience is working as expected. Although it may not be possible to run through a full regression, because it hits production systems, a small set of tests should be executed either manually or automatically based on the most common use cases. This will typically involve running tests like:
- Anonymous Customer (if applicable)
- Search using most popular keywords
- View product pages
- Add to cart
- Remove from cart
- Update cart
- Checkout as anonymous
- Check order
- Cancel order (if self-cancellation is allowed)
- Registered Customer
- Created a new customer
- Execute same tests as above
- Customer Service (using Assisted Service Module and/or Customer Support Center)
- Execute all tests above
Once all the regression tests have been executed successfully (and bugs opened for any non-blocker issue found), the Project Managers from the Customer and SAP/Partner (if being used) should decide with the team if the deployment is complete and ready to be made available to the end users. Once an agreement is reached, the final steps of the deployment plan around making the site available should be executed and you can move to the Support phase.