This document covers the Makeability Lab website's production infrastructure, deployment pipeline, and server administration.
- Deployment Guide
The Makeability Lab website runs on two UW CSE servers:
| Server | URL | Purpose |
|---|---|---|
| Test | https://makeabilitylab-test.cs.washington.edu | Staging environment for testing changes |
| Production | https://makeabilitylab.cs.washington.edu | Live public-facing website |
Each server has its own:
- PostgreSQL database
- File storage backend
- Log files
Important: Content added to the test server does not affect production, and vice versa. They are completely independent environments.
Deployments are automated via GitHub webhooks:
graph LR
A[Push to<br/>master] --> B(Webhook fires)
B --> C[makeabilitylab-test<br/>auto-deploys]
D[Push a tag<br/>e.g. 2.1.0] --> E(Webhook fires)
E --> F[makeabilitylab<br/>production]
Any push to master automatically deploys to the test server:
git push origin masterProduction deployments require a version tag:
git tag 2.1.0
git push --tagsCheck the build log to confirm deployment succeeded:
- Test: https://makeabilitylab-test.cs.washington.edu/logs/buildlog.txt
- Production: https://makeabilitylab.cs.washington.edu/logs/buildlog.txt
We use Semantic Versioning for production releases.
| Change Type | Version Component | Example |
|---|---|---|
| First release | Start at 1.0.0 | 1.0.0 |
| Bug fixes, minor patches | Increment PATCH (third digit) | 1.0.0 → 1.0.1 |
| New features (backward compatible) | Increment MINOR (second digit) | 1.0.1 → 1.1.0 |
| Breaking changes | Increment MAJOR (first digit) | 1.1.0 → 2.0.0 |
View current and past versions on the Releases page.
-
Ensure all changes are merged to
masterand tested on the test server -
Determine the appropriate version number based on the changes
-
Create and push the tag:
git tag 2.1.0 git push --tags
-
Verify deployment via the production build log
The production server was configured by UW CSE's IT team (Jason Howe).
Django reads database credentials and secret keys from config.ini. This file:
- Is not stored in Git (for security)
- Is mounted as a Docker volume on the production server
- Contains PostgreSQL connection strings and Django secret keys
Production-specific settings are configured in settings.py using values from config.ini. Local development uses different defaults specified in docker-compose-local-dev.yml.
Logs are available via SSH or the web:
| Log | Description |
|---|---|
debug.log |
Django application logs |
buildlog.txt |
Deployment build output |
httpd-access.log |
HTTP request logs |
httpd-error.log |
HTTP error logs |
- Test: https://makeabilitylab-test.cs.washington.edu/logs/
- Production: https://makeabilitylab.cs.washington.edu/logs/
-
SSH into the server:
ssh recycle.cs.washington.edu
-
Navigate to the log directory:
# Test server cd /cse/web/research/makelab/www-test # Production server cd /cse/web/research/makelab/www
-
View recent log entries:
# Last 100 lines tail -n 100 debug.log # Save to file tail -n 100 debug.log > last100lines.log # Follow log in real-time tail -f debug.log
If you have Windows directory mapping configured, logs are accessible at:
O:\cse\web\research\makelab\www # Production
O:\cse\web\research\makelab\www-test # Test
Files uploaded via the Django admin (publications, talks, images, etc.) are stored in the /media folder:
| Server | Path |
|---|---|
| Test | /cse/web/research/makelab/www-test/media |
| Production | /cse/web/research/makelab/www/media |
To browse uploaded files:
ssh recycle.cs.washington.edu
cd /cse/web/research/makelab/www/media # or www-test for test server
ls -laThe production PostgreSQL database runs on grabthar.cs.washington.edu.
Note: Direct database access is rarely needed. In the uncommon case you need to query PostgreSQL directly, you must connect through
recycle.cs.washington.edu:
ssh recycle.cs.washington.edu
# Then connect to PostgreSQL from thereFor routine data management, use the Django admin interface instead.