From 86b04718eeb374313caf1df88a3b80c7b156ecce Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Mon, 18 Dec 2023 14:52:11 +0100 Subject: [PATCH 01/22] Update preparation-for-going-live.md Restructure. --- docs/ca/dev/preparation-for-going-live.md | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index c231d6a3b94..77c02edecb9 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -42,10 +42,6 @@ Ensure you have addressed all the items from the following checklists. After pointing the domain name to your Spryker project, some of your customers may still see your old project due to DNS propagation. So, keep it live for up to 72 hours after the migration. -We highly recommend you to follow our [Security guidelines](/docs/scos/dev/guidelines/making-your-spryker-shop-secure.html) and ensure all the points are acknowledged and applied. - -Double check that you do not have any clear text passwords stored in config files or repositories. - {% endinfo_block %} ### Application @@ -79,15 +75,12 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Make sure you have an APM set up*. Application Performance Monitoring tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). - *Verify that your Deploy file is set up correctly*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. -- *TLS certificates are provisioned*. If you delegate DNS to Spryker, TLS certificates for your endpoints are created automatically. If you want us to create TLS certificates for your endpoints but don't want to delegate your DNS, request the verification of DNS records by the [Support Portal](https://support.spryker.com). If you don't delegate your DNS and want to use your own certificates, provide them to us as described in [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). - *Deploy the production environment regularly*. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). -- *The DNS names and strategy for your shop are clear*. You know how users are going to access your shop. Verify that you control access to the DNS to be able to manage DNS. For example, you want to use `spryker.com` as the domain for your shop, but you want a user to access the Storefront by the `www.spryker.com` subdomain. +- *The DNS names and strategy for your shop are clear*. + - You know how users are going to access your shop. Verify that you control access to the DNS to be able to manage DNS. For example, you want to use `spryker.com` as the domain for your shop, but you want a user to access the Storefront by the `www.spryker.com` subdomain. See [Set up DNS](/docs/ca/dev/set-up-dns.html) for details on how to set up DNS for your application. + - Optional: *Delegate DNS*. To find out how to delegate a DNS name, see [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). + - *TLS certificates are provisioned*. If you delegate DNS to Spryker, TLS certificates for your endpoints are created automatically. If you want us to create TLS certificates for your endpoints but don't want to delegate your DNS, request the verification of DNS records by the [Support Portal](https://support.spryker.com). If you don't delegate your DNS and want to use your own certificates, provide them to us as described in [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). - *Decide how email sending should be handled*. If you want to send emails using Spryker, decide whether you want to use the native mail service shipped with Spryker Cloud Commerce OS or integrate a third-party one. If you want to use the native one, let us know the email address that you want to send emails from. We will lift sending restrictions and help you validate the needed DNS name. See [Email service](/docs/ca/dev/email-service/email-service.html) for more information about the default email service and its restrictions. -- Optional: *Delegate DNS*. To find out how to delegate a DNS name, see [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). - -### DNS setup - -See [Set up DNS](/docs/ca/dev/set-up-dns.html) for details on how to set up DNS for your application. ### Application From b1d86a8e966af916de7ea61198e363499fb08410 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Mon, 18 Dec 2023 15:11:26 +0100 Subject: [PATCH 02/22] Update formatting --- docs/ca/dev/preparation-for-going-live.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 77c02edecb9..e283b022e34 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -60,12 +60,13 @@ After pointing the domain name to your Spryker project, some of your customers m ### Testing -- [Test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode) to understand how your application will perform and work when deployed. -- Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). +- *Test deployments*. [Test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode) to understand how your application will perform and work when deployed. +- *Test All Payment options*. Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). ### SEO ### -Make sure the SEO strategy and plan are defined. If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. +- *Make sure the SEO strategy and plan are defined.* + - If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. ## Four weeks before go-live @@ -92,7 +93,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Conduct load tests*. Conduct load tests for your application. The sample data used for testing should be comparable to the size and complexity of the production data. - *Performance testing and environment scale dial-in*. Testing your production environment before officially going live and assessing its performance are critical steps for a successful launch. Because production environments typically employ horizontal auto-scaling, it's essential to conduct stress and performance tests under expected average and peak loads. These tests enable our team to optimize the environment's vertical scaling in advance, ensuring that it can seamlessly handle the expected loads from the get-go, without any potential delays caused by auto-scaling mechanisms. This proactive approach eliminates the need for post-launch adjustments, providing your team with a significant advantage and peace of mind, while delivering a fast and responsive experience to your users right from the first request to the application. To make this process work effectively, maintain active communication with us. Inform us about your load and performance test plans and share the results so that we can fine-tune the environment to meet your specific requirements. -- Import real data on production. +- *Import real data on production*. {% info_block warningBox "Data import" %} @@ -110,7 +111,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti ## Two weeks before go-live ## -- *Code freeze*. We recomment to have a code freeze at least two weeks before going live. +- *Code freeze*. We recommend to have a code freeze at least two weeks before going live. - *Double-check the go-live date*. If any of the preceding tasks are not complete, postpone your go-live or discuss with us how to complete them in time. DNS changes are especially sensitive to deadlines. Due to how the DNS system works, any DNS changes take time to take effect. - *Make sure that the rollback strategy is still valid*. Check that you have everything you need to recover from an unforeseen issue with the newest version of the project you are deploying. - *Validate testing strategy.* @@ -120,7 +121,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti - *Define the exact plan for the go-live day.*: - Define the time of deployment. - Define the exact steps to be performed (including running Jenkins or other scripts if needed). -- Make sure that DNS is set. +- *Make sure that DNS is set*. {% info_block infoBox "Don't hesitate to contact us" %} From 1655223adea3e14fbdf11e12d8be421bc39ba92e Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Wed, 20 Dec 2023 13:22:32 +0100 Subject: [PATCH 03/22] Add new topics --- docs/ca/dev/preparation-for-going-live.md | 75 +++++++++++++++++++---- 1 file changed, 64 insertions(+), 11 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index e283b022e34..0831ff80764 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -54,9 +54,16 @@ After pointing the domain name to your Spryker project, some of your customers m - Create [deploy files](/docs/scos/dev/the-docker-sdk/{{site.version}}/deploy-file/deploy-file.html) for each of your environments. These files must be named in a particular manner: `deploy.(project)-(environment).yml`. For example, `deploy.example-staging.yml`. - [Define a Docker SDK version](/docs/scos/dev/the-docker-sdk/{{site.version}}/choosing-a-docker-sdk-version.html) for the project to use. - Integrate [FlySystem](/docs/ca/dev/configure-data-import-from-an-s3-bucket.html) so that the project is using data in S3 Buckets instead of local storage. -- Make sure that, where applicable, you have implemented our recommended Jenkins [performance and stability improvements](/docs/scos/dev/tutorials-and-howtos/howtos/howto-reduce-jenkins-execution-costs-without-refactoring.html) and that you are observing the general [Publish and Sync stability best practices](/docs/ca/dev/best-practices/best-practises-jenkins-stability.html#memory-management). -- Make sure you have applied the security guidelines. For details, see [Security guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html). -- Double-check that you don't have any clear text passwords stored in config files or repositories. +- *Performance tips are implemented and verified*: + - Double-check that you implemented all the [performance guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/performance-guidelines/performance-guidelines.html). + - Make sure that, where applicable, you have implemented our recommended Jenkins [performance and stability improvements](/docs/scos/dev/tutorials-and-howtos/howtos/howto-reduce-jenkins-execution-costs-without-refactoring.html). + - Make sure that, where applicable, you have implemented our [Publish and Sync stability best practices](/docs/ca/dev/best-practices/best-practises-jenkins-stability.html#memory-management). +- *Security guidelines are implemented and verified*: + - Apply Spryker [Security guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html). + - Double-check that you don't have any clear text passwords stored in config files or repositories. + - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. + - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. +- Make sure to comply with the latest laws. Consult your legal team. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. ### Testing @@ -66,7 +73,13 @@ After pointing the domain name to your Spryker project, some of your customers m ### SEO ### - *Make sure the SEO strategy and plan are defined.* - - If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. + - *Redirects*. If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. + - *Best practices*. Make sure that best practices are implemented. See [Basic SEO techniques to use in your project](/https://docs.spryker.com/docs/scos/dev/best-practices/basic-seo-techniques-to-use-in-your-project.html) + +### Training ### + +- *Define a training plan for staff.*: + - Team should know and understand on how to use the application. ## Four weeks before go-live @@ -74,7 +87,9 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Cloud -- *Make sure you have an APM set up*. Application Performance Monitoring tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). +- *Make sure you have an APM set up*: + - Application Performance Monitoring tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). + - Make sure to configure alerting mechanisms. - *Verify that your Deploy file is set up correctly*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. - *Deploy the production environment regularly*. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). - *The DNS names and strategy for your shop are clear*. @@ -85,7 +100,6 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Application -- *Performance tips are implemented and verified*. Double-check that you implemented all the [performance tips](/docs/scos/dev/guidelines/performance-guidelines/general-performance-guidelines.html). - *Variables and parameter store values are set up*. Double-check whether you have all environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. ### Testing @@ -93,6 +107,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Conduct load tests*. Conduct load tests for your application. The sample data used for testing should be comparable to the size and complexity of the production data. - *Performance testing and environment scale dial-in*. Testing your production environment before officially going live and assessing its performance are critical steps for a successful launch. Because production environments typically employ horizontal auto-scaling, it's essential to conduct stress and performance tests under expected average and peak loads. These tests enable our team to optimize the environment's vertical scaling in advance, ensuring that it can seamlessly handle the expected loads from the get-go, without any potential delays caused by auto-scaling mechanisms. This proactive approach eliminates the need for post-launch adjustments, providing your team with a significant advantage and peace of mind, while delivering a fast and responsive experience to your users right from the first request to the application. To make this process work effectively, maintain active communication with us. Inform us about your load and performance test plans and share the results so that we can fine-tune the environment to meet your specific requirements. +- TO BE DISCUSSED *Perform security audits to identify and address vulnerabilities.* - *Import real data on production*. {% info_block warningBox "Data import" %} @@ -101,7 +116,11 @@ You must start working with data of realistic size and quality as early as possi {% endinfo_block %} -- Test payment. +- *Validate Checkout/OMS process* + - Test general checkout steps. + - Test OMS. + - Test shipment. + - Test payment. {% info_block warningBox "Integration with payment providers" %} @@ -109,19 +128,53 @@ Lower or nonproduction environments may not have the same WAF and firewall setti {% endinfo_block %} +### SEO ### + +- *Sitemap is generated*. +- *Robots.txt is prepared*. +- *All the content is prepared*. All the CMS pages and other content are prepared (including meta tags, internal and external links, etc). + +### Training ### + +- *Make sure that training for staff is done.*: + - Team should know and understand on how to use the application. + ## Two weeks before go-live ## - *Code freeze*. We recommend to have a code freeze at least two weeks before going live. - *Double-check the go-live date*. If any of the preceding tasks are not complete, postpone your go-live or discuss with us how to complete them in time. DNS changes are especially sensitive to deadlines. Due to how the DNS system works, any DNS changes take time to take effect. - *Make sure that the rollback strategy is still valid*. Check that you have everything you need to recover from an unforeseen issue with the newest version of the project you are deploying. -- *Validate testing strategy.* -- *Organize a go-live support team*. Prepare a team that can monitor your go-live, react quickly to any issues, and work with the Spryker Support or Operations teams. -- *Validate BI and analytics integrations*. They should not be connected to your production database, but rather to the provided read replica. Make sure no external system is interacting with your production database. +- *Make sure that DNS is set*. - *Remove all the demo data from the environment*. The project should only use the real data that will be used after the go-live. Remove all the demo data that comes with the Spryker repository, which includes demo and admin users. Demo users in a live shop pose a significant security risk for your project. +- *Make sure that real data is set on production* + - Categories + - Product and all related data (prices, offers, attributes, images, stock, labels, reviews and ratings, cross and up selling etc.) + - Customers, Companies, Users, Merchants + - Taxes + - Discounts + - CMS pages (including homepage, CSM blocks, final terms & conditions check) + - Glossary (including all the needed languages) + - Custom data + - Other data +- *Make sure that 3rd party systems are switched to "Production mode"* + - *Set up production configuration for all the 3rd party systems* (in environment variables). Make sure to not expose secrets in the codebase. + - *Validate BI and analytics integrations*. They should not be connected to your production database, but rather to the provided read replica. Make sure no external system is interacting with your production database. +- *Organize a go-live support team*. Prepare a team that can monitor your go-live, react quickly to any issues, and work with the Spryker Support or Operations teams. - *Define the exact plan for the go-live day.*: - Define the time of deployment. - Define the exact steps to be performed (including running Jenkins or other scripts if needed). -- *Make sure that DNS is set*. +- *Go live*: + - *Prepare a go live communication plan*. Develop a communication plan to inform stakeholders, customers, and support teams about the launch date and any changes or updates. + - Remove basic auth from the frontend part and deploy the change. + +### Testing ### +- *Perform end-to-end testing.* Make sure to test customer journey with all the 3rd party systems switched to production mode. + +### SEO ### + +- *Robots.txt is set up*. +- *All the content is set*. All the CMS pages and other content are set (including meta tags, internal and external links, etc). +- Optional: *Redirects are set up.* {% info_block infoBox "Don't hesitate to contact us" %} From 27569269c2b7359846bbcc8e7c975aa8f5daf102 Mon Sep 17 00:00:00 2001 From: Andriy Netseplyayev Date: Wed, 20 Dec 2023 15:48:29 +0100 Subject: [PATCH 04/22] Update preparation-for-going-live.md Added some more points and considerations --- docs/ca/dev/preparation-for-going-live.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 0831ff80764..f3d8a47f319 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -60,15 +60,16 @@ After pointing the domain name to your Spryker project, some of your customers m - Make sure that, where applicable, you have implemented our [Publish and Sync stability best practices](/docs/ca/dev/best-practices/best-practises-jenkins-stability.html#memory-management). - *Security guidelines are implemented and verified*: - Apply Spryker [Security guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html). - - Double-check that you don't have any clear text passwords stored in config files or repositories. + - Double-check that you don't have any clear text passwords or API secrets stored in config files or repositories. - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. -- Make sure to comply with the latest laws. Consult your legal team. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. +- *Compliance and Legal Checks* - Consult your legal team to ensure the platform complies with relevant legal and regulatory requirements, especially for international operations. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. ### Testing - *Test deployments*. [Test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode) to understand how your application will perform and work when deployed. - *Test All Payment options*. Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). +- *User Acceptance Testing (UAT)*. Besides internal testsing, conducting extensive UAT to validate the functionality and user experience from an end-user perspective is always a great idea before opening your system publicly. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers ### SEO ### @@ -78,8 +79,10 @@ After pointing the domain name to your Spryker project, some of your customers m ### Training ### -- *Define a training plan for staff.*: - - Team should know and understand on how to use the application. +- *Training and Documentation for End-Users and Admins*: + - Prepare role-specific enablement trainings for all internal users of the platform. These may include: backoffice administrators (incl. role specifics), support assistants and agents, marketplace operators, merchant portal users. + - Consider also external users, such as those interacting with the platform via APIs or 3rd party systems. + - And last but not least, your end customers should be aware of changes (if any) that the new platform may bring. Besides striving for good user experience and transparency, make sure to consult with your legal team about any obligations in that regard. ## Four weeks before go-live @@ -89,7 +92,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Make sure you have an APM set up*: - Application Performance Monitoring tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). - - Make sure to configure alerting mechanisms. + - Establish robust post-launch monitoring plan, with the aim to watch system's performance and configuring alerting mechanisms. - *Verify that your Deploy file is set up correctly*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. - *Deploy the production environment regularly*. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). - *The DNS names and strategy for your shop are clear*. @@ -101,6 +104,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Application - *Variables and parameter store values are set up*. Double-check whether you have all environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. +- *Third-Party Integrations and Compatibility Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting or similar. ### Testing @@ -108,7 +112,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Performance testing and environment scale dial-in*. Testing your production environment before officially going live and assessing its performance are critical steps for a successful launch. Because production environments typically employ horizontal auto-scaling, it's essential to conduct stress and performance tests under expected average and peak loads. These tests enable our team to optimize the environment's vertical scaling in advance, ensuring that it can seamlessly handle the expected loads from the get-go, without any potential delays caused by auto-scaling mechanisms. This proactive approach eliminates the need for post-launch adjustments, providing your team with a significant advantage and peace of mind, while delivering a fast and responsive experience to your users right from the first request to the application. To make this process work effectively, maintain active communication with us. Inform us about your load and performance test plans and share the results so that we can fine-tune the environment to meet your specific requirements. - TO BE DISCUSSED *Perform security audits to identify and address vulnerabilities.* -- *Import real data on production*. +- *Import real data on production*. After import is done, it is crucial double-checking the completeness and accuracy of migrated data, especially if transitioning from another platform. {% info_block warningBox "Data import" %} From a7a1ab42177d5741d6a10b373e3d51e9da5bd025 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Thu, 21 Dec 2023 16:25:28 +0100 Subject: [PATCH 05/22] Add new topics. Fix comments from the code review. --- docs/ca/dev/preparation-for-going-live.md | 62 ++++++++++++++--------- 1 file changed, 38 insertions(+), 24 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index f3d8a47f319..d3a7c0bcb25 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -64,12 +64,13 @@ After pointing the domain name to your Spryker project, some of your customers m - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. - *Compliance and Legal Checks* - Consult your legal team to ensure the platform complies with relevant legal and regulatory requirements, especially for international operations. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. +- *Admin panel ACL set up and verification*. Ensure that the admin Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. ### Testing - *Test deployments*. [Test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode) to understand how your application will perform and work when deployed. - *Test All Payment options*. Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). -- *User Acceptance Testing (UAT)*. Besides internal testsing, conducting extensive UAT to validate the functionality and user experience from an end-user perspective is always a great idea before opening your system publicly. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers +- *User Acceptance Testing (UAT)*. Besides internal testing, conducting extensive UAT to validate the functionality and user experience from an end-user perspective is always a great idea before opening your system publicly. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers ### SEO ### @@ -103,6 +104,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Application +- *Prepare and communicate technical debt mitigation plan*. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. - *Variables and parameter store values are set up*. Double-check whether you have all environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. - *Third-Party Integrations and Compatibility Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting or similar. @@ -132,34 +134,23 @@ Lower or nonproduction environments may not have the same WAF and firewall setti {% endinfo_block %} +### Data ### + +- *Prepare a data migration plan*. Include all the data. + ### SEO ### - *Sitemap is generated*. -- *Robots.txt is prepared*. +- *File robots.txt is prepared*. - *All the content is prepared*. All the CMS pages and other content are prepared (including meta tags, internal and external links, etc). - -### Training ### - -- *Make sure that training for staff is done.*: - - Team should know and understand on how to use the application. +- *Favicon is set*. ## Two weeks before go-live ## -- *Code freeze*. We recommend to have a code freeze at least two weeks before going live. +- *Code freeze*. We recommend having a code freeze at least two weeks before going live. - *Double-check the go-live date*. If any of the preceding tasks are not complete, postpone your go-live or discuss with us how to complete them in time. DNS changes are especially sensitive to deadlines. Due to how the DNS system works, any DNS changes take time to take effect. - *Make sure that the rollback strategy is still valid*. Check that you have everything you need to recover from an unforeseen issue with the newest version of the project you are deploying. - *Make sure that DNS is set*. -- *Remove all the demo data from the environment*. The project should only use the real data that will be used after the go-live. Remove all the demo data that comes with the Spryker repository, which includes demo and admin users. Demo users in a live shop pose a significant security risk for your project. -- *Make sure that real data is set on production* - - Categories - - Product and all related data (prices, offers, attributes, images, stock, labels, reviews and ratings, cross and up selling etc.) - - Customers, Companies, Users, Merchants - - Taxes - - Discounts - - CMS pages (including homepage, CSM blocks, final terms & conditions check) - - Glossary (including all the needed languages) - - Custom data - - Other data - *Make sure that 3rd party systems are switched to "Production mode"* - *Set up production configuration for all the 3rd party systems* (in environment variables). Make sure to not expose secrets in the codebase. - *Validate BI and analytics integrations*. They should not be connected to your production database, but rather to the provided read replica. Make sure no external system is interacting with your production database. @@ -167,19 +158,42 @@ Lower or nonproduction environments may not have the same WAF and firewall setti - *Define the exact plan for the go-live day.*: - Define the time of deployment. - Define the exact steps to be performed (including running Jenkins or other scripts if needed). -- *Go live*: - *Prepare a go live communication plan*. Develop a communication plan to inform stakeholders, customers, and support teams about the launch date and any changes or updates. - - Remove basic auth from the frontend part and deploy the change. + ### Testing ### -- *Perform end-to-end testing.* Make sure to test customer journey with all the 3rd party systems switched to production mode. + +- *Perform end-to-end testing*. Make sure to test customer journey with all the 3rd party systems switched to production mode. Make sure to cover all the parts of application, including: + - Customer registration, account. + - Main E-commerce flow (search, checkout/OMS process). + - User/Merchant flow. + - etc + +### Data ### + +- *Remove all the demo data from the environment*. The project should only use the real data that will be used after the go-live. Remove all the demo data that comes with the Spryker repository, which includes demo and admin users. Demo users in a live shop pose a significant security risk for your project. +- *Make sure that real data is set on production* + - Categories + - Product and all related data (prices, offers, attributes, images, stock, labels, reviews and ratings, cross and up selling etc.) + - Customers, Companies, Users, Merchants + - Taxes + - Discounts + - CMS pages (including homepage, CSM blocks, final terms & conditions check) + - Custom data + - Other data +- *Make sure that all the translations are provided*. Including all the needed languages. +- *Make sure that all Emails are correct*. Including all the needed data and translations. ### SEO ### -- *Robots.txt is set up*. +- *File robots.txt is set up*. - *All the content is set*. All the CMS pages and other content are set (including meta tags, internal and external links, etc). - Optional: *Redirects are set up.* - + +## Go-live ## +- Remove basic auth from the frontend part and deploy the change. +- Run Go-live communication plan. +- Optional. Disable the destructive pipeline after successful go-live. {% info_block infoBox "Don't hesitate to contact us" %} From b3eab5d350a67dbdf019de8e9cb092285b46c7fe Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Thu, 21 Dec 2023 16:29:18 +0100 Subject: [PATCH 06/22] Fix a typo --- docs/ca/dev/preparation-for-going-live.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index d3a7c0bcb25..060bba99545 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -64,7 +64,7 @@ After pointing the domain name to your Spryker project, some of your customers m - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. - *Compliance and Legal Checks* - Consult your legal team to ensure the platform complies with relevant legal and regulatory requirements, especially for international operations. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. -- *Admin panel ACL set up and verification*. Ensure that the admin Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. +- *Admin panel ACL set up and verified*. Ensure that the admin Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. ### Testing From 79635505dccab8b8694ab70e4137efd47012859f Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Thu, 21 Dec 2023 16:47:53 +0100 Subject: [PATCH 07/22] Added new point --- docs/ca/dev/preparation-for-going-live.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 060bba99545..008c6f1f99f 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -163,7 +163,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti ### Testing ### -- *Perform end-to-end testing*. Make sure to test customer journey with all the 3rd party systems switched to production mode. Make sure to cover all the parts of application, including: +- *Perform end-to-end testing on production*. Make sure to test customer journey with all the 3rd party systems switched to production mode. Make sure to cover all the parts of application, including: - Customer registration, account. - Main E-commerce flow (search, checkout/OMS process). - User/Merchant flow. @@ -191,6 +191,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti - Optional: *Redirects are set up.* ## Go-live ## +- *Perform end-to-end testing on production*. - Remove basic auth from the frontend part and deploy the change. - Run Go-live communication plan. - Optional. Disable the destructive pipeline after successful go-live. From 2ac0734c95e366453e3d754706981e97bafcff67 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Thu, 21 Dec 2023 17:43:26 +0100 Subject: [PATCH 08/22] Added new point --- docs/ca/dev/preparation-for-going-live.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 008c6f1f99f..a01c7320462 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -33,6 +33,10 @@ Ensure you have addressed all the items from the following checklists. ### Cloud +- *3rd party connections are configured*. Check if there are any requirements from 3rd party systems to connect to production environment. As some examples it can be: + - port configuration; + - IP whitelisting/blacklisting; + - etc. - *DDOS prevention or mitigation checked and implemented.* - Check your concepts for DOS and DDOS prevention or mitigation and check with relevant vendors for products that fit your needs and are compatible with SCCOS. - Check your concepts for DOS and DDOS prevention Admin panel and Merchant portal. Add basic auth if applicable. For details, see [Configure basic .htaccess authentication](/docs/pbc/all/identity-access-management/{{site.version}}/configure-basic-htaccess-authentication.html) From 83bf99df55b5a5e65512b696bd0708fbba3713f1 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Fri, 22 Dec 2023 14:34:57 +0100 Subject: [PATCH 09/22] Update docs/ca/dev/preparation-for-going-live.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bünyamin Inan --- docs/ca/dev/preparation-for-going-live.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index a01c7320462..bda4bc473f1 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -63,7 +63,7 @@ After pointing the domain name to your Spryker project, some of your customers m - Make sure that, where applicable, you have implemented our recommended Jenkins [performance and stability improvements](/docs/scos/dev/tutorials-and-howtos/howtos/howto-reduce-jenkins-execution-costs-without-refactoring.html). - Make sure that, where applicable, you have implemented our [Publish and Sync stability best practices](/docs/ca/dev/best-practices/best-practises-jenkins-stability.html#memory-management). - *Security guidelines are implemented and verified*: - - Apply Spryker [Security guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html). + - Apply Spryker [security guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html). - Double-check that you don't have any clear text passwords or API secrets stored in config files or repositories. - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. From 1a19bf26d687a4276a03ed1b5cfc86096fbbe51c Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Fri, 22 Dec 2023 14:39:54 +0100 Subject: [PATCH 10/22] Small refactoring --- docs/ca/dev/preparation-for-going-live.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index a01c7320462..5cf26ee2d21 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -33,10 +33,6 @@ Ensure you have addressed all the items from the following checklists. ### Cloud -- *3rd party connections are configured*. Check if there are any requirements from 3rd party systems to connect to production environment. As some examples it can be: - - port configuration; - - IP whitelisting/blacklisting; - - etc. - *DDOS prevention or mitigation checked and implemented.* - Check your concepts for DOS and DDOS prevention or mitigation and check with relevant vendors for products that fit your needs and are compatible with SCCOS. - Check your concepts for DOS and DDOS prevention Admin panel and Merchant portal. Add basic auth if applicable. For details, see [Configure basic .htaccess authentication](/docs/pbc/all/identity-access-management/{{site.version}}/configure-basic-htaccess-authentication.html) @@ -67,7 +63,8 @@ After pointing the domain name to your Spryker project, some of your customers m - Double-check that you don't have any clear text passwords or API secrets stored in config files or repositories. - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. -- *Compliance and Legal Checks* - Consult your legal team to ensure the platform complies with relevant legal and regulatory requirements, especially for international operations. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. +- *Compliance and Legal Checks* + - Consult your legal team to ensure the platform complies with relevant legal and regulatory requirements, especially for international operations. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. - *Admin panel ACL set up and verified*. Ensure that the admin Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. ### Testing @@ -110,7 +107,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Prepare and communicate technical debt mitigation plan*. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. - *Variables and parameter store values are set up*. Double-check whether you have all environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. -- *Third-Party Integrations and Compatibility Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting or similar. +- *Third-Party Integrations and Compatibility Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting, port configuration or similar. ### Testing @@ -198,7 +195,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti - *Perform end-to-end testing on production*. - Remove basic auth from the frontend part and deploy the change. - Run Go-live communication plan. -- Optional. Disable the destructive pipeline after successful go-live. +- Disable the destructive pipeline after successful go-live. {% info_block infoBox "Don't hesitate to contact us" %} From 2d8622c7915d5e58b6cf5e7db4b7d6ecf2cc6901 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Wed, 10 Jan 2024 19:12:34 +0100 Subject: [PATCH 11/22] Updated wording based on the comment from the team Added new point about personal accounts usage --- docs/ca/dev/preparation-for-going-live.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 635a4c6b13c..38bc0161536 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -60,7 +60,8 @@ After pointing the domain name to your Spryker project, some of your customers m - Make sure that, where applicable, you have implemented our [Publish and Sync stability best practices](/docs/ca/dev/best-practices/best-practises-jenkins-stability.html#memory-management). - *Security guidelines are implemented and verified*: - Apply Spryker [security guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html). - - Double-check that you don't have any clear text passwords or API secrets stored in config files or repositories. + - Make sure that you don't have any plain-text passwords, private keys, or API secrets in config files or git repositories. + - Minimize the use of personal credentials and choose work-specific accounts based on each environment (production, staging, testing). Employing Centralized Credential Management is highly recommended for securely storing and managing these credentials. - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. - *Compliance and Legal Checks* From 65122a87989a9fcd7d91da790d45e70153b9d587 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Wed, 10 Jan 2024 19:20:37 +0100 Subject: [PATCH 12/22] Updated wording based on the comment from the team --- docs/ca/dev/preparation-for-going-live.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 38bc0161536..1f6fc9c2005 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -95,7 +95,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Make sure you have an APM set up*: - Application Performance Monitoring tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). - - Establish robust post-launch monitoring plan, with the aim to watch system's performance and configuring alerting mechanisms. + - Establish robust post-launch monitoring plan, with the aim to watch system's performance and configuring alerting mechanisms.We highly recommend logs to be configured to be gathered in a centralised SIEM system, in order to ensure that effective investigation would be possible in case of security incidents. - *Verify that your Deploy file is set up correctly*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. - *Deploy the production environment regularly*. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). - *The DNS names and strategy for your shop are clear*. @@ -115,7 +115,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Conduct load tests*. Conduct load tests for your application. The sample data used for testing should be comparable to the size and complexity of the production data. - *Performance testing and environment scale dial-in*. Testing your production environment before officially going live and assessing its performance are critical steps for a successful launch. Because production environments typically employ horizontal auto-scaling, it's essential to conduct stress and performance tests under expected average and peak loads. These tests enable our team to optimize the environment's vertical scaling in advance, ensuring that it can seamlessly handle the expected loads from the get-go, without any potential delays caused by auto-scaling mechanisms. This proactive approach eliminates the need for post-launch adjustments, providing your team with a significant advantage and peace of mind, while delivering a fast and responsive experience to your users right from the first request to the application. To make this process work effectively, maintain active communication with us. Inform us about your load and performance test plans and share the results so that we can fine-tune the environment to meet your specific requirements. -- TO BE DISCUSSED *Perform security audits to identify and address vulnerabilities.* +- We highly recommend performing a penetration test by an independent third-party provider and address the identified vulnerabilities. Before conducting a penetration test, Spryker should be informed at least two weeks in advance by completing the [form](https://docs.google.com/forms/d/e/1FAIpQLSfunn1HY-nsqueP6sRQSLmScUWlmmQyQJk9cscIVIP_5BmuOw/viewform?usp=sf_link). - *Import real data on production*. After import is done, it is crucial double-checking the completeness and accuracy of migrated data, especially if transitioning from another platform. {% info_block warningBox "Data import" %} From f95c5f267cfc5ef6771c77cdb72ba859d3401a7a Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Wed, 10 Jan 2024 19:26:17 +0100 Subject: [PATCH 13/22] Updated wording based on the comment from the team --- docs/ca/dev/preparation-for-going-live.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 1f6fc9c2005..205033ea4d0 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -109,7 +109,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *Prepare and communicate technical debt mitigation plan*. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. - *Variables and parameter store values are set up*. Double-check whether you have all environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. - *Third-Party Integrations and Compatibility Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting, port configuration or similar. - +- *Prepare and implement DB creating on production*. F.e. commit propel migration for production and update deploy file to install DB from the commited migration files. ### Testing - *Conduct load tests*. Conduct load tests for your application. The sample data used for testing should be comparable to the size and complexity of the production data. From 407fb7fd3a5524e993cca55dab13f9b7f1733af6 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Wed, 10 Jan 2024 19:35:48 +0100 Subject: [PATCH 14/22] Updated wording based on the comment from the team --- docs/ca/dev/preparation-for-going-live.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 205033ea4d0..9a80499a13b 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -13,7 +13,8 @@ redirect_from: {% info_block warningBox "Do not risk your Go-Live!" %} -The preparation steps listed here are mandatory because they are critical to the success of your go-live. We strongly encourage you to complete these steps because we won't be able to resolve the issues related to the steps not completed in time. Ensure that your project plan contains the tasks related to the go-live checklist and allows enough time for them to be completed. +Points mentioned here are critical for the success of your go live. +We strongly encourage that your project plan contains the tasks related to the go-live checklist and allows enough time for them to be completed. {% endinfo_block %} @@ -22,9 +23,6 @@ This document describes how to prepare a Spryker project for going live on Spryk We divided the preparation into approximate timeframes, and you can adjust them to your needs. Make sure that all the following tasks are completed one week before going live. -To successfully deploy a project on Spryker Cloud Commerce OS, make sure you follow all the guidelines described in this document. - - ## Eight weeks before go-live Eight weeks before your project goes live, *let us know your go-live plan*. Reach out to your Partner or Customer Success Manager and share your go-live plans: the date and time when you want to make your shop accessible to the public. If the time changes, keep us updated. This is critical for DNS switching and the hypercare phase we provide before and after your go-live. From e812a969587ea1526a2f8bcea1f126f565009799 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Mon, 29 Jan 2024 16:05:55 +0100 Subject: [PATCH 15/22] Updated wording based on the comment from the team --- docs/ca/dev/preparation-for-going-live.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 9a80499a13b..0664527b80a 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -25,14 +25,14 @@ We divided the preparation into approximate timeframes, and you can adjust them ## Eight weeks before go-live -Eight weeks before your project goes live, *let us know your go-live plan*. Reach out to your Partner or Customer Success Manager and share your go-live plans: the date and time when you want to make your shop accessible to the public. If the time changes, keep us updated. This is critical for DNS switching and the hypercare phase we provide before and after your go-live. +Eight weeks before your project goes live, *please inform us about your detailed go-live plans*. Reach out to your Partner or Customer Success Manager and share your go-live plans: the date and time when you want to make your shop accessible to the public. If the time changes, keep us updated. This is critical for Domain Name System (DNS) switching and the hypercare phase we provide before and after your go-live. -Ensure you have addressed all the items from the following checklists. +Ensure you have considered and/or addressed all the items from the following checklists. ### Cloud -- *DDOS prevention or mitigation checked and implemented.* - - Check your concepts for DOS and DDOS prevention or mitigation and check with relevant vendors for products that fit your needs and are compatible with SCCOS. +- *Distributed Denial-of-service (DDOS) prevention or mitigation checked and implemented.* + - Check your concepts for Denial-of-service (DOS) and DDOS prevention or mitigation and check with relevant vendors for products that fit your needs and are compatible with SCCOS. - Check your concepts for DOS and DDOS prevention Admin panel and Merchant portal. Add basic auth if applicable. For details, see [Configure basic .htaccess authentication](/docs/pbc/all/identity-access-management/{{site.version}}/configure-basic-htaccess-authentication.html) - *DNS strategy is defined*. If you delegate DNS to Spryker, let us know the date on which to point the domain name to your Spryker project. @@ -64,7 +64,7 @@ After pointing the domain name to your Spryker project, some of your customers m - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. - *Compliance and Legal Checks* - Consult your legal team to ensure the platform complies with relevant legal and regulatory requirements, especially for international operations. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. -- *Admin panel ACL set up and verified*. Ensure that the admin Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. +- *Admin panel Access Control List (ACL) set up and verified*. Ensure that the admin ACL setup is configured correctly to manage user permissions and access rights within the system's administrative interface. ### Testing @@ -72,7 +72,7 @@ After pointing the domain name to your Spryker project, some of your customers m - *Test All Payment options*. Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). - *User Acceptance Testing (UAT)*. Besides internal testing, conducting extensive UAT to validate the functionality and user experience from an end-user perspective is always a great idea before opening your system publicly. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers -### SEO ### +### Search Engine Optimization (SEO) ### - *Make sure the SEO strategy and plan are defined.* - *Redirects*. If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. @@ -91,7 +91,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Cloud -- *Make sure you have an APM set up*: +- *Make sure you have an Application Performance Monitoring (APM) set up*: - Application Performance Monitoring tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). - Establish robust post-launch monitoring plan, with the aim to watch system's performance and configuring alerting mechanisms.We highly recommend logs to be configured to be gathered in a centralised SIEM system, in order to ensure that effective investigation would be possible in case of security incidents. - *Verify that your Deploy file is set up correctly*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. @@ -99,7 +99,7 @@ Four weeks before your project goes live, ensure you addressed all the items fro - *The DNS names and strategy for your shop are clear*. - You know how users are going to access your shop. Verify that you control access to the DNS to be able to manage DNS. For example, you want to use `spryker.com` as the domain for your shop, but you want a user to access the Storefront by the `www.spryker.com` subdomain. See [Set up DNS](/docs/ca/dev/set-up-dns.html) for details on how to set up DNS for your application. - Optional: *Delegate DNS*. To find out how to delegate a DNS name, see [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). - - *TLS certificates are provisioned*. If you delegate DNS to Spryker, TLS certificates for your endpoints are created automatically. If you want us to create TLS certificates for your endpoints but don't want to delegate your DNS, request the verification of DNS records by the [Support Portal](https://support.spryker.com). If you don't delegate your DNS and want to use your own certificates, provide them to us as described in [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). + - *Transport Layer Security (TLS) certificates are provisioned*. If you delegate DNS to Spryker, TLS certificates for your endpoints are created automatically. If you want us to create TLS certificates for your endpoints but don't want to delegate your DNS, request the verification of DNS records by the [Support Portal](https://support.spryker.com). If you don't delegate your DNS and want to use your own certificates, provide them to us as described in [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). - *Decide how email sending should be handled*. If you want to send emails using Spryker, decide whether you want to use the native mail service shipped with Spryker Cloud Commerce OS or integrate a third-party one. If you want to use the native one, let us know the email address that you want to send emails from. We will lift sending restrictions and help you validate the needed DNS name. See [Email service](/docs/ca/dev/email-service/email-service.html) for more information about the default email service and its restrictions. ### Application From a32bba35b23615dc0c2d6b53f06b7382cbc044a1 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Mon, 29 Jan 2024 16:56:09 +0100 Subject: [PATCH 16/22] Updated wording based on the comment from the team --- docs/ca/dev/preparation-for-going-live.md | 30 +++++++++++++---------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 0664527b80a..4921235892e 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -38,13 +38,13 @@ Ensure you have considered and/or addressed all the items from the following che {% info_block infoBox "DNS propagation" %} -After pointing the domain name to your Spryker project, some of your customers may still see your old project due to DNS propagation. So, keep it live for up to 72 hours after the migration. +After pointing the domain name to your Spryker project, some of your customers may still see your old project until the DNS propagation is completed. So, keep it live for at least 72 hours after the migration. {% endinfo_block %} ### Application -- Upgrade your project's code to match the latest Demo Shop release, or at minimum, upgrade to a release that fully supports the Docker SDK. +- Upgrade your project's code to match the [latest Demo Shop release](https://docs.spryker.com/docs/scos/user/intro-to-spryker/releases/release-notes/release-notes.html), or at minimum, upgrade to a release that fully supports the Docker SDK (202009.0 and higher). - Update `spryker/twig` to version 3.15.2 or later because this version and the later ones have important stability improvements over version 3.15.1. - Migrate the project's database to MariaDB if you don't use it already. - Split up your project's Zed endpoints as outlined in [Integrating separate endpoint bootstraps](/docs/scos/dev/technical-enhancement-integration-guides/integrating-separate-endpoint-bootstraps.html) guide. @@ -52,6 +52,9 @@ After pointing the domain name to your Spryker project, some of your customers m - Create [deploy files](/docs/scos/dev/the-docker-sdk/{{site.version}}/deploy-file/deploy-file.html) for each of your environments. These files must be named in a particular manner: `deploy.(project)-(environment).yml`. For example, `deploy.example-staging.yml`. - [Define a Docker SDK version](/docs/scos/dev/the-docker-sdk/{{site.version}}/choosing-a-docker-sdk-version.html) for the project to use. - Integrate [FlySystem](/docs/ca/dev/configure-data-import-from-an-s3-bucket.html) so that the project is using data in S3 Buckets instead of local storage. +- Connect correct S3 bucket to correct environment: + - Production S3 bucket to Production environment. + - Staging S3 bucket to Staging environment. - *Performance tips are implemented and verified*: - Double-check that you implemented all the [performance guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/performance-guidelines/performance-guidelines.html). - Make sure that, where applicable, you have implemented our recommended Jenkins [performance and stability improvements](/docs/scos/dev/tutorials-and-howtos/howtos/howto-reduce-jenkins-execution-costs-without-refactoring.html). @@ -68,15 +71,15 @@ After pointing the domain name to your Spryker project, some of your customers m ### Testing -- *Test deployments*. [Test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode) to understand how your application will perform and work when deployed. -- *Test All Payment options*. Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). -- *User Acceptance Testing (UAT)*. Besides internal testing, conducting extensive UAT to validate the functionality and user experience from an end-user perspective is always a great idea before opening your system publicly. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers +- *Perform Deployment tests*. [Test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode) to understand how your application will perform and work when deployed. +- *Perform all Payment options tests*. Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). +- *Perform User Acceptance Testing (UAT)*. Beside internal testing, conducting extensive UAT to validate the functionality and user experience from an end-user perspective is always a great idea before opening your system publicly. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers ### Search Engine Optimization (SEO) ### - *Make sure the SEO strategy and plan are defined.* - *Redirects*. If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. - - *Best practices*. Make sure that best practices are implemented. See [Basic SEO techniques to use in your project](/https://docs.spryker.com/docs/scos/dev/best-practices/basic-seo-techniques-to-use-in-your-project.html) + - *Best practices*. Make sure that best practices are reviewed and implemented where applicable. See [Basic SEO techniques to use in your project](/https://docs.spryker.com/docs/scos/dev/best-practices/basic-seo-techniques-to-use-in-your-project.html) ### Training ### @@ -91,11 +94,11 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Cloud -- *Make sure you have an Application Performance Monitoring (APM) set up*: - - Application Performance Monitoring tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). +- *We strongly encourage you to have an Application Performance Monitoring (APM)*: + - APM tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). - Establish robust post-launch monitoring plan, with the aim to watch system's performance and configuring alerting mechanisms.We highly recommend logs to be configured to be gathered in a centralised SIEM system, in order to ensure that effective investigation would be possible in case of security incidents. -- *Verify that your Deploy file is set up correctly*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. -- *Deploy the production environment regularly*. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). +- *Verify that your Deploy file is set up correctly regards your project needs*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. +- *Deploy the production environment regularly*. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). Make sure to test all [recipes] (https://docs.spryker.com/docs/scos/dev/the-docker-sdk/202311.0/installation-recipes-of-deployment-pipelines.html#staging-and-production-environment-recipes). - *The DNS names and strategy for your shop are clear*. - You know how users are going to access your shop. Verify that you control access to the DNS to be able to manage DNS. For example, you want to use `spryker.com` as the domain for your shop, but you want a user to access the Storefront by the `www.spryker.com` subdomain. See [Set up DNS](/docs/ca/dev/set-up-dns.html) for details on how to set up DNS for your application. - Optional: *Delegate DNS*. To find out how to delegate a DNS name, see [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). @@ -105,9 +108,10 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Application - *Prepare and communicate technical debt mitigation plan*. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. -- *Variables and parameter store values are set up*. Double-check whether you have all environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. +- *Variables and parameter store values are set up*. Double-check whether you have all needed environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. - *Third-Party Integrations and Compatibility Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting, port configuration or similar. - *Prepare and implement DB creating on production*. F.e. commit propel migration for production and update deploy file to install DB from the commited migration files. + ### Testing - *Conduct load tests*. Conduct load tests for your application. The sample data used for testing should be comparable to the size and complexity of the production data. @@ -143,7 +147,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti - *Sitemap is generated*. - *File robots.txt is prepared*. - *All the content is prepared*. All the CMS pages and other content are prepared (including meta tags, internal and external links, etc). -- *Favicon is set*. +- *[Favicon](https://en.wikipedia.org/wiki/Favicon) is set*. ## Two weeks before go-live ## @@ -163,7 +167,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti ### Testing ### -- *Perform end-to-end testing on production*. Make sure to test customer journey with all the 3rd party systems switched to production mode. Make sure to cover all the parts of application, including: +- *Perform end-to-end testing on production*. Make sure to test customer journey with all the 3rd party systems switched to production mode. Make sure to cover all parts of the application, including: - Customer registration, account. - Main E-commerce flow (search, checkout/OMS process). - User/Merchant flow. From 414ca66dfcef5ef2bf811461d21ec4430c7389e9 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Fri, 2 Feb 2024 10:10:58 +0100 Subject: [PATCH 17/22] Updated wording based on the comment from the team --- docs/ca/dev/preparation-for-going-live.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 4921235892e..7ed4805fe41 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -107,9 +107,10 @@ Four weeks before your project goes live, ensure you addressed all the items fro ### Application -- *Prepare and communicate technical debt mitigation plan*. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. +- *Prepare and communicate technical debt mitigation plan*. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. Please make sure that all the stakeholders are aware of any missing/incomplete + features and agreed on the mitigation plan. - *Variables and parameter store values are set up*. Double-check whether you have all needed environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. -- *Third-Party Integrations and Compatibility Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting, port configuration or similar. +- *Third-Party Integrations, Compatibility and Performance Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting, port configuration or similar. Make sure to run a performance testing for 3rd party systems, especially if they are involved in some critical customers flows (like Checkout, Place order, etc). - *Prepare and implement DB creating on production*. F.e. commit propel migration for production and update deploy file to install DB from the commited migration files. ### Testing @@ -159,6 +160,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti - *Set up production configuration for all the 3rd party systems* (in environment variables). Make sure to not expose secrets in the codebase. - *Validate BI and analytics integrations*. They should not be connected to your production database, but rather to the provided read replica. Make sure no external system is interacting with your production database. - *Organize a go-live support team*. Prepare a team that can monitor your go-live, react quickly to any issues, and work with the Spryker Support or Operations teams. +- *Configure emails boxes and DMARC policy*. - *Define the exact plan for the go-live day.*: - Define the time of deployment. - Define the exact steps to be performed (including running Jenkins or other scripts if needed). @@ -187,6 +189,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti - Other data - *Make sure that all the translations are provided*. Including all the needed languages. - *Make sure that all Emails are correct*. Including all the needed data and translations. +- *Define glossary update strategy*. F.e. make sure to exclude glossary update during normal deployment or adjust for your business needs. ### SEO ### @@ -196,6 +199,7 @@ Lower or nonproduction environments may not have the same WAF and firewall setti ## Go-live ## - *Perform end-to-end testing on production*. +- Disable email sending restriction (if any). - Remove basic auth from the frontend part and deploy the change. - Run Go-live communication plan. - Disable the destructive pipeline after successful go-live. From 8fb682ea205898ecde7f7b1df515db6154ad05e0 Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Mon, 5 Feb 2024 15:08:33 +0100 Subject: [PATCH 18/22] Updated wording based on the comment from the team --- docs/ca/dev/preparation-for-going-live.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 7ed4805fe41..8f4a0976107 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -206,6 +206,6 @@ Lower or nonproduction environments may not have the same WAF and firewall setti {% info_block infoBox "Don't hesitate to contact us" %} -If your go-live date is close and you feel like you need help with any of the described tasks, contact us by your onboarding case *right away*. +If your go-live date is close and you feel like you need help with any of the described tasks, contact us by your onboarding case *right away*. {% endinfo_block %} From a86a2ade04bd2f7ce551b8032902ee964ed72f0e Mon Sep 17 00:00:00 2001 From: Helen Kravchenko Date: Mon, 12 Feb 2024 14:26:50 +0100 Subject: [PATCH 19/22] Update preparation-for-going-live.md --- docs/ca/dev/preparation-for-going-live.md | 230 +++++++++++----------- 1 file changed, 115 insertions(+), 115 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 8f4a0976107..a9f8238992f 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -4,7 +4,6 @@ description: This instruction explains how to prepare a Spryker project for goin last_updated: Jan 23, 2023 template: howto-guide-template originalLink: https://cloud.spryker.com/docs/preparation-for-going-live -originalArticleId: 738903ac-4167-47ed-93c8-b225c8041582 redirect_from: - /docs/preparation-for-going-live - /docs/en/preparation-for-going-live @@ -13,28 +12,32 @@ redirect_from: {% info_block warningBox "Do not risk your Go-Live!" %} -Points mentioned here are critical for the success of your go live. -We strongly encourage that your project plan contains the tasks related to the go-live checklist and allows enough time for them to be completed. +The preparation activities mentioned here are critical for the success of your go-live process. +We strongly encourage you to include the tasks related to the go-live checklist in your project plan and allocate sufficient time to complete them. {% endinfo_block %} -This document describes how to prepare a Spryker project for going live on Spryker Cloud Commerce OS (SCCOS). +This document describes how to prepare a Spryker project for going live. -We divided the preparation into approximate timeframes, and you can adjust them to your needs. Make sure that all the following tasks are completed one week before going live. +We've divided the preparation into approximate timeframes, and you can adjust them to your needs. Make sure that all of the following tasks are completed at least one week before going live. ## Eight weeks before go-live -Eight weeks before your project goes live, *please inform us about your detailed go-live plans*. Reach out to your Partner or Customer Success Manager and share your go-live plans: the date and time when you want to make your shop accessible to the public. If the time changes, keep us updated. This is critical for Domain Name System (DNS) switching and the hypercare phase we provide before and after your go-live. +Let us know all the details of your go-live plan. Reach out to your Partner or Customer Success Manager and share your go-live plans: the date and time when you want to make your shop accessible to the public. If the time changes, keep us updated. This is critical for Domain Name System (DNS) switching and the hypercare phase we provide before and after your go-live. -Ensure you have considered and/or addressed all the items from the following checklists. +Make sure you've addressed all the items from the following checklists. -### Cloud +### Cloud environments -- *Distributed Denial-of-service (DDOS) prevention or mitigation checked and implemented.* - - Check your concepts for Denial-of-service (DOS) and DDOS prevention or mitigation and check with relevant vendors for products that fit your needs and are compatible with SCCOS. - - Check your concepts for DOS and DDOS prevention Admin panel and Merchant portal. Add basic auth if applicable. For details, see [Configure basic .htaccess authentication](/docs/pbc/all/identity-access-management/{{site.version}}/configure-basic-htaccess-authentication.html) -- *DNS strategy is defined*. If you delegate DNS to Spryker, let us know the date on which to point the domain name to your Spryker project. +- Connected systems are checked and prepared: + - Double-check that all VPC peering and Site-to-Site VPN connections are monitored and secure. We don't usually monitor such connections with external parties. + - Make sure that there is a network diagram that can be used to explain the setup quickly if the need arises. + - Make sure that routing works as expected, and no internal resources are accidentally exposed via the Site-to-Site or VPC peering setup. +- Denial-of-service (DDOS) prevention or mitigation is checked and implemented: + - Check your concepts for Denial-of-service (DOS) and DDOS prevention or mitigation, and check with relevant vendors for products that fit your needs and are compatible with SCCOS. + - Check your concepts for DOS and DDOS prevention in the Back office and Merchant portal. Add basic auth if applicable. For instructions on implementing basic auth, see [Configure basic .htaccess authentication](/docs/pbc/all/identity-access-management/{{site.version}}/configure-basic-htaccess-authentication.html) +- The DNS strategy is defined. If you delegate DNS to Spryker, let us know the date on which to point the domain name to your Spryker project. {% info_block infoBox "DNS propagation" %} @@ -44,90 +47,86 @@ After pointing the domain name to your Spryker project, some of your customers m ### Application -- Upgrade your project's code to match the [latest Demo Shop release](https://docs.spryker.com/docs/scos/user/intro-to-spryker/releases/release-notes/release-notes.html), or at minimum, upgrade to a release that fully supports the Docker SDK (202009.0 and higher). -- Update `spryker/twig` to version 3.15.2 or later because this version and the later ones have important stability improvements over version 3.15.1. -- Migrate the project's database to MariaDB if you don't use it already. -- Split up your project's Zed endpoints as outlined in [Integrating separate endpoint bootstraps](/docs/scos/dev/technical-enhancement-integration-guides/integrating-separate-endpoint-bootstraps.html) guide. -- Verify that your project's service naming scheme is an exact match for the examples inside the [sample deploy-spryker-b2c-staging.yml file](https://github.com/spryker-shop/b2c-demo-shop/blob/202204.0-p2/deploy.spryker-b2c-staging.yml). -- Create [deploy files](/docs/scos/dev/the-docker-sdk/{{site.version}}/deploy-file/deploy-file.html) for each of your environments. These files must be named in a particular manner: `deploy.(project)-(environment).yml`. For example, `deploy.example-staging.yml`. -- [Define a Docker SDK version](/docs/scos/dev/the-docker-sdk/{{site.version}}/choosing-a-docker-sdk-version.html) for the project to use. -- Integrate [FlySystem](/docs/ca/dev/configure-data-import-from-an-s3-bucket.html) so that the project is using data in S3 Buckets instead of local storage. -- Connect correct S3 bucket to correct environment: - - Production S3 bucket to Production environment. - - Staging S3 bucket to Staging environment. -- *Performance tips are implemented and verified*: - - Double-check that you implemented all the [performance guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/performance-guidelines/performance-guidelines.html). - - Make sure that, where applicable, you have implemented our recommended Jenkins [performance and stability improvements](/docs/scos/dev/tutorials-and-howtos/howtos/howto-reduce-jenkins-execution-costs-without-refactoring.html). - - Make sure that, where applicable, you have implemented our [Publish and Sync stability best practices](/docs/ca/dev/best-practices/best-practises-jenkins-stability.html#memory-management). -- *Security guidelines are implemented and verified*: - - Apply Spryker [security guidelines](https://docs.spryker.com/docs/scos/dev/guidelines/security-guidelines.html). - - Make sure that you don't have any plain-text passwords, private keys, or API secrets in config files or git repositories. - - Minimize the use of personal credentials and choose work-specific accounts based on each environment (production, staging, testing). Employing Centralized Credential Management is highly recommended for securely storing and managing these credentials. - - Make sure to install all the [security updates](https://docs.spryker.com/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - - Make sure to install all the security updates from all external packages. [Security checker](https://docs.spryker.com/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html) can be used. -- *Compliance and Legal Checks* - - Consult your legal team to ensure the platform complies with relevant legal and regulatory requirements, especially for international operations. Check [Guidelines for new GDPR rules](https://docs.spryker.com/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html) as a starting point. -- *Admin panel Access Control List (ACL) set up and verified*. Ensure that the admin ACL setup is configured correctly to manage user permissions and access rights within the system's administrative interface. +- Upgrade your project's code to the [latest Demo Shop release](/docs/scos/user/intro-to-spryker/releases/release-notes/release-notes.html). Or at least upgrade to a release that fully supports the Docker SDK (202009.0 and later). +- Update `spryker/twig` to version 3.15.2 or later because this and later versions have important stability improvements over version 3.15.1. +- Migrate the project's database to MariaDB. +- Split the project's Zed endpoints as described in [Integrating separate endpoint bootstraps](/docs/scos/dev/technical-enhancement-integration-guides/integrating-separate-endpoint-bootstraps.html). +- Verify that your project's service naming scheme exactly matches the examples in the [sample deploy-spryker-b2c-staging.yml file](https://github.com/spryker-shop/b2c-demo-shop/blob/202204.0-p2/deploy.spryker-b2c-staging.yml). +- Create [deploy files](/docs/scos/dev/the-docker-sdk/{{site.version}}/deploy-file/deploy-file.html) for each of your environments. File names must follow the naming convention: `deploy.(project)-(environment).yml`. For example, `deploy.example-staging.yml`. +- [Define a Docker SDK version](/docs/scos/dev/the-docker-sdk/{{site.version}}/choosing-a-docker-sdk-version.html). +- Integrate [FlySystem](/docs/ca/dev/configure-data-import-from-an-s3-bucket.html) to use data in S3 Buckets instead of local storage for the project. +- Connect S3 buckets to correct environments: + - Production S3 bucket to a production environment. + - Staging S3 bucket to a staging environment. +- Implement the following performance tips: + - Implement approaches described in all the [performance guidelines](/docs/scos/dev/guidelines/performance-guidelines/performance-guidelines.html). + - Implement the recommended Jenkins [performance and stability improvements](/docs/scos/dev/tutorials-and-howtos/howtos/howto-reduce-jenkins-execution-costs-without-refactoring.html) where applicable. + - Implement the [Publish and Sync stability best practices](/docs/ca/dev/best-practices/best-practises-jenkins-stability.html#memory-management) where applicable. +- Implement the security tips: + - Apply Spryker [security guidelines](/docs/scos/dev/guidelines/security-guidelines.html). + - Make sure that you don't have any plain-text passwords, private keys, or API secrets in config files or Git repositories. + - Minimize the use of personal credentials and choose work-specific accounts based on each environment (production, staging, testing). We highly recommend employing Centralized Credential Management to securely store and manage these credentials. + - Install all the [security updates](/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. + - Install all the security updates from all the external packages. To check if your project modules require security updates, you can use the [Security checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html). +- Perform compliance and legal checks. To ensure the platform complies with relevant legal and regulatory requirements, especially for international operations, consult your legal team. Make sure to check [Guidelines for new GDPR rules](/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html). +- Make sure that the Back Office Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. For instructions on how to configure ACL, see [Users and rights overview](docs/pbc/all/user-management/{{site.version}}/base-shop/user-and-rights-overview.html). ### Testing -- *Perform Deployment tests*. [Test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode) to understand how your application will perform and work when deployed. -- *Perform all Payment options tests*. Before deploying your payment options, test them locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). -- *Perform User Acceptance Testing (UAT)*. Beside internal testing, conducting extensive UAT to validate the functionality and user experience from an end-user perspective is always a great idea before opening your system publicly. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers +- Perform deployment tests. To understand how your application will perform and work when deployed, [test your deployments locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-do-better-deployments.html#bootstrap-with-codedeployymlcode). +- Before deploying your payment options, test them all locally. For more information, see [HowTo: Debug payment integrations locally](/docs/scos/dev/tutorials-and-howtos/howtos/howto-debug-payment-integrations-locally.html). +- Perform User Acceptance Testing (UAT). Besides internal testing, before opening your system publicly, we highly recommend conducting extensive UAT to validate the functionality and user experience from an end-user perspective. If applicable, ensure the platform's compatibility and optimal performance across various devices and browsers -### Search Engine Optimization (SEO) ### +### Search engine optimization (SEO) -- *Make sure the SEO strategy and plan are defined.* - - *Redirects*. If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. - - *Best practices*. Make sure that best practices are reviewed and implemented where applicable. See [Basic SEO techniques to use in your project](/https://docs.spryker.com/docs/scos/dev/best-practices/basic-seo-techniques-to-use-in-your-project.html) +- Make sure the SEO strategy and plan are defined. Do the following: + - Set up redirects. If you are migrating from another shop or project to Spryker, that is, the domain you want to use already points to a shop or a project, you need a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. + - Review and implement the best practices where applicable. For details, see [Basic SEO techniques to use in your project](/docs/scos/dev/best-practices/basic-seo-techniques-to-use-in-your-project.html). -### Training ### +### Training -- *Training and Documentation for End-Users and Admins*: - - Prepare role-specific enablement trainings for all internal users of the platform. These may include: backoffice administrators (incl. role specifics), support assistants and agents, marketplace operators, merchant portal users. - - Consider also external users, such as those interacting with the platform via APIs or 3rd party systems. - - And last but not least, your end customers should be aware of changes (if any) that the new platform may bring. Besides striving for good user experience and transparency, make sure to consult with your legal team about any obligations in that regard. +- Prepare role-specific enablement training for all internal users of the platform. These may include: Back Office administrators (including role specifics), support assistants and agents, marketplace operators, merchant portal users. +- Prepare trainings for external users, such as those interacting with the platform via APIs or third-party systems. +- Make sure your end customers are aware of any changes that the new platform may bring. Besides striving for good user experience and transparency, make sure to consult with your legal team about any obligations in that regard. ## Four weeks before go-live -Four weeks before your project goes live, ensure you addressed all the items from the following checklists. +Make sure you've addressed all the items from the following checklists. ### Cloud -- *We strongly encourage you to have an Application Performance Monitoring (APM)*: - - APM tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). - - Establish robust post-launch monitoring plan, with the aim to watch system's performance and configuring alerting mechanisms.We highly recommend logs to be configured to be gathered in a centralised SIEM system, in order to ensure that effective investigation would be possible in case of security incidents. -- *Verify that your Deploy file is set up correctly regards your project needs*. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your Deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. -- *Deploy the production environment regularly*. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). Make sure to test all [recipes] (https://docs.spryker.com/docs/scos/dev/the-docker-sdk/202311.0/installation-recipes-of-deployment-pipelines.html#staging-and-production-environment-recipes). -- *The DNS names and strategy for your shop are clear*. - - You know how users are going to access your shop. Verify that you control access to the DNS to be able to manage DNS. For example, you want to use `spryker.com` as the domain for your shop, but you want a user to access the Storefront by the `www.spryker.com` subdomain. See [Set up DNS](/docs/ca/dev/set-up-dns.html) for details on how to set up DNS for your application. - - Optional: *Delegate DNS*. To find out how to delegate a DNS name, see [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). - - *Transport Layer Security (TLS) certificates are provisioned*. If you delegate DNS to Spryker, TLS certificates for your endpoints are created automatically. If you want us to create TLS certificates for your endpoints but don't want to delegate your DNS, request the verification of DNS records by the [Support Portal](https://support.spryker.com). If you don't delegate your DNS and want to use your own certificates, provide them to us as described in [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). -- *Decide how email sending should be handled*. If you want to send emails using Spryker, decide whether you want to use the native mail service shipped with Spryker Cloud Commerce OS or integrate a third-party one. If you want to use the native one, let us know the email address that you want to send emails from. We will lift sending restrictions and help you validate the needed DNS name. See [Email service](/docs/ca/dev/email-service/email-service.html) for more information about the default email service and its restrictions. +- We highly recommend you to set up an Application Performance Monitoring (APM). The APM tools help you identify performance bottlenecks in your application. You can request NewRelic APM from Spryker (subject to additional fees). +- To watch the system's performance and configure alerting mechanisms, establish a robust post-launch monitoring plan. To ensure effective investigation in case of security incidents, we recommend configuring logs to gather in a centralized SIEM system. +- Verify that your deploy file is set up correctly and aligns with your project needs. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your deploy file. Your developers need to mock a "live" operation of the project with its production endpoints by adjusting their local host entries. +- Deploy the production environment regularly. This lets you detect potential issues early enough to fix them before going live. For instructions, see [Deploying in a production environment](/docs/ca/dev/deploy-in-a-production-environment.html). Make sure to test all [recipes] (/docs/scos/dev/the-docker-sdk/202311.0/installation-recipes-of-deployment-pipelines.html#staging-and-production-environment-recipes). +- Make sure the DNS names and strategy for your shop are clear. Do the following: + - You know how users are going to access your shop. Verify that you control access to the DNS to be able to manage DNS. For example, you want to use `spryker.com` as the domain for your shop, but you want a user to access the Storefront by the `www.spryker.com` subdomain. For details on how to set up DNS for your application, see [Set up DNS](/docs/ca/dev/set-up-dns.html). + - Optional: Delegate DNS. To find out how to delegate a DNS name, see [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). + - Make sure Transport Layer Security (TLS) certificates are provisioned. If you delegate DNS to Spryker, TLS certificates for your endpoints are created automatically. If you want us to create TLS certificates for your endpoints but don't want to delegate your DNS, request the verification of DNS records through the [Support Portal](https://support.spryker.com). If you don't delegate your DNS and want to use your own certificates, provide them to us as described in [Setting up a custom SSL certificate](/docs/ca/dev/setting-up-a-custom-ssl-certificate.html). +- Decide how email sending should be handled. If you want to send emails using Spryker, decide whether you want to use the native mail service shipped with Spryker Cloud Commerce OS or integrate a third-party one. If you want to use the native one, let us know the email address that you want to send emails from. We will lift sending restrictions and help you validate the needed DNS name. For more information about the default email service and its restrictions, see [Email service](/docs/ca/dev/email-service/email-service.html). ### Application -- *Prepare and communicate technical debt mitigation plan*. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. Please make sure that all the stakeholders are aware of any missing/incomplete - features and agreed on the mitigation plan. -- *Variables and parameter store values are set up*. Double-check whether you have all needed environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. -- *Third-Party Integrations, Compatibility and Performance Checks*. Make sure to test that your third-party integrations (and plugins) are available and working when turned into production mode, using production credential. It is often the case that you'd need to comply with specific additional security measures, such as IP whitelisting, port configuration or similar. Make sure to run a performance testing for 3rd party systems, especially if they are involved in some critical customers flows (like Checkout, Place order, etc). -- *Prepare and implement DB creating on production*. F.e. commit propel migration for production and update deploy file to install DB from the commited migration files. +- Prepare and communicate technical debt mitigation plan. Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. Make sure that all the stakeholders are aware of any missing or incomplete features and agree on the mitigation plan. +- Double-check whether you have all needed environment variables and parameter store values set up. Remember that this has some lead time on our side. If you are still missing parameters, create them. +- Make sure to test that your third-party integrations and plugins are available and working properly when switched to production mode, using production credentials. Often, you may need to comply with specific additional security measures, such as IP whitelisting or port configuration. Conduct performance testing for third-party systems, especially if they are involved in critical customer flows like checkout or order placement. +- Prepare and implement database creation in production. For example, commit Propel migration for production and update deploy file to install the database from the committed migration files. ### Testing -- *Conduct load tests*. Conduct load tests for your application. The sample data used for testing should be comparable to the size and complexity of the production data. -- *Performance testing and environment scale dial-in*. Testing your production environment before officially going live and assessing its performance are critical steps for a successful launch. Because production environments typically employ horizontal auto-scaling, it's essential to conduct stress and performance tests under expected average and peak loads. These tests enable our team to optimize the environment's vertical scaling in advance, ensuring that it can seamlessly handle the expected loads from the get-go, without any potential delays caused by auto-scaling mechanisms. This proactive approach eliminates the need for post-launch adjustments, providing your team with a significant advantage and peace of mind, while delivering a fast and responsive experience to your users right from the first request to the application. +- Conduct load tests. The sample data used for testing should be comparable to the size and complexity of the production data. +- Test your production environment and assess its performance. Since production environments typically employ horizontal auto-scaling, it's essential to conduct stress and performance tests under expected average and peak loads. These tests enable our team to optimize the environment's vertical scaling in advance, ensuring that it can seamlessly handle the expected loads from the get-go without any potential delays caused by auto-scaling mechanisms. This proactive approach eliminates the need for post-launch adjustments. To make this process work effectively, maintain active communication with us. Inform us about your load and performance test plans and share the results so that we can fine-tune the environment to meet your specific requirements. -- We highly recommend performing a penetration test by an independent third-party provider and address the identified vulnerabilities. Before conducting a penetration test, Spryker should be informed at least two weeks in advance by completing the [form](https://docs.google.com/forms/d/e/1FAIpQLSfunn1HY-nsqueP6sRQSLmScUWlmmQyQJk9cscIVIP_5BmuOw/viewform?usp=sf_link). -- *Import real data on production*. After import is done, it is crucial double-checking the completeness and accuracy of migrated data, especially if transitioning from another platform. +- We highly recommend performing a penetration test by an independent third-party provider and addressing the identified vulnerabilities. Before conducting a penetration test, inform Spryker at least two weeks in advance by completing [this form](https://docs.google.com/forms/d/e/1FAIpQLSfunn1HY-nsqueP6sRQSLmScUWlmmQyQJk9cscIVIP_5BmuOw/viewform?usp=sf_link). +- Import real data on production. After the import is complete, double-check the completeness and accuracy of the migrated data, especially if transitioning from another platform. {% info_block warningBox "Data import" %} -You must start working with data of realistic size and quality as early as possible. At this point, you must be importing data regularly to all your environments. We recommend working with the same import data across all your environments. This significantly simplifies troubleshooting and helps you estimate import performance, leading up to your go-live and helping us with environment sizing considerations. We expect all our customers to follow this advice. +Start working with data of realistic size and quality as early as possible. At this point, you must be importing data regularly to all your environments. We recommend working with the same import data across all your environments. This significantly simplifies troubleshooting and helps you estimate import performance, leading up to your go-live and helping us with environment sizing considerations. We expect all our customers to follow this advice. {% endinfo_block %} -- *Validate Checkout/OMS process* +- Validate the checkout and OMS process: - Test general checkout steps. - Test OMS. - Test shipment. @@ -139,73 +138,74 @@ Lower or nonproduction environments may not have the same WAF and firewall setti {% endinfo_block %} -### Data ### +### Data -- *Prepare a data migration plan*. Include all the data. +Prepare a data migration plan. Include all the data. -### SEO ### +### SEO -- *Sitemap is generated*. -- *File robots.txt is prepared*. -- *All the content is prepared*. All the CMS pages and other content are prepared (including meta tags, internal and external links, etc). -- *[Favicon](https://en.wikipedia.org/wiki/Favicon) is set*. +- Generate sitemap. +- Prepare the `robots.txt` file. +- Prepare all the CMS pages and other content, including meta tags, internal and external links, etc. +- Set the [favicon](https://en.wikipedia.org/wiki/Favicon). -## Two weeks before go-live ## +## Two weeks before go-live -- *Code freeze*. We recommend having a code freeze at least two weeks before going live. -- *Double-check the go-live date*. If any of the preceding tasks are not complete, postpone your go-live or discuss with us how to complete them in time. DNS changes are especially sensitive to deadlines. Due to how the DNS system works, any DNS changes take time to take effect. -- *Make sure that the rollback strategy is still valid*. Check that you have everything you need to recover from an unforeseen issue with the newest version of the project you are deploying. -- *Make sure that DNS is set*. -- *Make sure that 3rd party systems are switched to "Production mode"* - - *Set up production configuration for all the 3rd party systems* (in environment variables). Make sure to not expose secrets in the codebase. - - *Validate BI and analytics integrations*. They should not be connected to your production database, but rather to the provided read replica. Make sure no external system is interacting with your production database. -- *Organize a go-live support team*. Prepare a team that can monitor your go-live, react quickly to any issues, and work with the Spryker Support or Operations teams. -- *Configure emails boxes and DMARC policy*. -- *Define the exact plan for the go-live day.*: +Make sure you've addressed all the items from the following checklists: + +- Implement the code freeze. We recommend having a code freeze at least two weeks before going live. +- Double-check the go-live date. If any of the preceding tasks aren't complete, postpone your go-live or discuss with us how to complete them in time. DNS changes are especially sensitive to deadlines. Due to the way the DNS system works, any DNS changes take time to take effect. +- Make sure that the rollback strategy is still valid. Check that you have everything you need to recover from an unforeseen issue with the newest version of the project you are deploying. +- Make sure that DNS is set up. For details on the DNS setup, see [Set up DNS](/docs/ca/dev/set-up-dns.html). +- Make sure that the third-party systems have been switched to the production mode: + - Set up production configuration for all the third-party systems (in environment variables). Make sure not to expose secrets in the codebase. + - Validate BI and analytics integrations. They should not be connected to your production database but rather to the provided read replica. Make sure no external system is interacting with your production database. +- Establish a go-live support team. Have a team that can monitor your go-live process, react quickly to any issues, and work with the Spryker Support or Operations teams. +- Configure email boxes and DMARC policy. +- Define the exact plan for the go-live day: - Define the time of deployment. - - Define the exact steps to be performed (including running Jenkins or other scripts if needed). - - *Prepare a go live communication plan*. Develop a communication plan to inform stakeholders, customers, and support teams about the launch date and any changes or updates. + - Define the exact steps to be performed, including running Jenkins or other scripts, if needed. + - Prepare a go-live communication plan: Develop a communication plan to inform stakeholders, customers, and support teams about the launch date and any changes or updates. -### Testing ### +### Testing -- *Perform end-to-end testing on production*. Make sure to test customer journey with all the 3rd party systems switched to production mode. Make sure to cover all parts of the application, including: - - Customer registration, account. - - Main E-commerce flow (search, checkout/OMS process). - - User/Merchant flow. - - etc +- Perform end-to-end testing on production. Make sure to test the customer journey with all the third-party systems switched to the production mode. Make sure to cover all parts of the application, including: + - Customer registration, account + - Main E-commerce flow (search, checkout/OMS process) + - User or Merchant flow -### Data ### +### Data -- *Remove all the demo data from the environment*. The project should only use the real data that will be used after the go-live. Remove all the demo data that comes with the Spryker repository, which includes demo and admin users. Demo users in a live shop pose a significant security risk for your project. -- *Make sure that real data is set on production* +- Remove all the demo data from the environment. The project should only use the real data that will be used after the go-live. Remove all the demo data that comes with the Spryker repository, which includes demo and admin users. Demo users in a live shop pose a significant security risk for your project. +- Make sure that real data is set on the production environment: - Categories - - Product and all related data (prices, offers, attributes, images, stock, labels, reviews and ratings, cross and up selling etc.) - - Customers, Companies, Users, Merchants + - Product and all related data (prices, offers, attributes, images, stock, labels, reviews and ratings, cross and up-selling etc.) + - Customers, companies, users, merchants - Taxes - Discounts - CMS pages (including homepage, CSM blocks, final terms & conditions check) - Custom data - Other data -- *Make sure that all the translations are provided*. Including all the needed languages. -- *Make sure that all Emails are correct*. Including all the needed data and translations. -- *Define glossary update strategy*. F.e. make sure to exclude glossary update during normal deployment or adjust for your business needs. +- Make sure that all the translations are provided. Double-check that all the needed languages are available. +- Make sure that all emails are correct. Double-check that all the needed data and translations are available. +- Define the glossary update strategy. For example, make sure to exclude glossary updates during the normal deployment or adjust the strategy according to your business needs. -### SEO ### +### SEO -- *File robots.txt is set up*. -- *All the content is set*. All the CMS pages and other content are set (including meta tags, internal and external links, etc). -- Optional: *Redirects are set up.* +- Make sure that the `robots.txt` file is set up. +- Make sure that all the content is set. Verify that all the CMS pages and other content are set, including meta tags, internal and external links, etc. +- Optional: Set up redirects. -## Go-live ## -- *Perform end-to-end testing on production*. -- Disable email sending restriction (if any). -- Remove basic auth from the frontend part and deploy the change. -- Run Go-live communication plan. -- Disable the destructive pipeline after successful go-live. +## Go-live +- Perform the end-to-end testing on production. +- Disable email sending restrictions, if any. +- Remove basic authentication from the frontend part and deploy the change. +- Run the go-live communication plan. +- Disable the destructive pipeline after the successful go-live process. {% info_block infoBox "Don't hesitate to contact us" %} -If your go-live date is close and you feel like you need help with any of the described tasks, contact us by your onboarding case *right away*. +If your go-live date is close and you need help with any of the described tasks, contact us by your onboarding case *right away*. {% endinfo_block %} From bd15db148a41f9271af5c7348436b7f453d198cb Mon Sep 17 00:00:00 2001 From: helen-laktionova Date: Thu, 15 Feb 2024 12:04:22 +0100 Subject: [PATCH 20/22] Feedback from Thomas --- docs/ca/dev/preparation-for-going-live.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index a9f8238992f..56590ca763e 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -12,9 +12,7 @@ redirect_from: {% info_block warningBox "Do not risk your Go-Live!" %} -The preparation activities mentioned here are critical for the success of your go-live process. -We strongly encourage you to include the tasks related to the go-live checklist in your project plan and allocate sufficient time to complete them. - +The preparation steps listed here are mandatory because they are critical to the success of your go-live. We strongly encourage you to complete these steps (if applicable for your project) because we won’t be able to resolve the issues related to the steps not completed in time. Ensure that your project plan contains the tasks related to the go-live checklist and allows enough time for them to be completed. {% endinfo_block %} From b0991508de189dfcee8741276cb3357bed086297 Mon Sep 17 00:00:00 2001 From: Helen Kravchenko Date: Thu, 15 Feb 2024 15:25:55 +0100 Subject: [PATCH 21/22] Update preparation-for-going-live.md --- docs/ca/dev/preparation-for-going-live.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index 56590ca763e..c23da102e45 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -12,7 +12,7 @@ redirect_from: {% info_block warningBox "Do not risk your Go-Live!" %} -The preparation steps listed here are mandatory because they are critical to the success of your go-live. We strongly encourage you to complete these steps (if applicable for your project) because we won’t be able to resolve the issues related to the steps not completed in time. Ensure that your project plan contains the tasks related to the go-live checklist and allows enough time for them to be completed. +The preparation steps listed here are mandatory as they are crucial for the success of your go-live. We strongly encourage you to complete these steps if they are applicable to your project, as we won't be able to resolve issues related to steps not completed in time. Make sure that your project plan contains the tasks related to the go-live checklist and allocates enough time for their completion. {% endinfo_block %} From a0cf31c747f6a3595ef01224e592e8b5c8adf57e Mon Sep 17 00:00:00 2001 From: Helen Kravchenko Date: Thu, 15 Feb 2024 15:52:35 +0100 Subject: [PATCH 22/22] fixing a link --- docs/ca/dev/preparation-for-going-live.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ca/dev/preparation-for-going-live.md b/docs/ca/dev/preparation-for-going-live.md index a3ea2efcb63..5f5f2e95f8d 100644 --- a/docs/ca/dev/preparation-for-going-live.md +++ b/docs/ca/dev/preparation-for-going-live.md @@ -67,7 +67,7 @@ After pointing the domain name to your Spryker project, some of your customers m - Install all the [security updates](/docs/scos/user/intro-to-spryker/whats-new/security-updates.html) from all Spryker packages. - Install all the security updates from all the external packages. To check if your project modules require security updates, you can use the [Security checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.html). - Perform compliance and legal checks. To ensure the platform complies with relevant legal and regulatory requirements, especially for international operations, consult your legal team. Make sure to check [Guidelines for new GDPR rules](/docs/scos/user/intro-to-spryker/support/guidelines-for-new-gdpr-rules.html). -- Make sure that the Back Office Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. For instructions on how to configure ACL, see [Users and rights overview](docs/pbc/all/user-management/{{site.version}}/base-shop/user-and-rights-overview.html). +- Make sure that the Back Office Access Control List (ACL) setup is configured correctly to manage user permissions and access rights within the system's administrative interface. For instructions on how to configure ACL, see [Users and rights overview](/docs/pbc/all/user-management/{{site.version}}/base-shop/user-and-rights-overview.html). ### Testing