The thalia working environment is split into three parts: development, testing, and production.
Development: thalia-dev.mit.edu
The development server is used by developers to deploy and test new code before
Our CI system will build the code from SCM every night and deploy the binary the devlopment server if the build and smoke test are successful.
Test: thalia-test.mit.edu
thalia2, thalia11 host the ime
thalia3, thalia12 host alfresco (currently only thalia3 is in use)
thalia4, thalia13 host the mysql db
The test server is used by QA testers and CAT users. The code on the test server is more stable than that on the development server. During the two week QA process, we will release a new build to QA every three days or whenever important bug(s) are fixed. A release note will be sent to QA along with the new release containing a list of issues resolved in this release.
We will give our final release candidate to QA three business days before the actual release date. Currently, we are releaing on Monday night every 4 weeks.
Production: thalia.mit.edu
thalia5, thalia8 host the ime
thalia6, thalia9 host alfresco (currently only thalia6 is in use)
thalia7, talia10 host the mysql db (currently only thalia7 is in use)
The production servers have their own sets of passwords to protect the production environment :the tomcat manager password on thalia5 and 8, the alfresco admin users' password and regular user's password. Only root instances are allowed in .k5login files.
Sprints and Release Process
Thalia uses 4-week release cycles, called sprints. There is a sprint planning meeting a couple of weeks before the start of each sprint. In that meeting, the bug list and new feature requests are reviewed, and we decide which tasks we will include in that sprint.
The first 2 weeks of a sprint are the development cycle. At the end of this cycle, there is a developer code freeze. This means that after this point, only fixes to bugs related to the development work in this sprint can be addressed.
At this point, the code should be branched, tagged, and released to QA for testing (see SVN Guide for details). A release note should be sent to QA with details of what is included in the new release candidate.
The next 2 weeks are the QA cycle. QA will be testing, and will enter bugs into JIRA. There will be one developer available in the thalia-qa chat room each day, so that QA can review any issues, and confirm they are indeed bugs before entering into JIRA. QA will group questions as much as possible, to minimize the disruptions.
Developers will be fixing bugs as they come in, and when there are several bug fixes ready, or even one significant one, a new release candidate will be put on the test server, after tagging it in SVN. Release notes will accompany any release to QA. The goal is to have an updated release candidate approximately every 3 days. The final release candidate should be stable by the wednesday before the release to production.
A new release will be deployed on thalia.mit.edu on Monday night at the end of each Sprint.