1. In the beginning, there was Jeff and there was Gary.
2. Jeff created VMs, installed OSes onto them, placed them in subnets, and configured firewall rules for them. Jeff provisioned and Jeff secured (and Jeff really liked Ubuntu).
3. Gary SSHed to these VMs, used `sudo apt` to install software, used `git` to clone and pull repos, used `clojure` to build and run SIG software, and ran long-running servers within `screen` or under `nohup`. Gary wrote software (version controlled) and config files (not version controlled).
4. Then more programmers appeared. Gary showed them how he managed VMs, and they largely followed his lead (though RJ really liked `make` and later decided that `bb` was even more fun for running build tasks). The team was small and agile.
5. Even though the team was small still, everyone didn't always know everything about how every application was developed and deployed. Gary decided to create a place to write that information down, and so Dev-Docs was born. This came to be the primary location to find information about VM configurations, service deployments, config files, and secrets for each SIG project.
6. One day, Jeff rebooted some VMs, and our services didn't restart. Chaos ensued. The `screen` command was ousted in a coup and replaced by `systemd`, which promised to always restart our services as long as we "enabled" them.
7. And lo! Even more programmers appeared. Better coordination became necessary and so Jeff created a `sig-app` account on all of our VMs. Everyone SSHed to these VMs, used `sudo su - sig-app` to become the `sig-app` user, and continued managing the servers as before.
8. One day, RJ introduced Jenkins to the team, which offered a means of scripting up our deployment steps in jobs per project rather than needing to perform them manually. Some programmers were enthused. Others ignored Jenkins and continued with their manual deployments.
9. Occasionally, a project moved its infrastructure to AWS or GCP, but most SIG applications continued to be developed and hosted on SIG VMs created and secured by the mighty Jeff.
10. Eventually, Jeff met Dominick, whom he promptly knighted as his first lieutenant, and the two came to share responsibility for the vast catalogs of SIG-hosted infrastructure.
11. As the team grew, the developers clustered in small product teams, each of which established their own policies around their preferred development tools and whether they would use automated or manual deployments.
12. In 2023, Gary proposed the adoption of reproducible development and deployment environments. As with Jenkins, some developers were enthused, and others continued working as before. Gary hosted a recurring developers' meeting in the spring and summer of 2024 to discuss various approaches to achieving reproducible environments and moving towards adopting an infrastructure as code approach on our projects. He presented on various ways to achieve these goals using Guix and heard from some other developers (predominantly George) about their experiences solving similar problems with Docker. Some teams began to use a bit of Guix. Some began to use a bit of Docker. Some teams continued as before without either new technology.
13. In 2025, the Pyrecast team decided to migrate to GCP in order to better support a commercial version of their app. Jeff and Dominick decided to provision and manage the new GCP infrastructure using Terraform while the Pyrecast developer team leveraged the UberJAR-building capabilities of Clojure and Triangulum to wrap up (almost) all of their dependencies in a single application file per repository. Gary then helped them to wrap their UberJAR building code in a containerized environment using Guix, and finally they created Jenkins jobs to build these UberJARs in Guix containers and deploy them along with their config files to the Terraform-provisioned VMs.
14. In 2025, The Planscape team also decided to migrate from AWS to GCP, and it would appear that they are also leveraging Terraform to deploy their needed GCP infrastructure. While I know that George has also created Jenkins jobs to perform their deployments, I'm not sure whether they are using Docker or any other container technology in their builds or deployed runtime environments. I hope to learn more about this as their migration progresses.
15. Hopefully as our team develops more experience with each of these tools in our development and production environments, we may be able to finally incorporate more reproducible environments and infrastructure as code approaches in all of our SIG software applications. In order to facilitate this transition, I would encourage those folks who are developing this experience to take the time to document it and share it with our larger team, whether in Lightning Talks or just in small skillsharing groups. This is how we all grow together.
And now that you know the (abridged) history of how we got here, you can all contribute to making our future even better. Happy hacking, everyone!