Product Bulletin 106 - Edsby Sandbox and Demo Systems

Feb. 24nd, 2016

Background

Edsby becomes a “mission-critical” service for education organizations as they embrace more and more of the capabilities Edsby provides across all key stakeholders in the organization. Over time larger education organizations often ask how they could best handle certain tasks related to Edsby such as:

• How can they develop training material and conduct demonstrations without exposing real user data?
• How can they test out changes to core systems that feed Edsby with data (such as the Student Information System) without impacting their production Edsby system?
• How can they test pre-release Edsby software on their own production data without impacting their production Edsby system? 
• How can all of the above be provided in an environment that incorporates the specific customizations an organization has put in place for their preferred way of using Edsby?

These are important capabilities for education organizations to have access to. This Edsby Tech Note describes how these facilities can be provided. 

Approach

After careful consideration of the requirements the following approach will be taken:

1. Edsby Demo Site: Each Edsby school district customer will be provided with a dedicated Edsby demonstration site that has completely fictional users, classes and schools.  This site is designed to be useful for doing demonstrations, for the creation of training material (screen snaps, videos), and for enabling key staff such as IT, Support and Training staff to have a site in which they can explore how Edsby works without having to worry about exposing customer data or impacting the production system. 
2. Edsby Sandbox Site: Each Edsby school district customer will be provided with a dedicated sandbox site that can be used for testing out new Edsby software releases prior to them going in to production, and that can be used for testing out changes in related systems such as the Student Information System (SIS). This site will typically be used by IT staff assigned to Edsby.

These sites are described in more detail below.

Edsby Demo Site

An Edsby demo site will be set up for each school district customer. This site will have the name “xyzdemo.edsby.com” where “xyz” is the site name of the production Edsby site.  This site will be configured as a school district with two schools – one elementary school and one secondary school. This will enable the demo site to span the kind of activities and usages that happen across the K-12 spectrum. Since it is configured as a district it will enable district level roles and features that only work at the district level to be tested. Examples of the latter include the Schools Zoom, posting news to multiple schools, and provisioning report cards across a district.

User Data: All users on the demo site will be entirely fictional and will be provided by Edsby. Each of the two schools will include hundreds of students and parents, and scores of teachers and classes. 

Scheduling Data: Edsby will provide a set of representative classes at each school that include a typical range of subjects and a typical set of students enrolled in them. This data will be refreshed yearly by the Edsby team so that an active set of classes is available all year round.

Account Data: The demo system will come with a standard set of provisioned userIDs and passwords to cover a modest set of students, staff and parents. School districts are welcome to configure userIDs and passwords for additional user accounts if desired. Note that each school district will have a custom set of passwords for its “standard” demo accounts to protect the privacy of their demo system.

User Generated Content: Frequent users of this system (such as district trainers) may create demonstration classes with illustrative content in them. Classes will be archived each year in the summer time. However just as in the real product “teachers” can find archived classes from the previous year and copy course content into new classes for the new year.

Site Configuration Data: Each Edsby system is configured to support the way the customer prefers their system to operate. This includes a range of configuration options including privacy settings, assessment schemes, attendance codes, and expectations/strands/outcomes. The Edsby team will work to have each customer’s demo site to have the same configuration data settings as the production system. 

Customizations: The Edsby team will maintain the same set of customizations that have been applied to the production site on the demo site. This is important so that demonstrations and content generated from the demonstration site reflect the way the district’s production site will work.

Edsby Sandbox Site

An Edsby sandbox site will be set up for each school district customer. This site will have the name “xyzsandbox.edsby.com” where “xyz” is the site name of the production Edsby site.  

This site will serve a number of different purposes:

• testing pre-production Edsby software
• testing pre-production SIS software
• testing out changes in SIS data content
• testing out changes in Edsby SIS integration logic
• developing, testing and demonstrating Edsby customizations
• testing out changes in Edsby exports
• testing how various Edsby features work (especially district level features)

User and Scheduling Data: The Edsby sandbox site is designed to be connected via EdsbyLink to a district-supplied data source (SIS) that matches the production data source in structure. The school district needs to run a second EdsbyLink to support this.  The district is responsible for selecting the data set that is included in this sandbox setup. Typical options include:

1. a mirror copy of the district’s production database
2. a subset of the district’s production database
3. an anonymized version of the district’s production database

Account Data: The default setup for the sandbox system will be to only provision one account with a userID and password. This will be one of the board’s “District IT” accounts. This account can be used to provision up selected additional accounts with userIDs and passwords as desired by the district. Note that these accounts will all be authenticated locally in Edsby rather than going through any external authentication source such as Active Directory. 

User Generated Content: Frequent users of this system may create demonstration classes with illustrative content in them. Classes will be archived each year in the summer time. However, just as in the real product “teachers” can find archived classes from the previous year and copy course content into new classes for the new year.

Site Configuration Data: Each Edsby system is configured to support the way the customer prefers their system to operate. This includes a range of configuration options including privacy settings, assessment schemes, attendance codes, and expectations/strands/outcomes. The Edsby team will work to have each customer’s demo site to have the same configuration data settings as the production system. 

Customizations: The Edsby team will maintain the same set of customizations that have been applied to the production site on the demo site. This is important so that demonstrations and content generated from the demonstration site reflect the way the district’s production site will work. 

Edsby software upgrades: The sandbox site will be upgraded with pre-release versions of Edsby software as these releases become available. Interested board staff will receive emails each time a software upgrade is done that will describe the contents of the upgrade. This will provide the district with a window of time (usually a couple of weeks) in which the new software can be tested out prior to it going into production. 

Additional Considerations

The Edsby Demo sites and Edsby Sandbox sites are intended to be available 24x7x365. However they are not considered mission critical systems from an availability or business continuity perspective. Some limitations to keep in mind include:

• The demo and sandbox sites may run on lower performance environments and lower availability environments than our production software. No SLAs are provided for the demo and sandbox systems.
• Standard maintenance activities such as software upgrades may occur during business hours (unlike the production system). This may impact demo or sandbox availability from time to time for brief periods.
• Backups of demo and sandbox system data will not be done as frequently as the production system. User generated content on these systems will not be treated as “mission critical” data since it does not contain any “real data” of any value that only exists in the demo or sandbox environment. 

Summary

The following diagram depicts the high level configuration for the three different Edsby systems:

The following table summarizes the differences between the three different Edsby systems that will be set up for each school district using Edsby.