In the Developer Interview series we talk to engineers who use Semaphore and pick their brains about how they work, what wisdom they would like to pass on, and the most challenging problems they’ve faced during developing.
This time, we spoke to Emile Vauge, the creator of an open source project, Traefik.
1. For a start, tell us something about Traefik.
Traefik is a reverse-proxy written in Go. What makes it interesting is that it has been designed to integrate in modern software infrastructures. Usually deployed in a container based/microsrevices platform, Traefik can dynamically and automatically manage its configuration using the orchestrator’s API on which it is deployed. Whether you use Kubernetes or Amazon ECS or Docker Swarm, Traefik can be used to automatically manage your ingress traffic.
2. How do you manage a large influx of people working on Traefik?
First of all, we try to make it “easy” to be a maintainer. You don’t have to write tons of code. If you want to invest in the project by writing documentation, helping out on our Slack support channel, or writing tests, etc., you can quickly become a maintainer. Half of the maintainers work at Containous, the company behind Traefik, and the other half are external.
We try to promote external contributions to the project. Therefore, the maintainers team tries to be as responsive as possible on pull requests. We also maintain detailed documentation for contributors. And of course, we build Traefik using Docker, which allows us to get a working development environment in one command line. Everything is made to make contributing easy.
Finally, we automate our process using multiple bots, GitHub labels, and optimizing our CI as much as possible.
3. How do you handle issues and feature requests?
As soon as an open source project gains some traction, issues and feature requests will start to stack up in your inbox. We quickly had to react to avoid wasting too much time on this.
First, we use Github issue templates to promote well formatted issues. This allows the maintainers to quickly get all the details needed to understand the issue. We also added a great feature to Traefik. The command traefik bug will open a pre-filled Github issue with your Traefik version and all your configuration.
Finally, feature requests are prioritized using Github reactions and discussed with the maintainers team.
4. What led you to name each Traefik version by a brand of cheese?
Traefik was born in France and here, we put cheese everywhere. So we decided to do the same in our reverse-proxy.
5. What are the unexpected challenges of managing Traefik, and how did you solve them?
One unexpected challenge we had a few months ago was that the maintainers team was wasting a lot of time merging pull requests. We force pull requests to be rebased on the target branch before merging in order to validate the pull request in the CI. We were asking contributors to rebase their PRs all the time, and we had to wait for them before merging.
Finally, GitHub added an option to allow maintainers’ changes to a pull request branch created from a fork. This meant we could rebase contributor PRs ourselves, but that was not enough. We created a bot that rebases and merges all our pull requests automatically with a simple GitHub label. Yes, maintainers don’t even merge pull requests anymore on Traefik.
6. You say you try to release a new version every 2 months – how do you keep up?
This is funny because our last release cycle was way more than 2 months on release 1.4, but this one was an exception. We try to keep up with this rate by fixing a date for the code freeze at the beginning of the cycle. We don’t release when features are ready but when this date is reached. Work in progress pull requests are postponed to the following release.
7. What tools and guidelines do you use to write tests?
We have unit and integration tests. There is not much to say about unit tests, but integration tests are interesting. Traefik needs to be tested against multiple tools: Docker, Mesos/Marathon, Consul, etc… Vincent Demeester, who is a maintainer, wrote awesome libraries in Go that allow us to launch entire Docker compose stacks within Go tests. The beauty of this is that everything is running in Docker. Our test environment can then be used everywhere, from the developers’ laptops to our CI.
8. How does Semaphore help you achieve your goals?
Earlier this year, we had a challenging issue: compile + tests + deploy were taking more than 50 minutes to run on our CI. We were frequently hitting the CI global timeout. We had difficulties to deploy our releases – that was bad.
We had to work on our CI process. We compared our online CI with multiple other online CIs, and we also tried to run our tests on private VMs. We discovered that Semaphore was way faster than any other solution, even faster than our own VMs! Great surprise!
We migrated our tests to Semaphore and after multiple other optimizations, we ended up having our tests pass in less than 10 minutes.
It goes without saying that we are more than satisfied by this move as we now get quick feedback on pull requests.
9. What advice would you give to developers who are thinking of open sourcing their company projects?
You have to be ready to be strongly involved in the project and be responsive to the community. Say no fast. Make contributing easy. Use diplomacy a lot.
10. Apart from yours, is there an open source tool or project you’re particularly excited about?
As a Go developer, I have (a lot of) issues with the (lack of) dependency management. Not a single day goes by without a team member crying desperately while trying to update a dependency… So yes, I’m totally excited by dep. The future of Go dependency management is hopefully almost here.
Want to have CI builds as fast as Traefik’s? Semaphore is free for open source and you can try it for free on private projects too.
