Atlassian this week made generally available a Compass developer experience platform through which DevOps teams can employ a software-as-a-service (SaaS) platform to centralize the management of the environments used to create code.
Taylor Pechacek, head of product for Compass at Atlassian, said Compass provides an instance of an internal developer platform (IDP) that is simpler for DevOps teams to set up and maintain.
At its core, Compass provides access to a software component catalog to track, search and discover the component and approved infrastructure that can be used to build and deploy applications.
In addition, templates enable developers to self-service environment setup using a set of policies that provide guardrails to ensure developers follow best practices for provisioning cloud resources and setting up pipelines.
Finally, Atlassian is making available scorecards based on the DevOps Research and Assessment (DORA) metrics defined by Google.
Compass is designed to be integrated with a wide range of continuous integration/continuous delivery (CI/CD) platforms and third-party observability, testing, collaboration and source code management tools, said Pechacek. The goal is to minimize context switching as much as possible for developers accessing the Compass platform, he added.
That approach also provides a level of consistency that both fosters collaboration and makes it simpler to onboard new members to a development team, noted Pechacek.
While IDPs as a concept have been around for some time, they are now central to any effort to embrace platform engineering methodologies to implement best DevOps practices at scale. The issue platform engineering teams need to come to terms with is determining whether they want to build and maintain an IDP versus invoking one provided as a SaaS application.
Regardless of approach, platform engineering teams are trying to strike a delicate balance between centralizing the management of development environments and the ability of developers to innovate by adding new tools to their development environment. Organizations clearly want developers to become more productive by spending less time managing development environments, but many of those same developers tend to jealously guard their prerogatives when it comes to the tools they prefer.
The challenge, of course, is that spending less time managing a development environment doesn’t necessarily mean more code will be written. All it does is afford developers the opportunity to write more code. The issue is that the writing of quality code only really occurs when developers are inspired, but at the very least, configuring a development environment shouldn’t stand in the way of creativity.
It’s not clear how many organizations are embracing platform engineering methodologies, but it’s apparent that more supervision is being brought to how applications are built and deployed within the context of a set of DevOps best practices. The challenge and the opportunity now is to make sure developers buy into, rather than resist, those efforts.