I’ve written a number of DivOps-focused posts (5 tips for a healthier DivOps setup, 50 shades of React rendering with Next.js, and Auto-generate React PropTypes from TypeScript components just to name a few). But I’ve never actually explained what DivOps is. It’s a play on words for DevOps which is a well-defined role bridging the gap between software development and IT operations.
DivOps to me is the bridge between frontend web development and traditional DevOps. So a DivOps engineer writes code for web frontend applications and libraries, but rarely is any of it shipped to Production or what users interact with. Instead they write all of the tooling and configuration code outside of the
src folder that’s needed for an app or lib to run.
Although I write a lot about DivOps, I can’t take full credit for the term. Enrique coined the term with this tweet:
Frontend engineers who also manage infra should be called <div>ops— Enrique staying ~ (@chochosmx) October 12, 2019
I have yet to see an explicit role for a “DivOps Engineer,” but I think we’re getting close. Typically those fulfilling the role are Frontend Engineers working on the frontend platform (possibly even on a Frontend Platform team), but are not working on the design system or component library. These developers are likely focused on DivOps.
I would like to see companies create explicit roles for this work because it’s highly valuable and critical. In my opinion, formalizing the role legitimizes the work and provides a 3rd path in frontend engineering. In addition to UI development (visual + interaction) or app development (state + API management), there’s now DivOps.
So I want to list out the high-level areas of work to which a DivOps engineer contributes, as well as some of the tooling within each area.
Because Babel and Webpack are so powerful and have such large ecosystems, configuring a
webpack.config.js file takes a deep understanding of how the tools work in order to set things up correctly and provide the most optimized builds to the browser. Because of the complexity and expertise needed to properly configure these low-level tools, there are many other tools that wrap Babel and Webpack to configure them to work with particular web frontend frameworks. I develop in React, and just within React there is Create React App, Next.js, Gatsby, Remix, and many others. These tools do many other things besides configure Babel and Webpack, but one of their goals is to abstract that work away.
But there’s even more once we get passed compilers and bundlers. DivOps engineers may have to setup API integrations like Firebase or Apollo GraphQL. There are also alternative development platforms like Storybook, which requires configuration thanks to its own addon ecosystem. For library/package development, we may need to set up npm or yarn workspaces to create monorepos (or alternatively configure yet another tool like Lerna to help manage multiple packages).
Lastly, DivOps engineers find themselves writing lots of command-line scripts called from npm scripts. Some of the scripts can be codemods that rewrite/upgrade/refactor source code when migrating a codebase. Other scripts orchestrate more tools like
nodemon for running the web app locally.
While the Prettier configuration itself is quite small, getting it to work alongside ESLint takes some knowhow. My post Prettier + ESLint = ❤️ goes into the details if you’re interested. We can also even automatically run linting before we commit our code by configuring
Next, DivOps engineers need to set up and maintain the various testing environments. In my opinion, the earlier they can configure the testing platforms, the healthier the code base remains. The primary frontend unit testing platform is Jest with its massive
jest.config.js configuration file. There is also Mocha (+ Chai), AVA, tape, and many other options.
For UI apps, Storybook serves both as a development environment as well as a testing environment for components. There are addons to connect it with Jest, or even Percy in order to get visual regression tests for components. Storybook + Percy is huge for validating component libraries because they are just as much about the visual look and feel as the UI interactions.
End-to-end testing is also important for web applications and, of course, requires configuration and maintenance. So whether they use Cypress, Puppeteer, WebdriverIO, or Selenium, a DivOps engineer will handle the setup and most likely even write shared helpers for common actions (like a user logging in).
Up until now, everything the DivOps Engineer has set up, configured, and maintained has been local to the repo running on a developer’s machine. But once we get into continuous integration and delivery we’re running on Github Actions, CircleCI, Vercel, or AWS. This is where we start overlapping with the DevOps engineers.
There are so many things that can happen in this area. DivOps engineers can write
Dockerfiles to deploy a Node application to Production with Docker. They may have to configure ngnix files to help serve a statically-generated site. And they write all sorts of bash scripts to help orchestrate all the build tools (like Babel, Webpack, Next, etc.).
And for libraries that get published on npm, DivOps engineers configure tools like
semantic-release or Lerna for handling versioning and publishing. They’ll likely also need to configure Babel, Rollup, or Gulp to transpile source code into ESM and CJS build targets for the published package.
Tools like Create React App and Next.js have CLI commands that will scaffold a new app for us with starter code. A company that is creating many apps or libraries may need to create similar starter templates in order to provide consistency and also ease the burden for creating a greenfield app or lib. Tools like
plop or Yeoman help a DivOps engineer with this.
Phew! 😅 So how about that? I’m sure I left off tons of packages and tools that are part of maintaining a frontend platform or infrastructure, but these should at least be the high-level areas.
I’m really curious. Does your company have an explicit role for something like a DivOps engineer? There is certainly enough work here for one or more folks to focus on this type of work. I would love to see a job description if you have one. Reach out to me on Twitter at @benmvp.
Keep learning my friends. 🤓