Change Management

PageOutline

There are two methods of change management implemented for Hal

• Gitea
• Docker Registry

Gitea is a packaged frontend service for git repositories (similar to github). We have deployed a restricted self hosted instance

Use ssh for repository work, not the https option. See the URL examples here, showing the ssh:// protocol in use.

DO NOT work in the master branch - changes performed here will be auto-deployed to production once changes are pushed back to the repo. Instead, branch then work within that branch.

1. Login to the Gitea instance
2. Create a new repository (with an appropriate name) under the tombstones organization (choose to initialize the repository if new and there isn't a pre-existing local git repo)
3. Under Settings, add the servers & server admins team to the repository (which provides permissions to securely clone the repository) ←- can't see how this is done…

1. Create or clone the repository locally
2. Use git branchto check the available branches in the closed repository
3. Use git -b <branch name>to create a branch to work in. Give the name something representative of the work
4. Switch to this new branch with git checkout <branch name>
5. Work in this tree (e.g. Add a README.md file) as normal.
6. Test the work. Once confident things work fine, you are now ready to check the work back in.
7. Check the current status of that tree with git status
8. Commit changes into your local tree git commit -m "<reason for change>" * If you have added new files from within your repository, run git add <filename> or git add * to add everything.
   • If you have modified an existing file(s), add the -a flag to your commit (or use the git add commands as mentioned above)
9. Push those changes back to the new branch with git push(see also here, or follow the instructions on the gitea repository page).

The branch will now be available for review in the application repository on gitea

We take a "peer review and approval" approach, i.e. someone else will review your work and merge it back to the master branch, as the master branch is regularly deployed to production. Hence when changes in your branch are complete, a pull request is required for branched code to be reviewed (then merged) into the master branch. The steps are:

1. In gitea, browse to the repository with your change (note:
2. In the pull requests tab on that repository, select 'New Pull Request'
3. Merge into: <repo>:master … pull from: <repo>:<your branch>
4. Click new pull request and provide any relevant information about the change for the reviewer

1. Log into gitea
2. Go to the appropriate repo
3. Go to the pull requests tab on the repository
4. Review the work and test locally if the changes aren't immediately clear (see Testing Changes)
5. If appropriate select to merge the code
   • Once the code is merged, delete the branch
6. If deemed not appropriate, reject the change and close the pull request

Changes made in the master branch will automatically be deployed out to nodes (servers), using the following process:

1. Servers pull down changes from existing repositories using the /usr/local/bin/repofixscript, which runs every 5 minutes (root's crontab). Changes made in the master branch will appear on the VMs in /var/lib/puppet/manifests
2. Entries in /var/lib/puppet/manifestsare then applied using puppet apply /var/lib/puppet/manifestswhich runs every 15 minutes (root's crontab). The results appear in /tmp/puppet-apply, so check this file for history of the last run (is truncated per run).

If a new repository created in gitea is to be added to puppet's automated rollout, clone that new repository first to /var/lib/puppet/manifeston the server. Note that the clone will only be temporary until another server redeploy, so consider if that repository should be persistent or not.

Manually cloning a new repository to /var/lib/puppet/manifestwill not survive a host deployment.

To make this repository persistent, update the appropriate kickstarts/<hostname>/post.cfgfiles (in the kickstarts repository) - what are preseed files?) which will then include this repository when the host is next deployed. Without this, new repositories will need to be manually recloned (using the methods mentioned above)

For example, to deploy a new image on the docker infrastructure using puppet to auto-install all configs correctly for each deployment, the following is required:

1. Log into gitea and create the repository
2. Create a local copy of the repository and create a puppet manifest (see the existing manifests for an example)

1, Test and commit your changes locally

1. Push the local working tree to the remote gitea tree
2. Log into the server and clone the new repository to the appropriate directory
3. Let puppet and docker handle the rest.

Image(create-a-new-git-repository.png)

A Docker Registry allows us to privately host pre-built custom docker images for deployment on our server.

Docker provides its own self-hosted docker registry which we use to store our pre-built images (e.g. gaming@Tombstones) for deployment on the Respective Hosts. To make it easier for everyone we also host a web frontend for the official Docker Registry to browse images etc.

The use of the Docker Registry is the same as the git repositories: work on a local copy then push to production

1. Scope, Build and Test the image locally create a Dockerfile then docker build
2. Tag the image docker image tag <local image>:<tag> <remote image>:<tag>
3. Push the Image docker push <remote image>:<tag>

NB: eventually this will be automated using watchtower in our images where possible

1. For a new service clone the appropriate puppet manifest
2. For an existing service restart the service (most of our systemd files for docker have an ExecPre docker pull action and we a lazy and just target :latest)

Image(docker-registry_v01.png)