FrontOps – A new fad, right?

The Challenge

In cross-functional teams, individuals with diverse knowledge and areas of expertise collaborate. At least one of them will have focused on front-end technologies such as HTML, CSS, and JavaScript, if the team's work product is web applications.

In many teams, I was involved with, responsibility for the frontend code ended with the commit. Dedicated front-end developers at least took care of the scripts in the JSON package and used Git hooks to ensure quality standards were met before the commit and push.

Before the code is available to the (hopefully happy and satisfied) customer, several steps are required, which, in my opinion, also fall under the responsibility of the front-end developer. Given the abundance of tools and possibilities, a new term is emerging: FrontOps.

The (New) Responsibilities of FrontOps

As a modern, responsible developer, the black box after the commit should be opened and become their responsibility. This includes things like the following, to just name a couple:

• Build pipeline, e.g., in the form of GitHub Actions.
• Provisioning and optimizing a Dockerfile for containerization.
• Documenting and maintaining environment variables.
• Test maintenance, execution, and result documentation in the build pipeline.

This results in a comprehensive profile for the FrontOps role:

• Expert knowledge in the frontend area.
• Basic understanding of backend API and effective communication between client and server.
• Willingness to learn and migrate concerning frontend tools to remain state-of-the-art.
• CI/CD (DevOps) knowledge for the build pipeline of the frontend code.
• Providing technical support for the tool chain.
• Monitoring and analysing UX to identify errors and problems early on.

The more complex (old) tasks of FrontOps

At this point, I would like to champion frontend development. Other developers often ridicule this discipline. The joke "there's a new JS library every minute" alone demonstrates the rapid pace of change that must be dealt with in the frontend area.

Making the right (long-term) decisions within a project is an enormous challenge. With the availability of tools, the possibilities for implementing something grow. At the same time, it's essential to understand the backend with the UX to enable performance-optimized data requests in the API because let's face it: Ultimately, the frontend should always be as fast, reliable, and intuitive to use as possible.

The latest developments are moving away from the monolithic frontend toward the micro-frontend. A trend that is already common in the backend and makes sense for larger frontend applications. I mean, frontends are just as complex as backends. It's just different – ​​I'd love to watch an unteachable backend developer ensure that functionality is responsive across multiple browsers on all devices, mobile and desktop, in all resolutions. And ensure this through automated testing in the build pipeline.

Conclusion

The new role of FrontOps isn't as new as it might sound at first. It's the logical consequence of a self-organized, agile team that is further developing the old, classic roles with a broader perspective.

Thus, a pure backend developer is brought into the responsibilities of operations and given the new role designation of DevOps. Furthermore, the DevOps role requires developing an understanding of the frontend. At the same time, the frontend developer role must be expanded to take on responsibility for deployment and operations. The former pure operations roles cannot create meaningful solutions for stability, resilience, scaling, or performance without knowledge of what they are operating on.

Thanks to my work as a full-stack developer, I have insight into all three areas (frontend, backend and operations). The multitude of tools combined with the diverse requirements of each project is precisely what makes my job so appealing. It never gets boring, and there's something new to learn every day.