====== Change Management ====== [[PageOutline|]] There are two methods of change management implemented for Hal * Gitea * Docker Registry ===== Gitea ===== Gitea is a packaged frontend service for git repositories (similar to github). We have deployed a restricted [[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:revisioncontrol|self hosted instance]] Use **ssh **for repository work, not the **https **option. [[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:revisioncontrol#a1.NewRepo|See the URL examples here]], showing the [[https://trac.x0blr.com/#data-tracwysiwyg-link=ssh://|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.// ==== One-time setup to create new repositories. ==== - Login to the Gitea instance - [[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:revisioncontrol#a1.NewRepo|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) - 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...// ===== Locally ===== - Create or clone the repository locally - Use git branchto check the available branches in the closed repository - Use git -b to create a branch to work in. Give the name something representative of the work - Switch to this new branch with git checkout - Work in this tree (e.g. Add a README.md file) as normal. - [[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:testing-changes|Test the work]]. Once confident things work fine, you are now ready to check the work back in. - Check the current status of that tree with git status - Commit changes into your local tree git commit -m "" * If you have //added// new files from within your repository, run git add 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) - Push those changes back to the new branch with git push([[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:revisioncontrol#a2.Collaboratingwithanexistingrepo|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 ===== Submitting work for review ===== 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: - In gitea, browse to the repository with your change (note: - In the **pull requests** tab on that repository, select 'New Pull Request' - Merge into: :master ... pull from: : - Click new pull request and provide any relevant information about the change for the reviewer ===== Reviewing a pull request ===== - Log into gitea - Go to the appropriate repo - Go to the pull requests tab on the repository - Review the work and test locally if the changes aren't immediately clear (see [[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:testing-changes|Testing Changes]]) - If appropriate select to merge the code * Once the code is merged, delete the branch - If deemed not appropriate, reject the change and close the pull request ===== Master Branch - autoupdates to the servers ===== Changes made in the **master **branch will automatically be deployed out to nodes (servers), using the following process: - 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 - 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. ===== Redeployment of servers ===== Manually cloning a new repository to /var/lib/puppet/manifestwill not survive a host deployment. To make this repository persistent, update the appropriate kickstarts//post.cfgfiles (in the [[https://trac.x0blr.com/#data-tracwysiwyg-link=https://config.tombstones.org.uk:23000/tombstones/kickstarts/src/branch/master|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: - Log into gitea and create the repository - 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 - Push the local working tree to the remote gitea tree - Log into the server and clone the new repository to the appropriate directory - Let puppet and docker handle the rest. [[Image(create-a-new-git-repository.png)|]] ===== Docker Registry ===== 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 [[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:quark-migration|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 ==== Locally ==== - Scope, Build and Test the image locally create a Dockerfile then docker build - Tag the image docker image tag : : - Push the Image docker push : ==== Server ==== //NB: eventually this will be automated using watchtower in our images where possible// - For a new service clone the appropriate puppet manifest - For an existing service restart the service (most of our systemd files for docker have an [[https://trac.x0blr.com/#data-tracwysiwyg-link=wiki:ExecPre|ExecPre]] docker pull action and we a lazy and just target :latest) [[Image(docker-registry_v01.png)|]]