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
And my friend Jonathan Creamer made it "official" by creating the #DivOps community. Check out the r/divops subreddit and DivOps Discord server to join the community.
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.
Development environment
The foundation of any modern development environment is a JavaScript compiler/transpiler and module bundler. The most popular JavaScript compiler is Babel, which has a huge plugin ecosystem, but TypeScript and Closure are other alternatives. Webpack is the most popular module bundle with its equally huge plugin ecosystem. And of course there are other options like Parcel, Snowpack, and Rome.
Because Babel and Webpack are so powerful and have such large ecosystems, configuring a babel.config.js or 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 serve or nodemon for running the web app locally.
Static-analysis environment
I'm really a fan of the emphasis on static-analysis within the frontend development ecosystem. Not only can we keep our code consistent by enforcing a coding style, but, more importantly, we can catch issues in our code without ever running it. ESLint (JavaScript) and Stylelint (CSS) are the main players in this space. And because of the size of the ESLint plugin ecosystem, there is lots for a DivOps engineer to configure in the .eslintrc.js file.
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 lint-staged with husky.
One huge static-analysis tool that I now cannot live without is type-checking with TypeScript. I use TypeScript solely as a type checker, leaving Babel to handle the compiling of TypeScript to vanilla JavaScript. There are also tools like GraphQL Code Generator that can generate TypeScript types from a GraphQL schema.
Testing environment
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).
CI/CD environment
While the DevOps engineers are experts at maintaining the Production environment, they are typically trained in backend engineering so they usually are less familiar with maintaining frontend tool chains. As a result, the onus falls on DivOps engineers to do what's necessary to get the web application to Production (or the JavaScript package to npm).
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.
Repo environment
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.
If after reading all this you realize that you are in fact a DivOps engineer, welcome to the #DivOps community! Join us on the r/divops subreddit and DivOps Discord server.
Keep learning my friends. 🤓