• Overview
• Deploy a Staging Server
• Upgrade Scenario
• Test/Development Scenarios
• Configuration Changes to Differentiate Staging Environments

Overview

Staging servers are used for many different reasons, including:

• Ensuring that an upgrade of LabKey Server does not break any customization.
• Testing new modules, views, or queries being developed.
• Running usage scenarios on test data prior to launching to a large group of users.

Deploy a Staging Server

The general process is:

1. Make a copy of the production database.
2. Bring up a separate LabKey Server using that copy. For example, if your server is "www.myDomain.org" you might name it "staging.myDomain.org".
3. Run any actions or tests you like on "staging.myDomain.org". Any changes made to this database copy will not be reflected on production.

Upgrade Scenario

In the upgrade scenario, typically a new snapshot of the production database is taken, then the new version of LabKey Server installed and started using that database copy. This gives administrators a 'real world' test of the upgrade itself as well as an opportunity to fully vet the new version against their own use cases.

Carefully review the upgrade logs and perform some of your own usage cases to test the new version. If there are issues here, you may have missed an upgrade step or could have an incompatible version of a component. This "test upgrade" also gives you knowledge of how long the upgrade will take so that you can adequately prepare production users for the real upgrade.

Once you are satisfied that the upgrade will go smoothly, you can upgrade production. Once production is up to date, the staging server can be taken down.

Test/Development Scenario

Another excellent use of a staging environment, possibly maintained on an ongoing basis, is for testing new development, scripts, modules, pages, or other utilities.

The process of setting up such a server is the same, though you may choose to then maintain the 'staging database' copy on an ongoing basis rather than taking a new production snapshot for each release. Using at least an approximation of a production database environment will give developers a realistic platform for new work. However, consider that you may not want to use a copy of production if PHI/PII is included. In this case, you might start from a new database and build test data over time.

If you want to use both a version for upgrade and a version for development testing, you might name this latter system "test.myDomain.org" or "dev.myDomain.org". For the development happening here to be easily transferred to production, this type of server typically runs the same version as production. This server is upgraded to the latest version of LabKey just before the production server is upgraded, allowing another full test of the upgrade with any new functionality in a similar environment.

Configuration Changes to Differentiate Staging Environments

When using any server on a copy of the production database, it is important to make sure that users can tell they are not on the real system. Both so that testing of unusual usage scenarios does not happen on the 'real' system and so that real work is not lost because it is done on the staging server.

Doing things like changing the color scheme on the staging server will help users know which environment they are working on and avoid inadvertent changes to the production environment.

• Change the Site Settings
• Change the Look and Feel
• Other Settings (For Advanced Users)

Considerations

1. If you use SQL statements to make the changes suggested on this page, make them after you restore the database on the staging server but before you start LabKey Server there.

Change the Site Settings

Change the Site Settings Manually

1. Log on to your staging server as a Site Admin.
2. Select (Admin) > Site > Admin Console.
3. Under Configuration, click Site Settings.
4. Change the following:

• (Recommended): Base server url: change this to the URL for your staging server.
• Optional Settings to change:
• Configure Security > Require SSL connections: If you want to allow non-SSL connections to your staging server, uncheck this box.
• Configure Security > SSL port number: If your SSL port number has changed. By default Tomcat will run SSL connection on 8443 instead of 443. Change this value if you staging server is using a different port.
• Configure pipeline Settings > Pipeline tools: If your staging server is installed in a different location than your production server, change this to the correct location for staging.

Change the Site Settings via SQL Statements

These commands can be run via psql or pg_admin.

To change the Base Server URL run the following, replacing "http://testserver.test.com" with the URL of your staging server:

UPDATE prop.Properties SET Value = 'http://testserver.test.com'
  WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s."set" = Properties."set") = 'SiteConfig'
  AND Properties.Name = 'baseServerURL';

To change the Pipeline Tools directory run the following, replacing "/path/to/labkey/bin" with the new path to the Pipeline tools directory:

UPDATE prop.Properties SET Value = '/path/to/labkey/bin'
  WHERE Name = 'pipelineToolsDirectory';

To change the SSL Port number run this, replacing "8443" with the SSL port configured for your staging server:

UPDATE prop.Properties SET Value = '8443'
  WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s.Set = Properties.Set) = 'SiteConfig'
  AND Properties.Name = 'sslPort';

To disable the SSL Required setting:

UPDATE prop.Properties SET Value = 'false'
WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s."set" = Properties."set") = 'SiteConfig'
  AND Properties.Name = 'sslRequired';

Change the Look and Feel

Change the Look and Feel Manually

1. Logon to your staging server as a Site Admin.
2. Select (Admin) > Site > Admin Console.
3. Under Configuration, click Look and Feel Settings.
4. Change the following:

• System description: Add a prefix, such as the word "TEST" or "Staging" to the text in this field
• Header short name: This is the name shown in the header of every page. Again, prepending "TEST" to the existing name or changing the name entirely will indicate it is the staging server.
• Theme: Use the drop-down to change this to a different theme.

Change the Look and Feel Settings via SQL statements

These commands can be run via psql or pg_admin

To change the Header short name for the Site and for all Projects, run this, replacing "LabKey Staging Server" with the short name for your staging server.

UPDATE prop.Properties SET Value = 'LabKey Staging Server'
  WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s."set" = Properties."set") = 'LookAndFeel'
  AND Properties.Name = 'systemShortName';

To change the System description for the Site and for all Projects, run this, replacing "LabKey Staging Server" with the system description for your own staging server:

UPDATE prop.Properties SET Value = 'LabKey Staging Server'
  WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s."set" = Properties."set") = 'LookAndFeel'
  AND Properties.Name = 'systemDescription';

To change the Web Theme, or color scheme, for the Site and for all Projects, run this, replacing "Harvest" with the name of the theme you would like to use on your staging server.

UPDATE prop.Properties SET Value = 'Harvest'
   WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s."set" = Properties."set") = 'LookAndFeel'
  AND Properties.Name = 'themeName';

Other settings (For Advanced Users)

Below are some additional configuration settings that you may find useful.

Deactivate all non-Site Admin users

This is important to do as it will not allow one of your researchers to accidentally log into the Staging Server.

update core.Principals SET Active = FALSE WHERE type = 'u' AND UserId NOT IN
  (select p.UserId from core.Principals p inner join core.Members m
  on (p.UserId = m.UserId and m.GroupId=-1));

Mark all non-complete Pipeline Jobs to COMPLETE

This will ensure that any Pipeline Jobs that were scheduled to be run at the time of the Production server backup do not now run on the staging server. This is highly recommended if you are using MS2, Microarray or Flow.

UPDATE pipeline.statusfiles SET status = 'ERROR' WHERE status != 'COMPLETE' AND status != 'ERROR';

Change the Site Wide File Root

Only use this if the Site File Root is different on your staging server from your production server

UPDATE prop.Properties SET Value = '/labkey/labkey/files'
  WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s."set" = Properties."set") = 'SiteConfig'
  AND Properties.Name = 'webRoot';

Have the Staging Server start up in Admin Only mode

UPDATE prop.Properties SET Value = 'true'
  WHERE (SELECT s.Category FROM prop.PropertySets s WHERE s."set" = Properties."set") = 'SiteConfig'
  AND Properties.Name = 'adminOnlyMode';

Related Topics

• Administration