The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Deploy |
| Maturity | viable |
| Content Last Reviewed | 2023-04-04 |
Welcome to the direction page of the Deployment Management product category of GitLab. This page is part of the bigger Delivery direction. It is owned by the Environments group and is maintained by Viktor Nagy (Email).
Your feedback helps us building a world-class deployment management offering in GitLab. We welcome your feedback in issues, epics and are always open to user interviews to learn more about your use cases or share more details about our roadmap. You can register a call with us through your GitLab account manager or customer support.
–>
The scope of the Deployment Management category is everything related to deploying your code to its target infrastructure. It includes every possible target infrastructure from mainframes to mobiles store, serverless providers, VMs or Kubernetes.
At GitLab we call the target infrastructure that a deployment targets an Environment. As Environments are a central part of Delivery that include both Deployment and Release functionalities, we have a dedicated direction to improve the environments offering.
Deployment management includes every aspect of deployments. Without aiming for a full list of the scope, it includes:
Managing an organization's deployments is a major challenge. Particularly in larger organizations, with the proliferation of services, technologies, dependencies on one side, and compliance and security requirements on the other side, many teams find themselves struggling to deploy frequently and consistently in a repeatable manner.
Platform teams want to help development teams become more efficient; so that they can meet compliance and security requirements and deploy to environments they can't (and probably shouldn't) access directly, without slowing down their ability to implement changes to their applications.
We envision a fully declarative, scalable, modular, testable approach to deployment management that supports any major target infrastructure from bare metal servers to container orchestrators to edge devices and mobile app stores.
Declarative operations is to the devops pipeline what serverless is to infrastructure. It shifts the responsibility of operating the underlying systems from the developer to provider, and enables the user to focus on their business instead. The provider of these functionalities is often a platform team. We want to simplify the life of a platform team by supporting them with tools and frameworks.
The biggest difficulty with every automation tool is that it is code. As a result it requires developers to write it, a runtime environment to run it and a lot of investment into learning the tool chain. Compare this to the declarative nature of Kubernetes. With Kubernetes everyday developers realised that operations are complex, but operations were complex even before Kubernetes. Kubernetes, with its declarative, everything as data approach made this complexity approachable for every developer.
At the same time, Kubernetes made it clear that higher-level abstractions are required for developers without compromising the core flexibility of the container orchestrator. This is a learning we want to build on and provide a framework and conventions that allow for a platform out of the box.
We envision our solution to have several layers in terms of user value and complexity.
Today, we focus our efforts on the Gitlab Agent for Kubernetes. The agent provides great flexibility, but does not offer any out of the box, white-glove experiences for less experienced users. We want to add higher layers of abstractions on top of the agent.
The second layer, what we call GitLab Delivery on the previous image, includes various integations, and a framework that supports platform teams to build out their own solutions, potentially replacing parts of the tool chain we integrate with. This layer should integrate well with other GitLab stages, especially around Package, Release and Secrets management.
The third layer, that is closest to the current Auto Deploy offering, provides a conventions based, fully-managed solution for our users. It can be approached from two different angles. First, from the software developers' point of view, it's a black box that should "just work" and provides a full delivery process from ephemeral environments to production. Second, from the platform engineers' point of view, it's a customized version of the GitLab Delivery layer. It allows minor modifications and customizations that as long as the conventions are followed provide a GitLab supported platform.
As we increase the value managed by GitLab, we need to increase the complexity owned by GitLab. At the agent level, we are responsible for the core cluster connection only. To best understand the agent, one should think of it as not providing any user-level features. It is responsible for maintaining a bi-directional communication channel between a cluster and GitLab. At this level, we try avoid 3rd party integrations as much as possible to minimize our maintenance costs and build an extremely reliable foundation for higher-level features. We add various features on top of the core connection, like the Flux integration, push-based deployments, security scanning, direct access of cluster resources from the GitLab UI, etc.
At the GitLab Delivery level, we need to pick at least a few tools and integrate those into our offering. The set of tools likely includes an ingress, a secrets management solution, a certificate management solution, support for advanced deployment strategies and integrations with GitLab Observability. At this level, we need to build out integrations and conventions that simplify the work of a platform engineer and can serve all our users.
On top of GitLab Delivery, Auto DevOps requires even more integrations. At this stage the vision is that the end user provides us a Dockerfile or a container and we return them a URL where they can check out their application. On top of the integrations mentioned under GitLab Delivery, we would likely want to add integrations with even more specific tools, like Knative and a Service Mesh. As the Auto DevOps codifies an opinionated process, we should aim to serve 80% of our users out of the box, and allowing the remaining 20% to be served by the GitLab Delivery framework.
Finally, expanding the scope of Auto Deploy to other deployment targets, mobile for example, likely requires a totally new set of integrations. At the same time, we should want to build a generic Delivery framework that works with any target infrastructure.
Our plan for the following year includes three major directions:
We decided in January 2023 to use Flux as the recommended approach for doing GitOps with GitLab. While Flux is a mature CNCF project, we see plenty of ways to improve the user experience around it by integrating it with GitLab. Primarily, we plan to:
Besides the above concrete plans, we are researching the best approach
We compiled a list of issues that block the final removal of the certificate-based cluster integration functionality, deprecated in GitLab 14.7. We plan to ship a solution to these issues to unblock the removal. If we manage to follow our plan, we would like to remove the certificate-based cluster integration in GitLab 18.0.
Some users are unable to transition to the agent for Kubernetes, because their clusters can not access their GitLab instance. With the certificate-based integration, GitLab reached out to the cluster to carry out its tasks. While the agent-based setup supports both directions to send a message, the initial connection today is set up starting from the cluster. We want to lift this requirement to unblock all our users in their journey with the agent for Kubernetes.
Another important theme in this area is the replacement of GitLab managed clusters. GitLab managed clusters allow automatic namespace and service account creation and have conventions from review/ephemeral environments to production. This functionality is not supported yet with the agent infrastructure. We are looking into approaches how to provide a similar experience.
Besides providing basic cluster insights as part of the environments. We want to provide a complete Kubernetes dashboard as part of GitLab. This should allow users to simplify and secure their operations as engineers won't need direct access to clusters for troubleshooting.
The dashboard will provide insights about all the resources available in the cluster with related events, log tailing and - when appropriate - pod terminal functionality.
This theme is currently being researched and architected. We plan to provide a Deployment management project built-into GitLab.
A core building block of Deployment management is a GitLab project to store the declarative deployment definitions in a structure following GitLab-defined conventions and using the GitLab agent for Kubernetes, to consume the content stored in a GitLab Deployment management project. A Deployment management project is supported by GitLab as long as it follows the GitLab conventions.
A note to help understand the management project: This approach we imagine is similar to various frontend tools, like "Create React App", "Expo" (React Native). These tools provide a simplified experience out of the box for 80% of the use cases. If the user needs more flexibility, they can eject. Thus, the user owns their project, but a lot of complexity remains hidden from them to support them focusing on their business problem. This is aligned with the convention over configuration product principle of GitLab.
The Deployment management project should describe:
The Deployment management project might include:
The features from this area closely related to our Environment management direction.
This section shares our plans towards simplifying the Delivery experience for our users . This direction is currently being researched and architected. It will very likely change.
The GitLab Delivery framework is an opinionated selection of tools to support platform teams in providing white-glove delivery experiences to software developers.
| Ease of use | Complexity |
|---|---|
|
|
The more user friendly GitLab makes a solution, the more complexity we become responsible for. Increasing complexity means increasing maintenance costs and higher customer value.
The agent for Kubernetes is the core building block of the GitLab Delivery framework on Kubernetes. With its Flux integration, it provides a reliable, production ready tool for cluster connection and declarative deployment management of Kubernetes clusters. The GitLab Delivery framework extends our product offering on top of the agent for Kubernetes.
The GitLab Delivery framework plans to offer a customizable selection of shared cluster tools from ingress to observability integrated across GitLab. We need to pick at least a few tools and integrate those into our offering. The set of tools likely includes an ingress, a secrets management solution, a certificate management solution, support for advanced deployment strategies and integrations with GitLab Observability. The framework should integrate well with other GitLab offering, especially around packages, secrets management and security.
The GitLab Delivery framework will be integrated with the Deployment management project. The two working together should support
We are working towards introducing services into GitLab and the design of the delivery framework.
We are working on improving the Flux - GitLab integration, making Flux reconciliation to show up in a pipeline and providing a full-featured Kubernetes dashboard built into GitLab.
We worked mostly on the Flux and cluster UI integrations. As a result, we provide users with
In the deployment management scope, we don't plan to
A separate single-engineering group works on mobile DevOps, including deployments to mobile stores.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
A BIC deployment management solution should provide a fully declarative, scalable, modular, testable approach to deployment management with an easy to understand GUI that describes the current status of a deployment process.
The primary persona is the Platform Engineer. Their job is to support all the development teams with standardised and compliant pipelines.
The secondary personas are the Application Operator and the Compliance Manager. The Application Operator is responsible for deploying and operating the business applications, while the compliance manager assures that all the processes follow internal policies.
Deployments don't live in a vacuum, but are part of a companies delivery process. They are preceded and followed by CI jobs, are surrounded by security checks and guardrails, are integrated with monitoring and work in coordination with release management. We created a user story map to highlight and discuss these cross-stage and intra-group jobs and integration requirements.
This section establishes the pricing alignment scaffolding for this category based on GitLab's buyer-based tiering.
Managing deployments using existing CI/CD features, such as using include will continue to be free. For a large number of GitLab users, from individual developers to small companies, this is sufficient.
Most GitOps and agent for Kubernetes features are available under Free as long as using the agent's in-cluster Service Account is used.
Features that require special permissions will fall under the Premium tier. This includes deployment approvals or cluster access impersonating a GitLab user's identity.
Features targeting a dedicated platform team fall under the Premium tier. While platform engineers are individual contributors, they do not contribute directly to the business. Their contribution is indirect, through increased developer productivity, security and reliability. Thus a platform teams assumes a non-IC decision maker who expects a level of standardization across several teams.
Helping organizations with a standards-based and compliant deployment pipeline is critically important that gets the attention of CIOs. Dashboards that summarize compliance and empower leaders with a birds-eye-view of their entire organization's change management solves a fundamental problem for GitLab's largest customers.
Security guardrails and policy attestation support and reporting fall under this category.
Strong collaboration requirements with partially locked release artifacts fall under the Ultimate tier.