miBUG 2017 - Blackboard Testing and Development in a Multi-Tier Environment

Central Michigan University maintains a multi-tiered environment for Blackboard that allows us to provide better end-user support and to test various updates to the Blackboard system, including releases, CUs, and integrations (e.g. B2s, LTI, etc.). CMU Application Administrators will detail the configuration and maintenance of these environments and the testing process used to prepare for major changes to the Blackboard system.

Transcript

1. Blackboard Testing and Development in a Multi-Tier Environment
2. Kenny Barnt Marcus Jackson Application Administrators Office of Information Technology Central Michigan University
3. Obligatory Environment Description
4. Learn at CMU • Self-Hosted on Windows • 2016 Q2 Release (CU4 currently in testing) • For Fall 2016-Spring 2017 – 10,500 Courses – 26,500 Students – 2,000 Instructors
5. Three Tiers
6. Production • Infrastructure – Fault Tolerance – High Availability – Load Balancing – Disaster Recovery • Usage – It’s production…
7. Staging • Infrastructure – As close to Production as reasonably possible • Usage – Day-to-day troubleshooting – Change testing – Late Stage Development
8. Test • Infrastructure – Very simple, not necessarily at all like Production • Usage – Tech Previews – New Releases – Development
9. Maintenance Keeping the lights on
10. Production • All configuration changes must be approved. – Ticket to track work – Vetted in staging – Approved by manager (CRB if impact is high) • Maintenance Windows – Changes only allowed during Windows – Made during least impactful time.
11. Production Freeze Windows 1. Beginning of fall semester: Thursday of prep week through Tuesday of the first week of classes 2. End of fall semester: Monday through Thursday of exam week 3. Beginning of spring semester: First two days of classes 4. End of spring semester: Monday through Thursday of exam week
12. Staging • Enables testing of upgrades (CU’s, B2’s, etc.) • Periodic refresh from production – Based on Bb documentation – Documentation Repository • Step-by-step on refresh • B2’s custom configurations • Lessons learned from past iterations
13. Refreshing Staging • Gather B2 Settings • Refresh content share – 2,898,247 files – 1.5TB – ~ 4hours • Refresh SQL (from production backup) • Copy application folder from production • Make staging specific changes • PushConfig • Update B2 configurations
14. Test • Updated ad hoc • Never gets bulk data from production
15. Change Testing & Development
16. Basic Testing • Low-Risk changes • First Pass for higher-risk changes • Does the change do what it’s supposed to do? • Does the change break anything obvious/likely?
17. Testing Matrix • Common functionality used by students and instructors • Historically problem- or regression-prone functionality • eLearning Support maintained
18. Release/CU Installation Rehearsal • Refresh & Update • Basic Testing and Testing Matrix • Refresh & Rehearse at least 2x • Load testing
19. Annual Readiness Testing • Stress Testing • Multiple Applications Simultaneously • Fail-overs • Production
20. “Learning Opportunities” • SQL SA Accounts • Authentication • Safe Assign • Content Share
21. Questions? Test Matrix Available at: http://bit.ly/cmumatrix