It might seem like a lot of what we do on frontend is to make our lives easier, but what I’ve learned in the past two years as a GitLab team-member and a community contributor is that if we make our lives easier, we can make a lot of customers happier, too. Over the years, I’ve experienced many changes at GitLab, from a change in processes to an increase in team members. From an early stage, the frontend team has been committed to continuous improvements, but working in a rapidly growing team required an investment in the way we work.
When I joined GitLab we still used some of the default conventions that the Rails framework recommended for the frontend, and it helped us for quite a while, but the more code we touched, the more code we needed to test and build for performance, making it more challenging for us to maintain. The frontend team realized that we needed a way to facilitate code consistency, fast delivery, and simple automation, so we decided to incorporate DevOps and CI/CD into our workflow.
Frontend DevOps and CI/CD workflow
We used CI in a few scenarios, including using linters to help write a consistent style of code throughout GitLab, but in the case of our JavaScript code, we realized that building for performance and maintainability was becoming increasingly difficult. So, we moved away from the asset pipeline and utilized webpack, which has given us a series of benefits. For example, when we develop locally, debugging code is now a breeze, and the jobs that are frontend related run on production-bundled code, ensuring a testing environment that closely resembles that of a user.
After CI, we publish code using DevOps by hosting it with GitLab Pages). We’ve seen several projects benefit from adopting a DevOps model, including GitLab SVG libraries and Trello Power-Up.
When we created GitLab SVG libraries, we wanted to use them for ourselves and make them available to the general public, so whenever we publish a new version, we use GitLab Pages so that it’s fully automated every time.
With the Trello Power-Up plugin, we use DevOps to address compatibility issues when a new version of Trello is released. GitLab Pages makes it easy to deploy a new version, in a fast and diligent manner, so that it’s accessible in the Trello Marketplace as quickly as possible.
Frontend DevOps and Data-driven efforts
Incorporating frontend DevOps and CI/CD into the workflow has had a significant impact on efficiency and results. We have greater insight into our operations and have metrics to help us detect major areas of improvement. We set up Sitespeed using Kubernetes to analyze sets of pages and provide reports on anything that could hamper our users’ perceived performance, from CSS and JavaScript bundle sizes to accessibility issues and the render time differences between various points in time. The information we gathered using Sitespeed has helped us improve the merge requests page and identify pages that render slowly. Having more data has changed the way we approach problems at GitLab, because we are able to focus our efforts on specific areas.
The unexpected discovery of problems
One of the unexpected benefits of our workflow is the discovery of problems that we may not have identified.
A lack of automation
We realized, for example, that we lack some automation in our tools. For instance, every time we didn’t format code in a specific way, our linter notified us, but analyzing and fixing the code slowed down developer velocity, so we decided to add Prettier to format our code in our merge requests for us. We also realized that, sometimes, we need a little bit of automation when we publish code. As an all-remote company, many of us work on public WiFi, and we found that unreliable connections could have detrimental effects while deploying code. The combination of CI and DevOps made deployments easier. If we triggered a pipeline and a coffee shop WiFi goes vamoose, it doesn't matter. We already automated a significant part of our development process, but we’re always striving for more.
A lack of speed
In the case of CI, we noticed that our own tools can be a source of problems. We found that we didn’t make the necessary considerations to keep our test suite fast. As developers, we want to go back to developing as fast as possible. A few of my teammates discovered that our test runs were becoming slower and slower with each release. Even though these are not customer-facing changes, it has made both product managers and team managers consider investing in those issues, because the easier the development cycle is for the developers involved, the better it is for our customers, since we can deliver even more features. Furthermore, we can prevent regressions from happening by having solid foundations, such as testing, code style, and code formatting.
Every time we discover problems that affect us or our work, we realize that we can also jeopardize the features and experiences we want to deliver to our customers. It has changed the culture inside the team, because we view performance issues as developers rather than as GitLab team-members.
Advice to frontend teams
Using DevOps and CI/CD in a frontend workflow is compatible with teams of any size, including small teams that may want to ensure that their code styling is the same.
Put a linter in place
With CI, the smallest and perhaps one of the most significant steps is to put a linter in place, and if the pipeline doesn't pass, you can’t merge the code. That's such a simple, effective way to improve your code and to keep it tidy and clean in the long run. Just setting up some simple steps using CI will improve your team’s code and your developers’ quality of life so that they don't have to worry about combing through past code. Even though small teams might not find the value in the short term, when they scale, they certainly will.
Create consistent scenarios
The bigger the project, the more you realize that some of your tooling ends up running locally, and it's beneficial to run it on CI. If something doesn't work on a generic type of machine that has enough dependencies installed to run your CI setup, that means there’s something wrong and that you should probably fix it before merging your code. As long as you can create a consistent scenario in which you can do things like testing and linting, you should be in a good position to deliver a great product.
Select CI-compatible tools
For teams of all sizes, it’s important that the tools you select as part of your workflow are compatible with CI in some way, so that even if you had a big part of your workflow running locally, you can easily move to CI by creating a pipeline that resembles that of your daily workflow. Regardless of the tool that you choose, creating a job for it will return a lot of value in the long run. If it makes sense, I encourage you to add it, because there’s very little incentive not to. CI-compatible tools include tests runners, linters, Prettier, or any custom-made tools that help you in some way. One decision you might want to avoid is creating on servers that live on CI runners. Since they only run for a limited amount of time, these servers will stop existing. You could also add deployments to your CI workflow, helping you with DevOps and preventing you from worrying about complicated local setups for new developers. The possibilities are huge.
Add performance testing
To add to the pool of possibilities, why not add performance testing to your merge requests with a tool such as Lighthouse, which can help you understand potential performance bottlenecks in your website. Or, maybe your team can add the ability to generate code documentation and publish it via GitLab Pages. CI/CD can be a really good tool, because it will return something immediately. It's just a matter of how you want to use it, depending on your needs.
The more the frontend team uses CI and DevOps, the more we discover ways to use it, so it’s worth it to us to invest in this tool.
Sometimes, we just want to get stuff out there without too much consideration for tooling and CI and CD, but because of the benefits we’ve experienced, we now include CI/CD in all of our projects. With GitLab, everything is integrated, so why skip it? Instead of fighting against automation, I encourage teams to embrace the idea that CI is there to help you.
Cover image by Zhipeng Ya, licensed under CC X.
