At PagoPA, we heavily rely on Infrastructure as Code (IaC) practices to deliver our cloud solutions. Terraform has become a fundamental tool in our engineering toolkit, allowing us to manage our infrastructure efficiently and ensure consistency across environments.

As our projects grew in number and complexity, we faced a common challenge: how to effectively share and reuse Terraform code while maintaining quality and consistency. This led us to explore publishing our modules and provider to the Terraform Registry, all while preserving our internal development process based on a monorepo structure.

In this post, we'll share our journey as the Developer Experience team, the challenges we faced, and the technical solutions we implemented to bridge the gap between developing Terraform modules in a single repository and meeting the Terraform Registry requirements.

The new Terraform module Azure GitHub Environment Bootstrap developed by the DevEx team, has finally left the beta status by reaching its first major version release!

This module is useful for anybody that has just created a new repository and wants to focus quickly on their goals rather than spending hours in setting up everything around the new repository. The module focuses on projects which leverage Azure, GitHub, and a single environment (production). After applying this module, the repository will have:

• completed the setup needed to launch GitHub Actions workflows
• a dedicated private GitHub Runner to connect to private Azure resources from GitHub pipelines
• an Azure resource group to deploy resources generally contained in infra/resources
• the required permissions to operate on domain resources
• a secure and smooth configuration

The new Terraform module Azure Service Bus Namespace has been released by the DevEx team to enable customers to easily and straightforwardly set up Service Bus!

This module abstracts inner complexities such as networking, authentication, and scaling. By choosing the l tier (which matches the Premium SKU), the module provides private communication via private endpoints and also includes an autoscaler resource to dynamically change the number of instances depending on CPU and memory metrics.

The digital services we provide interact through REST APIs that are documented using OpenAPI specifications.

Using API clients requires the code that handles HTTP requests and responses to strictly adhere to the OpenAPI specifications. This is crucial to ensure that the exchanged data is valid and consistent with the defined schemas. Similarly, when providing APIs through NodeJS services, such as Express or similar frameworks, it is important to follow the same standards. This ensures that the APIs are reliable, scalable, and easy to maintain.

Imagine being able to release the first API for a new digital service into production in minutes instead of weeks, having fewer decisions to make, less code to interpret and maintain, onboarding new team members with zero downtime: this is the goal we set for ourselves with the Developer Experience (DevEx) initiative.

At the heart of the Engineering Area, a group of Senior, Cloud, and Staff Engineers has decided to tackle the daily challenges that slow down our work. We're here to break down barriers, simplify processes, and make software development smoother and more rewarding for everyone.