February 2023
A recent project that I got excessively excited about was a task to set up a deployment of Epic Games' Robomerge tool suitable for use in a Production environment.
Robomerge is an internal tool developed and used by Epic Games, released along with the source code for Unreal Engine licensed for external developers. It monitors Streams in Perforce Helix Core and, depending on configuration, attempts to automatically perform merges between them when commits are made. This is incredibly useful in game development where the presence of large binary files causes problems for most classic code branching strategies.
Before my involvement, Team17 had only used it in a very limited capacity on a single game project. Documentation was limited, the application wasn't kept up to date with new updates, and it was running insecurely and without any authentication.
On the plus side, it had been deployed with most of a CI/CD pipeline - code in Perforce, Docker image compiled by TeamCity, container deployed to the host server using Ansible. Neither the build nor the deployment had been allowed the time and attention they needed, so there was a lot of room for improvement. Thankfully it had been set up with dedicated test and live images and servers, which made it very easy to start tinkering without disrupting anything in use.
So, my roadmap looked something like this:
- Review existing setup
- Download latest Robomerge code
- Test with the existing pipeline
- Beg @RegnerBA for advice
- Move environment variables from build to deployment to increase flexibility and rapid testing
- Configure Docker with permanent data and secrets vault directories
- Get it running on HTTPS with our trusted SSL certs
- Configure and test LDAP authentication
- Set up Streams in Perforce for the Robomerge code to facilitate contributions from developers
- Set up a Swarm project so that I have oversight of said contributions
- Rewrite the Ansible deployment into our more mature Puppet environment
- Start testing tool usage and configuration
- Write documentation on all the above that can be easily found and parsed
- Get feedback from service users/owners
- Set up long term plans for use and development
By the time I set up the Swarm project, I was going "...hang on, I'm actually doing a full DevOps pipeline for the first time". Before this project, I'd worked on source, build, and deployment, but never more than two bits at once. Now I was starting with application source, and setting up a fully automated and collaborative pipeline to allow changes to be safely tested and deployed.