...
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.