How to sunset a project¶
When a project has finished, and any relevant assets have been sent back to the client, the technical infrastructure for the project needs to be dismantled. As a general rule, we prefer to leave the the infrastructure set up in such a way that it can be re-activated if the client comes back to us.
Disable the Apache configurations for the site by running
Move the relevant Apache configuration to
/etc/apache2/sites-available/mysite.conf-disabled, then reload Apache:
sudo service apache2 reload
Remember to do this for production, staging and any other relevant deployments. Remove any public deployments from the company account on uptimerobot. Remove any webhooks from our Slack app. Revoke any SSL certificates that are associated with the project, and remove scripts for the automatic renewal of SSL certificates. You should also raise an issue and an MR to remove the site from our SSL validation script in the cron repository.
Stop GitLab runners¶
Remove the runners from GitLab, by going to Settings -> CI/CD -> Runners and clicking on the Remove runner button for each one.
Move the gitlab runner config on the server from
In some older servers the configuration might be in
Remove SSL certificates¶
Remove the SSL certificates obtained for the site(s) by running:
and selecting the relevant domains.
In some older servers the
certbot script might be found in
Update the SSL validator¶
Our SSL validator runs as a nightly GitLab pipeline to check that every SSL certificate that we own is still valid. Raise a merge request to update the SSL validator to remove the relevant sites from the script.
Remove DNS entries¶
Log into our account on 123-reg (ask the CTO if you need the password). Go to the Control Panel -> Choose Domain and toggle the Auto renew button off.
Next, go to Manage DNS -> Advanced DNS settings and remove any DNS records that point to Beautiful Canoe servers.
Go back to Manage Domain and click on the Web forwarding link, and remove any entries for the relevant domain.
That will be all that is necessary for most projects, but before you leave 123-reg have a look around for any other relevant settings.
Backup production and staging databases and sites¶
cron scripts on the server should back up both the database and website for any live deployments.
These backups should be in
scp to transfer the latest back ups to your local machine, and put them in the
backups folder on Dropbox.
Make sure that you check the file sizes of the backups you take, and check that they can be uncompressed.
Update the server map¶
Make sure that the relevant hostnames and other entries are updated on our server map.
Removing the server¶
In general, we prefer not to delete servers, just in case we need a spare server to run occasional jobs, or to help bootstrap a new project. However, if a server has reached its end of life, back it up and raise an ITS helpdesk call to remove it.
Archive the Slack channels¶
Every project should have a project-project and project-gitlab channel on Slack, for discussion and GitLab notifications. Once a project has ended, both channels need to be archived.
To archive a channel, go to Settings cog -> Additional options -> Archive this channel on the channel page.
Archive GitLab repo¶
GitLab repositories can be live, or archived. Archived projects are read-only and do not appear on the list of projects that the group owns. You will want to do this last, since some of the information on the project (such as CI/CD settings) will not be visible once the project has been archived.
Before you archive a repository, go through any open issues and merge requests, and:
- Remove any assignees
- Remove milestones
- Remove ~Doing, ~"To Do" and ~"Under Review" labels
and perform any basic triage operations that you think are necessary. This will prevent the Triage Bot trying to perform automated triage tasks on the project, after it is archived.
Next, go to Settings -> General -> Advanced -> Archive project and click the Archive project button.