Workflows

Contents

• Git workflows
• Updating code on the production server
• Resolving an internal server error
• Running South migrations
• Creating South migrations

Git workflows

See the page on Git Workflows.

Updating code on the production server

Requirements before proceeding:

• You will need a user account on your production server.
• You may need to use sudo to have permission to run certain commands. For example, if apachectl start yields a "permission denied" error, then sudo apachectl start might work. To use sudo, you have to be added as a sudoer on the server.
  • Using sudo on git commands, however, is generally a bad idea. See the below requirements to set up Git permissions with your production server username.
• To use Git on the production server, you must have a Git credential helper or SSH key set up on the production server. See GitHub's guide for more info (make sure to select the server's operating system at the top of the page).
• You will need write permission for the directories in the Git repository. To ensure that all project collaborators can write to the directories, you should make sure all of these directories have g+w (group write) permission and are under a group which all project collaborators are part of. Suppose your group is called admin, and your project root directory is CoralNet. Then you would run sudo chgrp -R admin CoralNet and sudo chmod -R g+w CoralNet.

Now, whenever you need to update code on the production server, you'd do the following:

1. SSH into the production server machine, and locate the directory with the project code.
2. Put up the maintenance message. Set the maintenance time to be at least several minutes after the current time. That way, users have some advance warning before you actually start messing with the site. More info on the maintenance message: here
3. Wait until your specified maintenance time begins.
4. Stop the server with apachectl stop. This is done because updating code while the server is running can temporarily leave the server code in an inconsistent state, which can lead to some very weird internal server errors. (Note that this is only the case when settings.DEBUG = False, which it should be for production servers.)
5. Follow the Updating procedure on the Git workflows page. This'll be simple because you almost never develop code on the production server; you just update it. In particular, git fetch origin, git checkout -- <path to file>, and git rebase origin/master are probably all you will need.
6. If there are any new Python packages or other packages to install, then install them.
7. If there are any new settings to specify in settings_2.py, or new task helper functions to create in images/task_helpers.py, then do that.
8. If any static files (CSS, Javascript, etc.) were added or changed, run python manage.py collectstatic to serve those new static files.
9. If there are any new South migrations to run, then run those.
10. Start the server again with apachectl start.
11. If possible, quickly test the new functionality to check that's it's working.
12. Take down the maintenance message.

Resolving an internal server error

Almost always, when you need to resolve an internal server error, you'll need to know the error traceback.

• Sentry logs errors and their tracebacks, so if an error occurred, check the Sentry client, which is at /sentry . Log in as a site admin, using the same username and password as an admin account on the website.
• Occasionally, there will be an error that Sentry cannot log, or an error that prevents the Sentry client from being reachable. In that case, you'll need to check the Apache error log. The Apache error log location is configured with the ErrorLog directive, and this directive's value should be in one of the Apache configuration files (ending in .conf).

Special cases:

• If an internal server error is only occurring on the production server (not on any development machines), and/or intermittently occurring, then it's possible that someone forgot to do step 3 in "Updating code on the production server". Try restarting Apache (apachectl restart) and see if that stops the error from happening again.

Running South migrations

TODO

Creating South migrations

TODO