I was excited to start a new chapter in my career by joining Commit in late January. Part of the onboarding process as a Software Engineer is to set up your computer for development work, which can take anywhere from minutes to days. Coincidentally, as my first day at Commit was wrapping up, an interesting message appeared on a Slack Commit community channel. It mentioned that developers were experiencing some friction with the setup process, which required “high onboarding/setup time” to start working on Commit internal projects. It couldn’t be that challenging, could it?
I was eager to find out. On my second day, I started to read over the project documents for Commit’s internal platform. I began to realize what the frustration was. There were multiple setup documents, one of them was long and had branching paths, and in some cases it was out of date. A light bulb went off and I immediately knew what I would do for my Commit Hackathon Onboarding Project (CHOP): improve the developer experience when getting set up on Commit’s platform.
Planning my approach
The platform has several components: a back-end service, a database, and a user interface. For my CHOP, I would streamline running these components and connecting them. There was already a Docker file to build an image of the back-end service and a Docker Compose file that only spun up a database. I knew I could use Docker Compose to orchestrate:
- Building Docker images
- Spinning up Docker containers
- Connecting the Docker containers
However, I had never done this before. I also had not worked intimately with Docker files. It was a perfect opportunity to gain more exposure to these toolings.
Prepping the back end
The back-end service Docker file only had instructions to create a production image; I needed to create a development one. I experimented with several options:
- Adding branching conditions to create a development or production image, given a flag
- Creating a separate development Docker file
- Leveraging multi-stage Docker file builds
I eventually settled on using multi-stage builds. This allowed me to better optimize for readability and maintainability. First, I added instructions to build a base image that was common to both the development and production image. Next, I drafted instructions to create a development image by leveraging the base image and layering additional instructions. Lastly, I repeated this process for the production image with slightly varied instructions.
Screenshot of the code
I then updated the Docker Compose file to spin up the back-end service and connect it with the database.
Pinging the database
Running the command docker-compose up, both the back-end service and database seemed to have spun up. Upon closer inspection, I noticed that the back-end service, at the start, was failing to perform a database operation. Despite configuring the Docker Compose file to have the back-end service depend on the database, the back-end service didn’t wait until the database was ready before making a request. With version 3 of Docker Compose, I couldn’t add an extra condition to wait for the database to be operational. I ended up adding a snippet of code that ran when the back-end service started. This snippet of code pings the database every second until it responds.
Prepping the user interface
For the user interface, I created a new Docker file and configured it within the Docker Compose file.
The next problem I encountered was that the user interface wasn’t accessible in the browser. It was running inside a Docker container; this meant that the local loopback address that it was using was not the same as my host machine. Changing the bind address from 127.0.0.1 to 0.0.0.0, I could access the user interface in the browser.
Making it happen
After installing Docker and Docker Compose, a developer wanting to work on the Commit platform can run just a single command: docker-compose up. Within minutes, all the components are running, encapsulated so they don’t affect the host machine, and connected. The setup is now concise, quicker and less confusing.
Future features
One area for potential future exploration is better mirroring of the production environment. The production version of the Commit platform runs in Kubernetes. There are several options to run a local Kubernetes cluster, such as Kind or K3s.
Simplifying the setup process for the internal platform allows Commit developers to get started right away. That’s no small issue. Customer experience and user experience typically get top billing when it comes to software development, but developer experience is equally important. Without it, the other two don’t come easy.
For over a decade, Thomas Choo has been a Software Engineer focused on re-architecting and migrating large backend systems across a number of industry verticals, from telco to social media platforms.When he isn’t at a computer, he is exploring breathtaking hikes.
Interested in becoming an Engineering Partner at Commit? We offer professional development, peer-to-peer support and access to exciting startups.
###