Success to a release depends not only on how well Project is being managed, requirements are being captured to preciseness, technical architects’ layout the correct design or team of efficient developers and testers put their effort to make things working, but also how well we prepared our delivery for pushing it LIVE; whether we have thoroughly tested the end product per expected LIVE environment. That’s where essence of STAGING environment comes in picture. The thumb rule is Staging environment should imitate the Production to greatest extent possible to avoid any surprises during cut-over activities. This way we not only get early pointers around the success or failure but create a sense of confidence among the team as well.
Below are some of key notes that should be taken care of while preparing Staging environment for UAT:
1 Environment Setup
1.1 Environment configuration
1.1.1 Software configuration
The software configuration and version must be exactly same as planned Production environment. That includes OS, Web server, application framework and any third party plugin. Any difference in the version and sub-version can result in deviating behavior which might get different to identify at later stage.
1.1.2 Hardware configuration
In case, similar hardware is not feasible for UAT environment due to cost constraint (which is justifiable), an appropriate scale down version still can work for one. But that needs a keen thought and one should analyze the expected audience base and engagement prior taking decision on scale down version and its extent.
1.3 Dummy accounts for third-parties involved
If we are expecting to use some third-party integration like Disqus for Commenting System & moderation, Site Catalyst or Google Analytics for web analytics, having separate account for UAT environment would make sense so that information on the actual account while on Production does not get messy and reflect incorrect picture at a later stage.
2 Restricting access
2.1 For Public
Consider a situation where website relating to an important campaign gets publicly accessible on UAT environment prior to actual launch. From marketing perspective, this will not only steals away the WOW-factor associated with the campaign but also provides an edge to competitors. Thus, securing/restricting public access is utmost requirement here. There are number of ways to achieve this like Basic authentication, restricting access based on IP@ or geographical location and so on.
2.1 For Crawlers
In order to avoid Duplicate Content or risk of picking up URLs of Staging environment, URLs or web-pages should be excluded from Google indexing.
The exclusion can be realized:
- By adding a noindex tag in the
<head>section of the copy and staging page
<meta name="robots" content="noindex" />
- By disallowing crawling using the txt file
Disallow: /
- By using .htaccess to protect the page with a password
3 Follow correct strategy for environment refresh
3.1 Database from Production
Updating Database from Production is the foremost step as this helps in providing exact user journey where dynamic behavior is involved. In case the website is expected to launch for the first time, one should ask the client for the sample data followed by executing the test cases accordingly.
3.1.1 Mask any PI or financial data related information
Mask all information that identifies uniquely identifies a person and exposes personal or financial information like email address, mobile number, passport, tax/back account/credit card numbers etc. Exposing any such information add a risk to getting them miss-used which can have severe consequence. All such should be masked or replaced with a dummy information.
3.1.1.1 Keep note of all fields or columns that store PI information
Owner of website should keep a note of all such fields storing sensitive information about client and make sure they are timely replaced with mask as part of DB refresh.
3.1.1.2 Create scripts to automate the masking
Once fields are identified, automating masking process by scripts is a good option to make process even more secure and fast.
3.1.2 Replace Production domain reference with staging environment
If URLs inside web applications or websites are relative, probably you the lucky one. But consider the scenario with URLs are absolute and performing any GET or POST operation results in opening resource or submitting request to other environment. As a QA person, it could be a time consuming & frustrating activity to track URL at each action and then switching back to UAT environment again and again. This, in case URLs are absolute, the domain name of Production should be replaced by the domain name of UAT environment.
3.1.3 Update Email recipient of Lead Submission forms with dummy email addresses
To avoid accidental delivery of emails to actual recipients from UAT environment, the email address should be replaced with valid test accounts. This way one test the email deliveries as well as avoid risk of spamming the end users.
3.2 Code from Development
3.2.1 Create the build in manner that the same should be deployed on Production
DO NOT CREATE SEPARATE BUILD FOR PRODUCTION
The build deployed on UAT would tested by QA team & signed-off by client should only be considered for further deployment to Production. There is no point of creating a separate build for Production and assuming it would work similar to one deployed on UAT environment. Doing such adds a high risk to your delivery and for which only development team is accountable.
3.2.2 Use configuration settings to address environment specific behaviors (if any)
Most of frameworks today provides as an inbuilt support for Configuration files which can help addressing the concern of creating separate build for Staging & Production environment. They could be XML based web.config in case of .NET or text based wp-config.php for WordPress and so on. All environment related configurations can be laid down here and can be configured outside the app build.