Deployment and environments
Analyzing the testing and deployment strategy of your Sitefinity CMS instance is a crucial step in planning the integration and setup of Digital Experience Cloud and how and what data you collect.
Essentially, you need to make sure you do not track data that you do not need or that pollutes your data result sets. That is, data reported from your real customers interacting with your live site is not mixed with the data reported as a result of testing or deployment procedures, produced by quality assurance engineers, automated tests, and so on.
The following table summarizes the scenarios and recommendations for DEC setup, based on your deployment strategy and number of environments.
Your deployment process consists of multiple environments different from each other in the development and deployment process, for example, Development, System Integration Testing, User Acceptance Testing, and Production.
|To avoid having garbage test data, configure dedicated data centers for each environment. You are still able to verify tracking is functioning properly by testing tracking on testing and production environments.
NOTE: You can also turn off reporting completely for some of the environments, for example, the Development environment. For more information, see Stop DEC from tracking your websites.
You need to ensure connecting to DEC in each environment is as easy as possible by setting the connection parameters (credentials, data center selected, switching on and off of reporting) during deployment. You do this by utilizing different configurations or applying configuration transformations for each environment.
|Production and staging aggregation (Blue-Green deployment)
The main benefits of the approach are related to being able to deliver the tested release candidate to production as quick as possible and with no downtime (if possible).
|Configure the Sitefinity CMS DEC Connector with a single data center and a single data source across the deployment environments.
|Two production environments on two Sitefinity sites
This setup is related to considerations about delivery of the site content. You have two Sitefinity sites - one for production and one for content editing. You deliver the content to production with SiteSync.
|Configure the Sitefinity CMS DEC Connector with a single data center and a single data source for both environments.
NOTE: It is possible that you mix deployment strategies, for example, when staging environment is used instead of user acceptance testing environment. If so, you can use as many data centers as needed but you must always ensure that the blue-green deployments are configured to use one and the same data center.
Testing and validation
Another aspect worth considering is the execution of automatic or manual tests against the production environment. This case is especially applicable to the Blue-Green strategy, where the staging environment is used to extensively test the application before the Production and Staging slots are swapped. Another good example of such a case is when you are running heartbeat tests against your live site in set time intervals to ensure that the site is still working properly.
When running tests, to eliminate the pollution of the live environment customer data, reported to the production DEC data center, we recommend two approaches:
|IP filtering with DEC
||You disregard all data reported by the IP addresses you configure. This implies that you need to make sure that the tests are always run from a known machine(s) with stable IP address. In case you are using 3rd party systems like PagerDuty or PingDom, usually the vendors offer a list of all IP addresses their services use. Thus, to perform the checks, you need to filter in DEC these IP addresses to prevent data pollution. The IP filtering approach is good when your primary goal is to test the site but not the integration with DEC. For more information, see Filter tracked data.
|Test with particular DEC contact
||In case you want to test the integration between your site and DEC, we recommend performing the tests on behalf of particular DEC contact(s). This approach ensures all reported data is associated with the particular contact(s) in DEC and you can later (preferably right after the testing effort is completed) delete the contact from DEC, along with all associated reported data. Thus, you minimize the impact of testing data to the actual analysis of the behavior data by your real website visitors.
NOTE: When employing this approach, you do not set IP filtering rules.