The workflows that power Eugene front-end projects
At Eugene every front-end project leans heavily on automated workflows for testing, checking code quality, building preview environments and deploying changes to production environments. Combined with our use of GraphQL it gives front-end developers the power to build, prototype and showcase changes instantly whilst maintaining code quality and running tests.
How we landed on Github Actions 🧑💻
Early on at Eugene we set all the front-end CI up using CircleCI and pretty quickly ended up hitting plan limits. When we looked into it most of our job time was coming from booting up the Docker instance rather than running any of our tests or builds. There’s a limit to how much caffeine the human body can ingest a day, and I either had to find a new thing to do while waiting for CI jobs to finish or find a new CI. When Github Actions finally launched in November 2019 we migrated some, and then all, of our workflows over to it. We managed to get our setup time from more than a minute to less than 10 seconds by using the core ubuntu-latest runner instead of our custom Docker image and now most of our workflows run in less than a minute.
Tests, tests, tests 📝
For our our tests on the front-end we use a combo of Jest, enzyme and react-testing-library. We use Enzyme mostly for testing internal tools because it’s easy to test how complex pieces of data get displayed on the ui and our internal tools are mostly giant lists of large amounts of data. For our customer facing projects we use react-testing-library because it accurately maps the end-user experience and ensures we keep our ui accessible.
Early on at Eugene we did a lot of Jest snapshot testing of React components. We no longer do it because some of the snapshots being generated were huge and a lot of the time when a snapshot test failed it didn’t tell you much about why or how.
Linting branch changes 🧹
Linting is one of those things which inspire both dread and absolute pride — but from a pure business perspective it cuts down on unnecessary pull-request feedback by getting there first. We had two challenges implementing linting. Challenge 1 — we implemented it late and Challenge 2 — it takes long enough to run that you wouldn’t run it often enough to be useful. We managed to solve both challenges by using a forked version of git-diff-lint to only lint files that are touched by the current branch. It also means in pull requests linting errors are only ever about the files changed within that branch so features don’t get delayed due to unrelated code cleanup tasks.
Preview environments 🖥
One of my favourite parts of our front-end workflows is preview environments using Linc. We were one of Linc’s early customers and they’ve been absolutely awesome at helping us set up workflows where we can preview our front-end branches using multiple back-end configurations.
Whenever a pull request is created, or any subsequent commits are made to the pull requests, a preview environment is created that can be shared with anyone in the team for rapid feedback. Preview environments link to different environment variables which determine which back-end should be used. The back-end team can also uses master preview environments to check dev api environments aren’t breaking the front-end.
Tag and deploy 🚀
Once a pull request is approved and merged into the main branch, our deployment workflow kicks off. We start by generating a version number and tagging the release. Then the release is built and the source-maps are sent to Sentry with the release version. After that the front-end is packaged and deployed to both Linc as well as the projects front-end hosting platform. After that there’s a bit of cache clearing and deployment is complete. All in all it takes around 3 minutes for a master branch to deploy to production.
Want to work in a place where meaningful work is done with awesome tools? Head over to https://angel.co/company/eugenelabs and get in contact with us.
