Infrastructure Projects
Infrastructure Projects are a dedicated Project type in the Console for provisioning and managing infrastructure, following the Infrastructure as Code (IaC) paradigm.
They are designed primarily for Operations teams, who can use them to define, version, and deploy infrastructure resources while ensuring consistency, transparency, and control over infrastructure changes.
For example, DevOps teams can use Infrastructure Projects to group all repositories that use tools like Terraform, OpenTofu, Microsoft Bicep, or others to manage resources.
By consolidating these repositories, Infrastructure Projects simplify the release and monitoring process. They allow you to deploy a component and follow a two-part process: a validation phase (e.g., the plan
phase in a Terraform pipeline), where you can review proposed changes and decide whether to proceed, and an execution phase (e.g., the apply
phase in a Terraform pipeline), where the changes are actually applied.
These Projects are distinct from traditional Application Projects as they are specifically designed to manage infrastructure resources, enabling better control, automation, and governance in the context of IaC. They can be connected to multiple repositories containing code and scripts to deploy resources in your infrastructure, providing the ability to deploy quickly with a review of the affected resources.
Infrastructure Projects are currently a BETA feature and are under active development.
At this time, they only support GitLab and Azure DevOps repositories with a specific pipeline configuration. Support for other providers will be added in future Console releases. You can find out more in the technical limitations section below.
If you want to share your feedback, you can head to the Community discussion post.
Creating an Infrastructure Project
When creating a new Project in your Company, you can select the Infrastructure type. This option unlocks a dedicated setup flow and enables the creation of a Project tailored to infrastructure workflows.
Managing Infrastructure Components
Each Infrastructure Project includes a specific section for managing infrastructure components.
Currently, it is possible to add components from scratch, referencing existing repositories in the provider of the project.
In the near future components will be available in the Software Catalog, to quickly install components simplifying the configuration and allowing to share these configurations with other users.
To create a new infrastructure component from scratch, you need to provide several information, which depends on the type of provider of the project.
- GitLab
- Azure DevOps
- Name: The name of the component.
- Repository URL: The URL of the Git repository where the component's code is hosted. This is used to provide a reference to the user.
- Branch/tag Name: The Git branch, tag, or commit that the deployment pipeline will run on.
- Repository Project ID: The project ID associated with the Git repository. This is actually used to interact with the Git Provider.
As example:
- Repository URL:
https://my.gitlab.host/some/repo
- Branch/tag name:
main
- Repository Project ID:
some/repo
As a Repository Project ID, you can use the relative path of the repository or the numeric identifier that you can find in the Settings section of the repository.
- Name: The name of the component.
- Repository URL: The URL of the Git repository where the component's code is hosted. This is used to provide a reference to the user.
- Branch/tag Name: The Git branch, tag, or commit that the deployment pipeline will run on.
- Repository Organization Name: The name of the Organization that contains the repository.
- Repository Project Name: The name of the repository that contains the code to be deployed.
- Repository Pipeline ID: As Azure DevOps allows to configure different pipelines, this is the numeric identifier of the pipeline configured
As example:
- Repository URL:
https://dev.azure.com/my-organization/my-project
- Branch/tag name:
main
- Repository Organization Name:
my-organization
- Repository Project Name:
my-project
- Repository Pipeline ID:
1
The Repository Pipeline ID is not the name of the pipeline, but the identifier that can be found in the settings of the pipeline itself.
You can alternatively find it by navigating into your pipeline page: on the address bar the definitionId
value is the pipeline identifier.
Deploying your Infrastructure
From within your Project, you can manage the deployment flow of your infrastructure components by:
- Running a plan to preview proposed infrastructure changes
- Executing an apply to confirm and release your infrastructure changes
This enables control and consistency in your infrastructure.
Deploy History
The Deploy History page is useful to better understand which actions have been executed for each infrastructure component of your Project.
In particular this view traces which component has been deployed, together with some additional information.
Pipeline Webhook
In order to correctly fill up the Deploy History view, an Infrastructure Component must have a webhook associated to its repository on the git Provider.
The webhook is automatically created upon the Infrastructure Component creation. However, in case the webhook creation fails, a warning message will inform to manually retry the webhook creation from the Infrastructure Components Overview page.
If an Infrastructure Component is missing the related webhook on the git Provider, the Component will show highlighted to inform of this issue. On the right side of the Component row, a dedicated action appears to manually retry the webhook creation.
Runtime Visibility
After the deployment of your infrastructure components, runtime data retrieval can be integrated in the Console by leveraging the Infrastructure Component Runtime Software Catalog item type.
You can later access the data via API or by creating a custom extension using the Composer extensions
Access and Permissions
Currently, all members of a Company can view Infrastructure Projects.
However, only users with the role of Project Administrator or Company Owner are allowed to perform changes within them.
Technical limitations
As mentioned above, there are still some technical limitations that repositories must conform to in order for Infrastructure Projects to work.
All of the following limitations will be soon resolved
- the repository must be on one of the following:
- GitLab and use GitLab CI
- the GitLab CI pipeline must be composed of two separate jobs named
plan
andapply
- the GitLab CI pipeline must be composed of two separate jobs named
- Azure and use Azure Pipelines
- the Azure pipeline must be composed of three stages: the first stage has to be named
plan
, the second stage must be aManualApproval
, and the thirs stage must be namedapply
- the Azure pipeline must be composed of three stages: the first stage has to be named
- GitLab and use GitLab CI
- creation from Marketplace is not supported yet, so you need to create your repository beforehand