Thalia environments and workflow
The thalia working environment is split into three four parts: development, testing, and production.
- Development
...
- - a shared ennvironment for developers to deploy and test new code
...
- . Our CI system will build the code from SCM every night and deploy the binary the
...
- development server if the build and smoke test are successful.
...
- Testing - 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
...
- releasing on Monday night every 4 weeks.
- Production
...
- - live service. 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
...
- user's password and regular user's password. Only root instances are allowed in .k5login files
...
- .
We don't have a staging environment at this time. Staging is a stable release containing test data for other services to test against.
Nightly builds and smoke tests run on isda-build1.mit.edu .
We may put files on isda-build1.mit.edu/~isdasnap for AMIT to deploy during release.
| Development | Testing | Production |
|---|---|---|---|
hostname | thalia-dev.mit.edu | thalia-test.mit.edu | thalia.mit.edu |
IME (back end) and help files | cms-dev-th1.mit.edu | isda-thalia2, isda-thalia11 | isda-thalia5, isda-thalia8 |
Alfresco | cms-dev-th2.mit.edu | isda-thalia9 | isda-thalia6 |
MySQL | cms-dev-th3.mit.edu | isda-thalia13 (thaliaunicode) | isda-thalia7 |
value for repository.location in | |||
|
|
|
|
|
|
|
|
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.
...