Summary
The ScheduleDB project consists of a set of micro-services that allow a user with administrator credentials to login and maintain the database collections of Teams, Users, Venues and Meeting Schedules. The user facing services include:
- frontend : a User Interface for login and data management.
- website: a micro-service implementation of the current tssg.tech website. Includes a schedule page that automatically updates with the next three General Meeting schedules.
History
For the last few years that tssg.tech has had a page to list the upcoming schedules: a developer, like Joel Sharasheff, had to make code changes every week to keep the page updated.
The ScheduleDB project was born out of a need to create a process whereby any authorized user could make the schedule, venues, teams and user changes into a database once. The website (tssg.tech) would then update the schedule page automatically every week.
TSSG Management Responsibilities
Before these implemented services can be deployed to replace the tssg.tech production website, the Web Team is requesting that all TSSG Management stakeholders test the frontend and website services. Management will then update the TSSG Management Input table below for a Go or No-Go vote to Production along with Constructive Feedback.
Management will also need to decide who will update the General Meeting Schedules within the services.
Access
Access to the development instance of the FrontEnd Service is available by navigating your browser to the development endpoints:
- Administrative FrontEnd - https://frontend.sdb.technologynursery.org
- Try out adding users, teams, venues, and meeting schedules.
- Proposed Website - https://website.sdb.technologynursery.org
- Click on the schedule icon to get the next three scheduled weeks from the database.
Login credentials for the administrator "admin" will be provided to the tssg-management group in an email.
Once you have logged in as admin, please create an administrative user for yourself to do the testing. Log out as admin and then login as your newly created user.
TSSG Management Input
Please update this table with your Vote and/or Feedback.
Manager | Team | Vote
| Comments / Constructive Feedback |
---|---|---|---|
TSSG | Go | Found the functionality adequate for the current tasks required. Future:
| |
Mark Pralat | Mobile Group | Go | It worked as expected. I created the mobile group, added meetings etc. Some areas need some refinement:
|
Ray Bloom | QA Study Group | Go | Good work by all involved; sufficiently implemented and functional to release and start using.
|
Web Team | Go | WebTeam approval is a given, our Jira is full of details
| |
DevOps Team | Go |
| |
Norm Heckman Alan Rawsthorne | Data Analytics Team | Go | Approval by Alan on behalf of Norm, but any feedback we have from any Data team members came from discussions in Data Science group, see below |
Data Science Learning Team | Go | Scheduledb Feedback
| |
Lora Bates | TSSG |
Conclusion
When all of TSSG management has approved these services for production, the following steps will be done:
- We will follow the guidelines for code review as specified in Requesting a merge to scheduledb of your code contributions.
- The scheduledb branch will be merged into the master branch. The master branch contains the state of the current tssg.tech web site.
- The database will be compared to the data on the current site and updated to match
- We should split up the List All pages and each Web Team member update his/her collection data vs the True Data
Afterward, do the same for the static pages in the new Site folder.Jim Turner (or when it is done) Let client make modifications to either the database (through the FrontEnd) or raise tickets for the Web Team to change the Site content as necessary.Final step: see to it somehow that this (newest) data is in the (initializing) db saved in the Git repository.Not needed because the db is persistent. Just change the data through the FrontEnd UI.
- Ralph A. Navarro Jr. Upgrade a13 storage from 128G to 512G
- A Jenkins project will deploy the master branch to a staging (i.e. QA) endpoints.
- decide the names of the services' subdomain endpoints
- Website
https://tssg.tech → a13 - Backend
https://backend.tssg.tech → a13 - Admin (FrontEnd)
https://admin.tssg.tech → a13
- Website
- Ralph A. Navarro Jr. configure Nginx to reverse-proxy them to the underlying services
- Paul Scheidemantel Enable scheduledb.env working in private branch taken from master branch
to configure either dev or prod endpoints by passing an environment variable (deployEnv) option (default=dev) to scheduledb.env. - Paul Scheidemantel Create a prod.install for deploying scheduledb to prod.
- Ralph A. Navarro Jr. configure Jenkins
- Ralph A. Navarro Jr. execute the deploy
- decide the names of the services' subdomain endpoints
- Automated and manual tests will be run against the
stagingproduction area. This will verify that the merge has happened successfully before moving to the next step in the pipeline. Corrections will be made if needed until the staging area quality can be assured.- create "smoke" tests to verify service inter-connectivity
- enhance code coverage for all UX features
- Another Jenkins project will deploy the master branch to the production endpoints. We will be
- Automated and manual tests will be run against the production endpoints. This will verify the quality of the production endpoints. Corrections will be made if needed until the production area quality can be assured.
- Once in production, create a backup script to backup the database data periodically (either cron job or manually).