Section Direction - Ops

  1. 表示中のページ:
  2. GitLab Direction
  3. Section Direction - Ops

Ops Overview

Ops Section Overview

Composition

The Ops Section is comprised of the Verify, Package, Release, Configure and Monitor stages of the DevOps lifecycle. Market analysts (internal - i) often describe these stages as automated software quality (ASQ, partially correlated with Verify, Package and Release) IT automation and configuration management (ITACM, correlated with Configure) and IT operations management (ITOM, partially correlated with Monitor). The section also covers CI/CD (Verify/Release), IT Infrastructure Monitoring/APM (Monitor), CDRA (Release), Infrastructure Configuration (Configure) and Package and Binary Management (Package) analyst categories.

In some contexts, "ops" refers to operators. Operators were the counterparts to Developers represented in the original coining of the term DevOps. That definition highlighted the rift between the two groups and a need for collaboration. At GitLab, we use "ops" to mean operations - any component of the software delivery value stream after a developer commits code. Our developer first perspective means our use of the word ops is focused on enabling developers to configure tools and perform operations tasks first. We have ambitious plans to support operators in the future.

Market

The total addressable market (TAM) for DevOps tools targeting these stages was $3.2B in 2018 and is expected to grow to $7.6B by 2022 (18.8% CAGR) (i). This analysis is considered conservative as it focuses only on developers and doesn't include additional potential users. This is a deep value pool and represents a significant portion of GitLab's expanding addressable market. As organizations further adopt DevOps, developer focused ops tools account for a larger share of a market. This market has traditionally targeted IT's Architects, System Admins and Operators where large hardware budgets enabled expensive IT tools to flourish.

The market is well established (i), but the participants are evolving rapidly. Existing leaders in single stages of the DevOps lifecycle are expanding towards a complete DevOps delivery platform via acquisition and product development. These existing leaders run the gamut from GitHub with their strong position against the Create stage and growing capabilities to compete with Verify, to Splunk with their strong position against Monitor. All are pivoting to pursue a single DevOps platform strategy.

Expanding market players such as GitHub are taking market share from traditional participants like CloudBees in the Verify stage. In the Package stage, JFrog is looking to expand their leadership position in artifact repositories into other stages of the DevOps lifecycle. In the Release stage Spinnaker is a new open-source, fast growing entrant enabling collaborative CI/CD workflows and taking market share from traditional Application Release Orchestration vendors. Splunk, New Relic and Datadog are dominating market share in the Monitor stage and fiercely competing to be a central monitoring platform. IBM (+RedHat), HashiCorp, Puppet and Chef share a large chunk of the fragmented market in the Configure stage.

Current Position

Despite many strong players, GitLab's market share in the Ops section is growing, especially in the Verify, Package and Release stages. For the Configure and Monitor stages, our unique perspective as a single and complete DevOps application positions us for growth. Our customers utilize many Ops Section stages today. Primarily they:

Our current R&D investment in Ops Section stages is large. The maturity of each stage and category can be found in our maturity page. Our investment in the Ops section is critical to both enabling enterprise users to continue on their DevOps maturity journey and completing our complete DevOps platform vision. Driving adoption across multiple Ops stages enables early adopters to recognize the benefit of a single application.

We would appreciate your feedback on this direction page. Please take our survey, email Kenny Johnston or propose an MRto this page!

Challenges

GitLab is competing in a new market of value stream delivery platforms (i - Gartner). We were an early entrant in this market before it was defined but there are many, and will be more, fast followers. Key players include large established tech firms (Microsoft) as well as newly consolidated platforms from aquisition (JFrog, CollabNet/VersionOne/XebiaLabs).

Beyond the key players, there is also rapid innovation. This makes for a market where there is proliferation of new technology concurrent to consolidation of the winning technologies into comprehensive platform players. Ease of deployment for CI/CD and operational tools has aided this expansion: developers and operations teams can easily instrument and utilize new technologies alongside their existing software development pipelines with less risk, and in quicker time frames than under previous models where it required diligent planning and months of installation and configuration.

Competing tools are typically marketed as stand-alone point solutions. In contrast, GitLab's capabilities shine when customers use other stages of GitLab. This can create a narrow funnel for adoption with potential users coming only from the segment of the market already using, or willing to use, other stages of GitLab rather than broad-based market fit. Without developing more landing spots for new users of GitLab, this smaller adoption funnel will affect our rate of learning.

Few companies have been able to successfully bridge between Developer and Operator personas. Building tools that satisfy both sets of jobs-to-be-done is difficult. Without deeply understanding new personas and tasks, market entrants end up with a checklist of modules that don't represent a cohesive and improved experience for users.

In recent years we've seen the emergence of large public cloud infrastructure providers moving from a focus on infrastructure services for operators towards developer tools. These providers could challenge current notions of multi-cloud by creating great, integrated experiences in their tools for developers to create, verify, and deploy applications to the provider's infrastructure. There is a possibility that these provider-centric ecosystems present organizations with a choice of investing in a best-of-breed platform with a small subset of projects or a just sufficient enough platform used by all.

Outside of market challenges we have some internal ones as well. In general, we are not dogfooding the Release, Monitor and Configure stage features sufficiently. This has the effect of slowing our rate of learning, and putting us in the position of not having immediate real-world validation of our product initiatives.

Opportunities

Given these challenges, here are some key opportunities we must take advantage of:

3 Year Strategy

GitLab's Ops strategy follows that of GitLab's company strategy. Just like our company mission, we will enable everyone to contribute beyond application code to other digital artifacts that increasingly define the performance, reliability, and resilience of the world's software. We will pursue that mission and capitalize on the opportunities (such as, developer buyer power, IT skills gaps, a move towards Kubernetes, and our roots in source-control and CI) by utilizing a dual-flywheel approach. This approach starts with attracting developers performing DevOps tooling and operations tasks to our Free/Core tier. As we build best of breed tools for them we will co-create with the community to drive product improvements. This will generate revenue for higher product tiers and additional investment for supporting the modern development teams.

More specifically, we will achieve this by enabling easy-to-discover workflows that support doing powerful, complex actions with a minimum of manual configuration. We want to take advantage of our single application so that, while each team may have their own views or dashboards in the product that support their day to day, the information about what is deployed where is available everywhere and to everyone, embedded naturally into the product where it's relevant. For example, a person thinking about upcoming releases may interact mostly with an environment-based overview that helps them see upcoming changes and alerts as they flow through environments, but that same information exists everywhere it is relevant:

The end result is that even complex delivery flows become part of everyone's primary way of working. There isn't a context shift (or even worse, a switch into a different tool) needed to start thinking about delivery or operations - that information is there, in context, from your first commit. The centerpiece of this strategy is our Get Things Done Easily theme.

Market Predictions

In three years the Ops market will:

GitLab Goals

As a result, in three years, the Ops stages in GitLab will:

Themes

Our direction for Ops is to enable today's modern best practices in operations without the burden of specialized teams, multiple tools, and heavy workflows that are the largest barriers to adoption in these stages of the DevOps lifecycle.

Our goal is to empower DevOps teams to own their code's path to production as well as the performance of their production application itself. We also want to ensure they have the tools to contribute to feature development and the complete end-user experience of their application.

Our themes are directly aligned to our overall Product Principles especially:

In addition to our broad product themes there are some specific call-outs relevant for the Ops Section stages.

Speedy, Reliable Pipelines

GitLab CI/CD was built from the ground up with speed and scalability in mind. This is reflected both in the product design as well as product vision (automated testing, testing all the things). To enable our users to go from monthly shipping releases to truly enabling continuous delivery, everything that we do must be concerned with the scalability and speed of continuous integration and testing. Not that sword fighting on office chairs isn't fun, but we do want people to be able to contribute at the speed of development. We will achieve this through automated tuning where possible, and faster feedback on potential issues where not.

Wall clock time for a pipeline is an important measure here. You feel this many times every day - when you make a commit and a pipeline starts, but you need to go have lunch before you see the result, that's not fun for anyone. Issues like our auto-determining the test parallelization factor and running tests likely to fail first represent how we want GitLab CI/CD to automatically find and solve these problems for you. We are building more speed into the workflow itself with features like the dependency proxy to help speed up the tax you pay on every job invocation setting up the environment, fetching dependencies, and so on.

Compliance, Infrastructure and Observability as Code

There have been three major trends impacting operations; they are all three essential to enabling Developer style workflows for operational tasks by defining those activities as code (or data). They are Compliance as Code, Infrastructure as Code (IAC) and Observability as Code (OAC). At GitLab, our roots in SCM make us especially well suited for supporting these trends.

Compliance as Code

Compliance as Code is the idea that requirements for auditing and compliance teams can be collected with zero additional cognitive load from developers and other team members participating in software delivery. Because GitLab has an end-to-end view of the artifacts that are associated with releases (issues, merge requests, feature flags, and so on) we are uniquely positioned to provide a comprehensive view of compliance-related activity, collected on an ongoing basis throughout the build, test, and release process. Our vision here can be found in our strategy page for Release Evidence.

Infrastructure as Code

IAC provides DevOps teams with a method to maintain consistency with the infrastructure their applications run on. The best practices defined in IAC prevent configuration drift, and allow teams to maintain consistent performance and security characteristics without the need for ongoing manual intervention.

IAC was made possible by the availability of rapidly deployed cloud infrastructure (IaaS platforms), and the corresponding buildup of tools to enable generic usage and consistent deployment to that infrastructure (Container Management Platforms).

With our roots as a source code management system, we will build on our existing workflows for code management, and extend our ability to define and manage infrastructure configuration in your project repositories so you can achieve reliability and consistency in your application.

Observability and Operations as Code

Observability is a measure of your application which defines how well you can understand the state of your production system from its external outputs. The more observable your application is, the more reliably you can operate it, both manually and through automation. Our vision is to allow you to define your observability and operational automation in code, alongside your application code. Whether that is the configuration of dashboards, metrics, alerts, runbooks, automation scripts or incident issues - GitLab will source-control those configurations and ensure they are reliably deployed to your production systems.

Progressive Delivery

Progressive Delivery is a set of emerging CD best practices, oriented around being able to control and monitor deployments incrementally over time, and in an automated and safe way. It takes Continuous Delivery to the next level by providing more options around how and when different users get access to your new features, making software delivery a continuous activity, rather than frequent but punctuated moments in time.

Additional articles on Progressive Delivery can be found on the LaunchDarkly blog, RedMonk and The New Stack, as well as our own blog posts highlighting Feature Flags and Review Apps.

Smart Feedback Loop

Defining your infrastructure, observability, and operations as code is just the first step. The real magic happens when you rapidly iterate on those definitions. As a single-application for the entire DevOps lifecycle GitLab completes what is commonly a major gap in the DevOps loop - the feedback from ops back into planning.

Our vision is to provide not just an easy ability to identify, suggest, complete, and deploy changes to your production system, but also enable new insights that other tools can't. During incident response, GitLab can quickly identify the last deployed commit, lines of code changed, and author to guide the response to the right place. During deployment, GitLab can quickly tell you if your production system is already out-of-bounds from defined service-level indicator (SLI) metrics and roll back. During post-mortems, GitLab can suggest runbook or alert changes. We are very excited about enabling DevSecOps teams with these smart additions.

Operations for All

Truly integrated DevOps teams are difficult to create. While large organizations have the budget to staff dedicated teams with roles like "Cost Optimization Engineer" and "Site Reliability Engineer" smaller teams require "Jack of All Trades" engineers.

Our vision at GitLab is that everyone can contribute, and that small teams, without specialization, can leverage and adopt the same tools as those in larger organizations. By building on our preference for convention over configuration, we can take the guess work out of operations. We will enable you and your team to quickly build a production application and iterate on it. We'll make it easy for teams to start from modern operations practices where you avoid alert fatigue by detecting real user events and are able to resolve like a pro. Not just on its features, but on the overall experience delivered to your users. Rapidly.

User Adoption Journey

Like our product-wide adoption journey, we've also defined a user adoption journey between the Ops section stages.

graph LR %% Define Styling classDef OpsStage fill:#11f,color:#fff classDef OtherStage fill:#ddd,color:#888 %%% Define Stages P[Plan]:::OtherStage C[Create]:::OtherStage V[Verify]:::OpsStage Pa[Package]:::OpsStage R[Release]:::OpsStage Co[Configure]:::OpsStage M[Monitor]:::OpsStage S[Secure]:::OtherStage D[Defend]:::OtherStage %% Define Connections C -.- P P --> M V -.- S C==> V V==> R V==> Pa V --> Co R==> M R==> Co Co -.- D Co==> M M -.- D subgraph "Legend" Legend1[Ops Stage]:::OpsStage == Critical Path==> Legend2[Other Stage]:::OtherStage Legend1 -. Additional Path .-> Legend2 end

Performance Indicators

The Ops Section tracks our Product Performance Indicators in our Ops Section Product Performance Indicators page. Our section wide Performance Indicator is Total Section Stages Monthly Active Users (Total Section SMAU). Just like our broad-based product metric of SMAU, total Total Section SMAU measures user-based adoption of the various stages at GitLab.

Given that, we are heavily focused on enabling CI usage from existing SCM customers and CD usage from existing CI customers - thus activating users into our section SMAU and enabling them to continue on our user adoption journey to other Ops Section stages.

The majority of our Ops Section product groups are focused on driving adoption first, and then monetization within their category scope. Some groups are well placed to focus on adding tier value for buyer-based personas on top of existing stages which already have heavy usage. Those groups will adopt Stage Monthly Active Paid Users (SMAPU) as their North Star Metric. In the Ops section those groups are:

Critical Jobs to Be Done

GitLab will focus on the jobs to be done (JTBD) found in the workflows identified across all of our stages. Today we've identified those critical JTBD in the Package, Release Management, Configure and Monitor stages.

The most critical are:

Who is it for?

We identify the personas the Ops section features are built for. In order to be transparent about personas we support today and personas we aim to support in the future we use the following categorization of personas listed in priority order.

Today

To capitalize on the opportunities listed above, the Ops section has features that make it useful to the following personas today.

  1. 🟩 Sasha - Software Developer
  2. 🟩 Devon - DevOps Engineer
  3. 🟨 Rachel - Release Manager
  4. 🟨 Simone - Software Engineer in Test
  5. 🟨 Allison - Application Ops
  6. 🟨 Delaney - Devleopment Team Lead
  7. 🟨 Priyanka - Platform Engineer
  8. ⬜️ Ops Teams
  9. ⬜️ Central IT / System Admins

Medium Term (1-2 years)

As we execute our 3-year strategy, our medium term (1-2 year) goal is to provide a single application that enables collaboration between cloud native development and platform teams.

  1. 🟩 Sasha - Software Developer
  2. 🟩 Devon - DevOps Engineer
  3. 🟩 Allison - Application Ops
  4. 🟩 Simone - Software Engineer in Test
  5. 🟩 Rachel - Release Manager
  6. 🟩 Delaney - Devleopment Team Lead
  7. 🟩 Priyanka - Platform Engineer
  8. 🟨 Ops Teams
  9. ⬜️ Central IT / System Admins

One Year Plans

Ops Section Plan

Our plan is quite simple. We see a common progression in all of our GitLab stages and categories. That progression is:

  1. Create MVCs
  2. Leverage the high rate of learning provided by dogfooding to achieve viability
  3. Shift focus to awareness and aquisition of viable capabilities increasing SMAU
  4. Begin building completeness and tier value as a result of increased SMAU

As a result our performance indicators and tier strategies are aligned to the maturity of each stage.

In doing so, over the next 12 months we will choose NOT to:

Acquisition Plan

GitLab pursues acquisitions which will help accelerate our product roadmap. There are a few categories across the Ops Section stages which have a higher appetite for acquisition. We look for one of two things:

  1. Planned future category maturity increments where the jump from minimal or viable to complete or lovable would nessecitate significant R&D investment and an acquisition would accelerate that maturity significantly.
  2. Filling gaps in our themes that span our current categories. As a result our top priorities are:

Top priorities:

  1. CI Testing - Tools that immediately increase our capability in a Verify:Testing group category AND provide a framework for an over-time and cross-project view of testing results.
  2. Cluster Cost Optimization - Tools that provide alerting and dashboarding for attached Kubernetes cluster cost optimization.
  3. Observability - Tools that immediately increase our capabilities in tracing and digital experience management. We are specifically focused on improving the out-of-the-box experience for instrumenting and setting up triage workflows of users' applications.

Additional options:

  1. Smart Feedback Loop - Tools that enable the continuous improvement of applications via efficient feedback loops from production to the Plan and Create stages, including product telemetry, user forums, suggestion mechanisms, and real-user monitoring.
    • Operations as Code - Tools and software that improve the ability to define observability systems and repeatedly deploy them alongside application code.
    • Operations for All - Tools that help developers quickly understand complex infrastructure setups, including service catalogs, cluster cost optimization, and observability interfaces.

Useful Resources

Below are some additional resources to learn more about Ops:

Stages and Categories

The Ops section is composed of five stages, each of which contains several categories. Each stage has an overall strategy statement below, aligned to the themes for Ops. Each category within each stage has a dedicated vision page plus optional documentation, marketing pages, and other materials linked below.

Verify

The three year goals of the Verify group (high-level roadmap; SMAU (Stage Monthly Active Users) dashboard) are:

  1. Getting to the first green build for a new project setup is a key metric for CI authoring. We want to make it as easy as possible to set up your .gitlab-ci.yml including the ability to find and utilize organization-wide recipes to create your CI pipelines.
  2. Be the tool of choice for groups that want to reduce their lead time for changes to under an hour. Part of how we will achieve this is by taking CI/CD analytics to the next level.
  3. Provide automated setup, configuration and management of Runners for self-managed.
  4. Make ML/AI workflows easier, including features like adding the ability to install industry leading applications like Kubeflow to your Kubernetes clusters.

Verify Stage Categories

継続的インテグレーション（CI）

各コミット毎の自動化されたビルド、テスト、セキュリティテストにより、驚異的なスピードで大規模なスケールのデリバリーを自信を持って行うことができます。 This category is at the "lovable" level of maturity.

Learn more • Documentation • Direction

GitLab Runner

GitLab Runnerは、CIジョブを実行して結果をGitLabに送り返すための実行エージェントです。 This category is at the "lovable" level of maturity.

Documentation • Direction

Jenkinsインポート

Jenkinsインポートは、チームがGitLab CIに移行する際の障害を取り除くのに役立ちます。 This category is at the "minimal" level of maturity.

Direction

コード品質

ソースコードを自動的に分析して問題を表面化させ、最新のコミットで品質が向上しているか、または悪化していないかを確認できます。 This category is at the "viable" level of maturity.

Documentation • Direction

コードテストとカバレッジ

コードテストとカバレッジは、パイプライン内でビルドされた個々のコンポーネントが期待通りに動作することを保証するものであり、継続的インテグレーションの重要な部分です。 This category is at the "viable" level of maturity.

Documentation • Direction

負荷テスト

実世界の負荷シナリオを使用して検証することで、変更がパフォーマンスに与える影響に自信を持つことができます。 This category is at the "minimal" level of maturity.

Documentation • Direction

ウェブパフォーマンス

自動化されたウェブパフォーマンステストを使用して、ブラウザでのソフトウェアのパフォーマンスを保証します。 This category is at the "viable" level of maturity.

Documentation • Direction

ユーザビリティテスト

ユーザーにとって、ユーザビリティが実際に理解可能で価値のあるものであることをテストします。 This category is at the "viable" level of maturity.

Documentation • Direction

アクセシビリティテスト

アクセシビリティテストはコンプライアンス要件であるだけでなく、多くの場合、行うべき正しいことです。 This category is at the "viable" level of maturity.

Documentation • Direction

マージトレイン

開発のコラボレーションの安定性を確保するために、masterブランチのテストをグリーンに保つことは非常に重要です。 これを達成するための重要な方法として、GitLabはマージトレインを導入しました。 This category is at the "viable" level of maturity.

Documentation • Direction

Pricing

The Verify group is at the entrypoint to the funnel in our user adoption journey, so our features are an critical enabler for users seeking a complete DevOps platform. While we do try to drive adoption in order to support multi-stage growth at least partially through features at the free tier, it's also important for us that we have features at the paid tiers. For our group, these will typically be cross-department and cross-company views related to CI templates, quality and pipelines. See below for the how we are thinking about each of the tiers, and the kinds of features that will be included.

Core/Free

The foundation of the Core/Free strategy for Verify is that enhancements to baseline CI YAML features will be available in this tier by default. The rationale for this approach is that we want to preserve a consistent experience. Users must always be able to use the same .gitlab-ci.yml in all tiers.

Beyond this, features that drive broad adoption and help with onboarding (including generally making it easier to get started with GitLab CI) are also good candidates for inclusion in this tier. Providing solutions to simplify the deployment and management of Runners at scale for self-managed is also critical for all tiers of users.

Starter/Bronze

Our plan for features in this tier is to appeal to managers of small teams. These features will be targeted at the team lead who is managing the team's workload, for example looking at trends in how code coverage and quality data is evolving over time, and who wants to encourage collaboration in the team by using features like Visual Review Tools. Additionally, we will invest in paid dashboards that tie together various stages that connect with CI, adding value more than the sum of the whole. One example of the latter is running automated tests as part of the release to enable smarter rollback control.

You can see features that we are considering including in this tier in this issue search.

Premium/Silver

The default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We will focus on features that solve for typical entry-level enterprise needs: reporting and analytics, operational efficiency, and other needs that are must-haves for medium to large organizations.

You can see features that we are considering including in this tier in this issue search.

Ultimate/Gold

There is an opportunity to support inner-sourcing/collaboration for CI in this top tier since it's only if you are utilizing CI across thousands of projects that those types of capabilities are warranted. This would be exemplified by issues like gitlab#24939.

You can see features that we are considering including in this tier in this issue search.

Package

The three year goals of the Package group (high-level roadmap; SMAU (Stage Monthly Active Users) dashboard are:

  1. Build a product, that within three years, is your single source of truth for storing and distributing images and packages.
  2. Unify the Container Registry and the Package Registry to create a seamless user experience for building, testing and releasing code. We will achieve this by expanding the Dependency Proxy to allow you to create remote and virtual registries. This will allow you to easily publish and install packages and images using a single, logical URL and reduce friction when consuming external packages.
  3. Build integration points and documentation to enable our customers and the GitLab Community to more easily contribute. This is the only and best way to achieve adding support for all of the most common package manager formats in a timely manner.
  4. Improve the performance and reliability of builds by reducing reliance on external dependencies.

The details of how we'll achieve different elements of this can be found in the individual category pages below:

Package Stage Categories

パッケージレジストリ

すべてのチームは、パッケージや依存関係を保存する場所を必要としています。 GitLabは、一般的に使用されているすべての言語やバイナリ形式のパッケージ管理をサポートすることを目指しています。 This category is at the "complete" level of maturity.

Documentation • Direction

コンテナレジストリ

GitLabに組み込まれたDockerイメージ用のセキュアでプライベートなレジストリです。GitLab CI/CDで、イメージの作成、プッシュ、取得をすぐに行えます。 This category is at the "complete" level of maturity.

Documentation • Direction

Helm Chartレジストリ

Kubernetesクラスターインテグレーションでは、Helm Chartを利用して配布とインストールプロセスを標準化できます。 ビルトインのHelm Chartレジストリをサポートすることで、 より優れたセルフマネージド型のコンテナオーケストレーションが可能になります。 This category is at the "viable" level of maturity.

Documentation • Direction

依存関係プロキシ

GitLabの依存関係プロキシは、開発者や自動化で使用するCIが、 リモートリポジトリから必要なパッケージを取得する際の仲介役として機能します。 キャッシュやセキュリティの検証のレイヤーを追加することで、 依存しているパッケージの信頼性、正確性、監査可能性を 確保することができます。 This category is at the "complete" level of maturity.

Documentation • Direction

依存関係ファイアウォール

GitLabは、パッケージレジストリに保存されている依存関係が企業のコンプライアンスガイドラインに準拠していることを保証します。つまり、安全でない依存関係やポリシーから外れた依存関係の使用を防ぐことができます。 This category is at the "minimal" level of maturity.

Direction

Jupyter Notebook

Jupyter Notebookはデータサイエンスのユースケースでよく使われるツールです。GitLabを使えば、パッケージやアプリケーションコードを保存するのと同じように、 これらのノートブックを保存したりバージョン管理したりできます。 This category is at the "viable" level of maturity.

Documentation • Direction

Git LFS

Git LFS（Large File Storage）はGitの拡張機能で、リポジトリ内の巨大なファイルを遅延ダウンロードすることでその影響を軽減します。 具体的には、巨大なファイルはクローンやフェッチ中ではなく、チェックアウト中にダウンロードされます。 This category is at the "viable" level of maturity.

Documentation • Direction

Pricing

Our goal is to ensure that any organization can rely solely on GitLab as a universal package manager. Our pricing strategy and product strategy are closely correlated to the size of a given organization. That is because as team size increases, so does the complexity in managing how packages are shared, consumed, and distributed.

Core/Free

We will continue to invest in our Package and Container registries to ensure that anyone can use their GitLab project as their default registry, leverage GitLab's many authentication options and easily publish/share packages. We will focus our efforts on a few key areas.

We must make the use of our Core offering frictionless. To do this we'll focus on usability, reliability, and seamless integrations with GitLab continuous integration and delivery. We will ensure that our product is easy and rewarding to contribute to. We will continue to rely on the GitLab Community to help define and refine our product offering. This includes adding support for new package manager formats.

Roadmap features targeted for tier:

Starter/Bronze

This tier will be a minor investment in the pricing strategy. Features in this tier appeal to managers of small teams and we are strategically focusing on by positioning capabilities into this tier that help with team management and collaboration. Cross-project release managers and distributed teams will typically be in the tier above and will benefit from project-level capabilities we will introduce. Roadmap features targeted for tier:

Premium/Silver

The default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We'll direct features that solve for typical entry-level enterprise needs: reporting and analytics, operational efficiency, deployment automation, security and compliance, and other needs that are must-haves for medium to large organizations. While this type of organization should be able to get started in GitLab at lower tiers, they won't be able to thrive at scale. Roadmap features targeted for tier:

Ultimate/Gold

Directed toward an executive likely buyer, we will focus our efforts here on serving the needs of our larger, enterprise customers. This means introducing features that help to drive compliance and shift security left into development pipelines. Roadmap features targeted for tier:

Release

The three year target for Release (high level roadmap; SMAU (Stage Monthly Active Users) dashboard) is:

The details of how we'll achieve different elements of this can be found in the individual category pages below:

Release Stage Categories

継続的デリバリー

GitLab CDを使用して本番環境へのデリバリーを自動化することによって、優れたソフトウェアの開発に集中できます。 This category is at the "lovable" level of maturity.

Learn more • Documentation • Direction

Pages

任意の静的サイトジェネレーターを使用して、GitLabで簡単に管理・デプロイできるWebサイトを作成できます。 This category is at the "complete" level of maturity.

Learn more • Documentation • Direction

レビューアプリ

マージリクエストに対して、コミットごとに更新される動作確認用の環境を提供します。マージ前に動作中のコードを確認でき、ユーザーの受け入れテストを可能にします。 This category is at the "complete" level of maturity.

Learn more • Documentation • Direction

高度なデプロイ

新しいコードをクラスターの小さなサブセットにデプロイし、徐々に適用範囲を増やしていくことで、プロダクションへのデプロイのリスクを軽減できます。 This category is at the "complete" level of maturity.

Documentation • Direction

フィーチャーフラグ

フィーチャーフラグを使用することで、検証が必要な機能をより小さなバッチとして本番環境にデプロイできます。これによって、機能のデリバリーと顧客へのリリースを分離し、デリバリーのリスクを軽減することができます。これは、CDを実施するのに役立ちます。 This category is at the "viable" level of maturity.

Documentation • Direction

リリースオーケストレーション

インテリジェントな通知、デリバリーと共有リソースのスケジューリング、ブラックアウト期間、リレーションシップ、並列化、シーケンスに基づいて構築されたRelease as Codeの管理とオーケストレーション、および手動プロセスのインテグレーションのサポートします。 This category is at the "complete" level of maturity.

Documentation • Direction

リリースエビデンス

リリースエビデンスには、信頼できるコンテナイメージのみがKubernetesエンジン上にデプロイされるようにするデプロイ時のセキュリティ制御などの機能が含まれています。さらに、デリバリーする変更の信頼性を担保するのに必要な、より広範なエビデンスを収集できます。 This category is at the "lovable" level of maturity.

Documentation • Direction

シークレット管理

HashiCorp VaultとGitLabを使ってGitLabのシークレットを管理できます。 This category is at the "lovable" level of maturity.

Documentation • Direction

Pricing

To support our goals in 2020 and our 3-year strategy, Release will continue enriching the free features while adding tier value. In our adoption journey, the Release features are typically consumed after continuous integration and source code management, so we will work to expand the independent use of continuous delivery features. While investing in the reduction of barrier to entry into Release we will spend time meeting the needs of the Enterprise by adding visibility into the benefits of using GitLab end-to-end.

Core/Free

Release will continue investing in the free solution to reduce the barrier of entry into Release as both as part of additional Gitlab adoption from existing CI users and as an independent solution without needing to use CI or SCM. We will focus on simplifying the process of managing releases and deploying progressively while empowering developers to release independently using GitLab. Roadmap features targeted for this tier include:

Starter/Bronze

This tier will be a minor investment in our pricing strategy. Features in this tier appeal to managers of small teams. We strategically focus on adding capabilities into this tier which help with team management and collaboration. Experiences for cross-project release managers and distributed teams will typically be in higher tiers which benefit from project-level capabilities we will introduce. Roadmap features targeted for this tier include:

Premium/Silver

As the default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We'll direct features that solve for typical entry-level enterprise needs: reporting and analytics, operational efficiency, deployment automation, security and compliance, and other needs that are must-haves for medium to large organizations. While this type of organization should be able to get started in GitLab at lower tiers, they won't be able to thrive at scale. Roadmap features targeted for this tier include:

Ultimate/Gold

This tier is directed toward an executive likely buyer. Release groups will direct capabilities into Ultimate/Gold which serve the organizational needs of a complex enterprise operating a large GitLab instance. We'll focus on features which will help drive compliance into the continuous delivery workflow and shift security left into the development pipelines. Roadmap features targeted for this tier include:

Configure

While the market for the Configure stage has many strong incumbent players, it is splintered across many traditional IT management tools (Ansible, Chef, Puppet). There are emerging trends (i) showing a consolidation on containers (i) and specifically Kubernetes (i) for cloud-native application development. This will have the effect of stymying commercial players from locking in market share based on proprietary tools. So while there are strong players, the current market dynamics means there is upside for us.

You can read more about the Configure stage plan on the Configure Direction page.

The Configure stage is made up of several categories:

Configure Stage Categories

Auto DevOps

コードをコミットすると、あとはGitLabがビルド、テスト、デプロイ、監視を自動的に行います。パイプラインと必要なインテグレーションを自動的に設定することで、ソフトウェアの自動デリバリーを開始する際の煩雑さを解消し、チームは開発に集中できるようになります。 This category is at the "lovable" level of maturity.

Priority: medium • Learn more • Documentation • Direction

Kubernetes管理

数回のクリックでKubernetesクラスターを作成して管理できます。また、ワンクリックでクラスターにアプリケーションをインストールできます。 This category is at the "lovable" level of maturity.

Priority: high • Learn more • Documentation • Direction

ChatOps

SlackやMattermostとの緊密なインテグレーションにより、チャットアプリケーションからソフトウェアの開発やデリバリーの自動化を容易に管理できます。 This category is at the "minimal" level of maturity.

Priority: low • Documentation • Direction

ランブック

ランブックは、特定のシステムの起動、停止、デバッグ、トラブルシューティングなど、特定のプロセスの実行方法を説明する手順書です。実行可能なランブックは、事前に記述されたコードブロックやデータベースクエリを、運用者が特定の環境に対して実行することを可能にします。 This category is at the "complete" level of maturity.

Priority: low • Documentation • Direction

サーバーレス

GitLab CI/CDを使用して、デプロイクラウドに依存しないサーバーレスワークロードをKubernetes上にデプロイをして実行できます。 This category is at the "complete" level of maturity.

Priority: low • Learn more • Documentation • Direction

Infrastructure as Code

完全なソフトウェア開発環境を作成、構成、管理するためのインフラを効果的に管理できます。 This category is at the "complete" level of maturity.

Priority: high • Documentation • Direction

クラスターコストの最適化

This category is at the "complete" level of maturity.
Priority: low • Direction

Pricing

TBD

Monitor

The market for the Monitor stage is aligned around key players New Relic, Splunk, ServiceNow and Datadog. Datadog, New Relic and Splunk are all headed towards integrated observability platforms based on collecting all available telemetry. ServiceNow (i) is considered a standard for help-desk and Incident Management workflows. Strong existing players with large sustained R&D investment will make it difficult for GitLab to compete head-to-head for Monitor stage market share, especially with traditional Operations and System Administration users.

You can read more about the Monitor stage plan on the Monitor Direction page.

The Monitor stage is made up of several categories:

Monitor Stage Categories

メトリクス

Prometheusを利用して、GitLabはデプロイしたアプリケーションのパフォーマンスメトリクスを収集し表示できます。開発者はマージが本番環境に与える影響を、GitLabから離れることなく、簡単に確認できます。 This category is at the "complete" level of maturity.

Priority: high • Documentation • Direction

アラート管理

GitLabでAPMアラートを設定して管理できます。 This category is at the "complete" level of maturity.

Priority: high • Documentation • Direction

インシデント管理

GitLabでインシデントを追跡できます。つまり、誰が、何を、いつ、どこで、どのようなインシデントが発生したのかを把握するための統合された場所を提供します。 開発速度と安定性の望ましいバランスを達成するために、サービスレベルの目標とエラーバジェットを定義できます。 This category is at the "complete" level of maturity.

Priority: high • Documentation • Direction

ロギング

GitLabでは、Elastic Stackによるログ集約を利用して、複数のポッドやサービスに分散したログを簡単に閲覧できます。Elastic Stackを有効にすると、集約されたKubernetesのログを複数のサービスやインフラにまたがって閲覧したり、過去にさかのぼったり、無限スクロールしたり、GitLabのUIからアプリケーションのログを検索したりできます。 This category is at the "complete" level of maturity.

Priority: medium • Documentation • Direction

トレーシング

トレーシングは、デプロイされたアプリケーションのパフォーマンスと健全性に関する考察を提供し、各機能や指定されたリクエストを処理するマイクロサービスを追跡します。これにより、モノリシックなシステムを使用しているか分散システムを使用しているかに関係なく、リクエストのエンドツーエンドのフローを簡単に理解できます。 This category is at the "complete" level of maturity.

Priority: medium • Documentation • Direction

GitLabのセルフモニタリング

セルフマネージド型のGitLabインスタンスは、優れた観測ツールを備えており、GitLabインスタンスを維持するために必要な時間と労力を削減できます。

Priority: low • Documentation • Direction

エラートラッキング

エラートラッキングにより、開発者はアプリケーションで発生している可能性のあるエラーを簡単に発見し、確認することができます。コードの開発箇所とエラー情報を明らかにすることで、効率性と認識度を高めることができます。 This category is at the "complete" level of maturity.

Priority: low • Documentation • Direction

製品分析

This category is at the "minimal" level of maturity.
Priority: medium • Direction

合成モニタリング

ユーザーアクションと行動経路の成功率と実行のシミュレーション、監視、レポートを積極的に行います。 This category is at the "minimal" level of maturity.

Priority: high • Direction

Pricing

TBD

What's Next

It's important to call out that the below plan can change any moment and should not be taken as a hard commitment, though we do try to keep things generally stable. In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.

15.11 (2023-04-22)

Verify

Package

Monitor

16.0 (2023-05-22)

Verify

16.1 (2023-06-22)

Verify

Package

このページを編集 — 貢献をお願いします Creative Commons License
このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。