LCC eLearning

Explore

Archived / Completed

Staging Sites

Justification

A site backup and retreival plan is an excellent tool to ensure site uptime, but it is only one part of a site stability plan. It is also important to have a testing site on the opposite side, where major changes and revisions can be implemented and tested before being launched to production. This ensure that any major changes such as new plugins, significant site revisions, or design changes do not break the primary structure or content of the site and everything remains usable on the customer-facing pages.

⁠

Scope

This project will develop and implement testing sites for both the

eLearning Student Resources⁠

and

eLearning Instructor Resources⁠

sites. These sites will be used to test:

New Plugin Installations

Site Content Reorganizations

Wordpress Theme Changes

Other significant site changes as necessary.

They may also potentially be used as a staging area to test updates to site pages and content, to improve ID workflow. This would allows Instructional Designers and other members of the elearning team to develop documentation and pages ahead of time in Wordpress, and then push the content out to production sites once the new feature has launched.

⁠

Research Questions

The majority of these answers came from a F2F meeting w/ Ariel on 11.9.21

How do we schedule content/changes from staging to production, and is that even best practice—or should they be kept separate and manually updated?

It is best practice to keep the databases completely separate. While there are technically plugins that allow scheduling from staging to production, staging is not typically used for testing/deployment of content, just large new site features like reorganizations, plugins, theme/layout, etc.

How do we get a copy of the current site/database on staging?

Ariel can help with this when we get to that point.

Benefits/downsides of having different cPanel accounts for staging/production?

Maintaining both sites as one cPanel account simplifies account management and the backup procedure. While it is technically possible to split them off, there isn’t a significant advantage to doing so.

Is there any value in backing up the staging environment separately from production?

Generally no. And because of how our sites are configured on the host and via cPanel, this wouldn’t be an option anyway.

What types of edits/changes should be made first in staging, vs. which are safe to just make in production immediately?

Content changes can largely be made in production unless they are to a specific area like a widget, or a page with more complex layout. Reorgs, theming, layout, plugins, etc., should be tested on stating first

Will staging/production require separate accounts for user access?

Yes. Each staging site functions exactly like another Wordpress instance

Is it best practice to do a local test environment first for -big- changes (like a theoretical site reorganization), then test those changes in staging, then move eventually to production?

It’s not essential, but it’s not a bad idea either. Typical workflows involve building/testing on a local instance, pushing to Staging, testing, then pushing to production. Dave’s Note: After checking with other developers/development teams, the proper setup is local dev, staging on server, push to production for significant changes.

⁠

Staging Site Tasks

Staging Site Tasks

Task

Est. Effort

People

Done

Completed On

Determine Current Site Structure

11/10/2021

Determine Staging Process / Requirements

11/10/2021

Setup Local Test Environment

11/11/2021

Deploy Staging Sites

11/16/2021

Logins / Credentials for ID Team

11/16/2021

Document / Train eLearning on Staging Process

There are no rows in this table

⁠

Resources

Wordpress Local Testing Environment Software:

Local WP⁠

⁠

cPanel Configuration:

cPanel Login⁠

⁠

eLearning Sites Configuration as of 11/12/21

eLearning Sites Configuration as of 11/12/21

Site

Public URL

Domain

SQL Database

Server Directory

Instructor - Production

https://elearning.lcc.edu

elearning.lcc.edu

elearnin_wp5

/public_html/

Student - Production

https://elearning.lcc.edu/students/

elearnin_wp6

/public_html/students

Instructor Staging — Current

⁠

https://elearning.lcc.edu/itest/⁠

⁠

itest.elearning.lcc.edu⁠

⁠

elearnin_itest

/public_html/itest

Student Staging — Current

⁠

https://elearning.lcc.edu/stest/⁠

⁠

stest.elearning.lcc.edu⁠

⁠

elearnin_stest

/public_html/stest

Instructor - Staging (Out of Date)

https://elearning.lcc.edu/staging/

staging.elearning.lcc.edu

elearnin_stage

/public_html/staging

Student - Staging (Out of Date)

https://elearning.lcc.edu/staging2/

staging2.elearning.lcc.edu

elearnin_staging2

/public_html/staging2

There are no rows in this table

⁠

Deliverables

Instructor Test Site:

https://elearning.lcc.edu/itest/⁠

⁠

Student Test Site:

https://elearning.lcc.edu/stest/⁠

Test Site Locations / Credentials

The sites are protected by the

Password Protection⁠

plugin to prevent outside users from accidentally accessing the testing sites. This will allow us to test new features, layouts and themes without making them public, and still protecting the integrity of our production sites. The password to view the test sites is: NU_smod!hoof0jald. To access the WordPress Dashboard for the test sites, append /wp-admin/ to the end of the test site URL (i.e. https://elearning.lcc.edu/itest/wp-admin/). You can use the same credentials to login to the dashboard as the production WordPress sites.

Content Update Process

In order to isolate and protect the production environment, there is no direct way to import created WordPress content from the test to production sites, or vice versa. This means we will continue to add and edit content, including: pages, posts, sliders, and eLearning Live events in the production environment. An initial exploration of this project was to determine if there was a way we could schedule updates from test to production—this ended up not being possible.

Theme / Organization Update Process

Continued WordPress development will first be done in a local development environment set up using

Local WP⁠

. This is available for both Mac and PC if other members of the eLearning team would like to setup their own local environments, or if a future person comes into the role.

Initial development of new features will be done on this local test environment to work out as many bugs as possible in an environment that is completely removed from the Once the development has been tested, it will be moved to the test sites. Once it is live on the test sites, it can be tested in an environment that is closer to production and available for multiple people to test.

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.