Commit 1d2e0645 authored by Jason Lenny's avatar Jason Lenny 📧

Update source/direction/cicd/themes/_universal_package_management.html.md.erb,...

Update source/direction/cicd/themes/_universal_package_management.html.md.erb, source/direction/cicd/themes/_speedy_pipelines.html.md.erb, source/direction/cicd/themes/_progressive_delivery.html.md.erb, source/direction/cicd/themes/_compliance_as_code.html.md.erb, source/direction/cicd/themes/_cool_things.html.md.erb, source/direction/cicd/themes/_event_based.html.md.erb, source/direction/cicd/themes/_integrated_solutions.html.md.erb, source/direction/cicd/themes/_mobile_support.html.md.erb, source/direction/cicd/themes/_multi_platform.html.md.erb, source/direction/cicd/themes/_gitops.html.md.erb, source/direction/cicd/template.html.md.erb, source/direction/package/template.html.md.erb files
parent cd64dcff
The goal of the Package group is to build a set of features that within three years, will allow ninety percent of our customers to store all of their packages and artifacts in GitLab. In order to accomplish this goal, we will expand the footprint of our existing product, build products that fully leverage the benefits of GitLab's [single application](https://about.gitlab.com/handbook/product/single-application/), and unify the container registry, build artifacts and the package registry to create a seamless, unified user experience for building, testing and releasing code.
We will first focus on [improving the usability of our existing registries](https://gitlab.com/groups/gitlab-org/-/epics/1241). By providing a consistent and delightful user experience across integrations, we will be able to quickly introduce new [package manager integrations](https://gitlab.com/groups/gitlab-org/-/epics/1245). Next, we will ensure that all Package features take advantage of GitLab's single application. We will simplify the lives of our users by [standardizing authentication and permissions](https://gitlab.com/groups/gitlab-org/-/epics/1243) for each of our package manager integrations. We will help our users by [creating visibility and transparency](https://gitlab.com/groups/gitlab-org/-/epics/1244) into their registries by providing meta data and evidence for how images/packages are built, by whom and when.
Then we will work to [improve the performance and reliability of builds](https://gitlab.com/groups/gitlab-org/-/epics/1850) by rolling out the [dependency proxy](https://docs.gitlab.com/ee/user/group/dependency_proxy/) to each package manager. Increased adoption of the dependency proxy will allow us to build new features that will help our customers to [reduce open source risk by providing visibility and transparency into external dependencies](https://gitlab.com/groups/gitlab-org/-/epics/1248).
Finally, we will increase adoption and conversational development by providing improved discovery and collaboration features, such as [search](https://gitlab.com/gitlab-org/gitlab-ee/issues/24078).
\ No newline at end of file
The traditional roles of software development teams are changing. The trend in the market is to build self-managed teams and we believe that more and more teams will adopt this change in the next three years. Gitlab sees the importance of giving these teams everything they need in order to perform their job without additional overhead. We have seen the traditional centralized Release Management role at companies change, becoming more of a shared responsibility that is distributed amongst several groups, and expect that to continue.
To support this transition we are bringing Release Management features into the product, such as release orchestration, runbooks for releases, management of blackout periods, environment scheduling, etc., but in a way where these features are integrated directly into the single application. Instead of having a Release Manager view a dashboard within the product, feature flag states are connected with the issues and merge requests that introduced them. Releases automatically collect evidence about what the state of issues, team members, test results, and so on were at the time of the automatically, and these are presented simply within the release view. This way of working serves both the teams writing the software and the teams delivering it, whether they are separated or not, and is a unique solution in the market compared to other point tools which provide solutions to Release Managers but do not really integrate well with the rest of the team.
In addition to the change in roles, the next natural step of SW delivery is progressive delivery. Once there is an automated CI/CD process in place, the next part of the journey is progressive delivery. Progressive delivery controls the deployment to a specific subset of users before being fully shipped, so that testing in production doesn’t have to be a massive risk. The idea is to get feedback, and fast. If something goes wrong, reverting is automatic and without any hassle. We believe that taking steps towards these directions is both natural and necessary in order to stay true to our customers and remain a unified tool for the entire DevOps lifecycle.
Users of Verify's CI solution can expect us to invest heavily in multi-platform support, making it just as easy to build on Windows and MacOS as it is to build on Linux today. In terms of pipeline capabilities, we've recently implemented [directed acyclic graphs](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/), a powerful primitive for complex dependency relationships, and we will expand on this with great features like [child/parent pipelines](https://gitlab.com/gitlab-org/gitlab-ce/issues/22972) and [cartesian products for jobs](https://gitlab.com/gitlab-org/gitlab-ce/issues/19199). The innovation never really stops here: there's always a way to provide a new, powerful command that can help organize your pipeline configuration in a simpler and more expressive way.
Beyond pipeline execution, we'll improve how we present and act on interesting data around what jobs do and how they perform; timing and efficiency information is one part, but so is how test results are changing over time. Our [epic for CI/CD analytics](https://gitlab.com/groups/gitlab-org/-/epics/358) captures some of the important metrics we've identified so far. This data then can be acted upon by GitLab itself to automatically tune your pipelines for better performance - imagine [automatically tuning parallelization of your test runs](https://gitlab.com/gitlab-org/gitlab-ee/issues/12282) - without users having to spend time thinking about it. Self-healing pipelines that automatically adapt to changes to maintain their efficiency will be a powerful tool for teams.
\ No newline at end of file
This diff is collapsed.
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
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 begins by improving our releases feature to start collecting evidence from the cycle leading up to the release event ([gitlab-ce#56030](https://gitlab.com/gitlab-org/gitlab-ce/issues/56030)).
In addition to collecting compliance evidence along the path to production, our plan is to improve the way GitLab pipelines interact with secure secrets, typically held in a Vault or other secrets store. Our plan is to first allow GitLab to integrate with your existing Vault, implemented via [gitlab-ce#61053](https://gitlab.com/gitlab-org/gitlab-ce/issues/61053). In the future, however, we have a broader vision for bundling Vault with GitLab and making secrets management a part of the GitLab product in general; this includes storing GitLab's own secrets in an external Vault.
Related Epics:
- [Evidence collection for Releases MVC](https://gitlab.com/groups/gitlab-org/-/epics/1856)
- [Reduce open source risk by providing visibility into external dependencies](https://gitlab.com/groups/gitlab-org/-/epics/1248) (Package)
- [Lock down the path to production](https://gitlab.com/groups/gitlab-org/-/epics/762) (Verify & Release)
- [Variables and secrets management in GitLab CI/CD](https://gitlab.com/groups/gitlab-org/-/epics/816) (Verify & Release)
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
One of the core principles of GitLab CI/CD is the idea that we want to give people powerful tools to do their job; flexibility is key, and we want to ensure that getting complex things done with small, easy-to-use, but powerful primitives is the GitLab way. This also helps us remain flexible and avoid hewing too closely to a specific technology solution, ensuring we continue to diverse and sometimes legacy technology stacks, and retain our flexibility to embrace future innovation. Put simply, we will always prioritize powerful building blocks in GitLab that are exposed to you, the user. Where we have structures to get started quickly with a given stack, those will be built up from the same primitives that you have access to as well.
An interesting measure for this is how long it takes to get to your first green build from the time you create your project, for both new and seasoned pipeline users. We are going to start tracking this as a success metric for how easy it is to get in and get your work done; GitLab's built-in functionality should make this quick and easy.
Related Epics:
- [Natively support hypercloud deployments](https://gitlab.com/groups/gitlab-org/-/epics/1804) (Release)
- [Make environments easier to use and manage](https://gitlab.com/groups/gitlab-org/-/epics/767) (Release)
- [Make CD more reliable and require less interaction](https://gitlab.com/groups/gitlab-org/-/epics/770) (Release)
- [Improve certificate handling for Pages](https://gitlab.com/groups/gitlab-org/-/epics/766) (Release)
- [Integrated Load Testing MVC](https://gitlab.com/groups/gitlab-org/-/epics/952) (Verify)
- [Interactive editing of .gitlab-ci.yml](https://gitlab.com/groups/gitlab-org/-/epics/157) (Verify)
- [Make code coverage more comprehensive](https://gitlab.com/groups/gitlab-org/-/epics/100) (Verify)
- [Make CI lovable for monorepos](https://gitlab.com/groups/gitlab-org/-/epics/812) (Verify)
- [CI/CD reporting improvements](https://gitlab.com/groups/gitlab-org/-/epics/358) (Verify & Release)
\ No newline at end of file
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
We've seen GitHub actions v2 come out with a more event-based model for building up CI/CD pipelines. Distributed, event-based systems in general can be very powerful, but as complexity scales they tend to add to the complexity rather than help you solve it. We believe that to a large extent, building and maintaining a CI/CD platform should be and exercise in minimizing complexity rather than embracing it. There's nothing that says CI/CD has to be hard, and we believe our vision for powerful, small primitives will scale better and result in happier, more productive teams in the long term.
That said, in certain simple cases (and especially when it comes to getting up to speed quickly) things like webhooks can be a powerful tool. We don't believe these should be avoided at all costs, we just don't believe that these are a stable foundation to build a delivery platform on top of and have no plans to build an event-based model for GitLab CI/CD in the next twelve months.
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
DevOps tooling is heading towards consolidation simply because users prefer well-integrated solutions that don't require administration effort to keep everything wired together in order to realize the benefits of having all the information you need in one place. Point application solutions like TravisCI and CircleCI are struggling under this paradigm because they suffer from the fundamental problem that CI/CD is not an island. In order to make sure their solutions can compete effectively they are forced to maintain integrations with various stacks, which is expensive in terms of focus and results that they are unable to innovate as fast as competitors that are providing a unified solution.
Ultimately, our single application solution is what will help us ensure that GitLab is a [Robot Cat instead of a Sheepdog](https://thenewstack.io/todays-ci-cd-from-fat-sheepdogs-to-robot-cats/). By embedding CI/CD naturally into everyone's workflows, as a first-class part of working with issues, source control, merge requests, etc., CI/CD isn't a box under someone's desk that nobody knows how to work while on vacation; it's a part of how everyone works together - the glue that binds everyone around how they deliver software together as a team.
Related Epics:
- [Make GitLab CI/CD work better with external repositories](https://gitlab.com/groups/gitlab-org/-/epics/943)
- [Standardize authentication and permissions for the GitLab Registry](https://gitlab.com/groups/gitlab-org/-/epics/1243)
- [Create visibility and transparency for the GitLab Package and Container Registry](https://gitlab.com/groups/gitlab-org/-/epics/1244)
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
Mobile is an important segment of the market - many consumer brands, even those that would be considered non-tech are now development and distributing mobile apps as part of their customer engagement strategies. It's important for GitLab that we support these customers to be successful in this area. To see an example of where we're headed and the kinds of easy-to-use delivery flows we have in mind, we have a [video](https://www.youtube.com/watch?v=325FyJt7ZG8) where we demonstrate (using GitLab today) making a change to a mobile app using an iPad Pro, sending the build over to a MacOS runner, and receive a working copy back to test on the very same device using TestFlight. Part of supporting Mobile builds also includes our vision for better multi-platform support, making shared runners available for MacOS in particular will allow for easier iOS builds on GitLab.
More information on how we plan to support mobile CI/CD can be found on our [mobile use case](/direction/mobile) page.
Related Epics:
- [Improve mobile CI/CD in GitLab](https://gitlab.com/groups/gitlab-org/-/epics/769) (Verify & Release)
- [Mac Shared Runners MVC](https://gitlab.com/groups/gitlab-org/-/epics/1830) (Verify)
\ No newline at end of file
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
GitLab has traditionally done very well with building and deploying software on Linux, with our shared runner fleet making it very easy to get up and running quickly. We've supported MacOS and Windows Runners, but only in a bring-your-own configuration where you host and register your own Runners. Our top priority is changing that by improving Runner features for these platforms in addition to providing them as available options in the shared runner fleet.
Just being able to run builds on the platform isn't sufficient, though. We also want to improve our support for unit testing and code coverage frameworks used on these operating systems, as well as our support for different package managers that are used by code build there.
Related Epics:
- [Mac Shared Runners MVC](https://gitlab.com/groups/gitlab-org/-/epics/1830) (Verify)
- [Windows Shared Runners MVC](https://gitlab.com/groups/gitlab-org/-/epics/1768) (Verify)
\ No newline at end of file
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
Put simply, 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.
Progressive delivery controls the deployment to a specific subset of users before being
fully shipped, so that testing in production doesn’t have to be a massive risk. The idea is
to get feedback, and fast. Similarly to Compliance as Code, our single application is
uniquely capable of providing an integrated solution in this space by using feature flags, incremental
rollout and other traffic routing methods that can be controlled directly on the deployment pipeline.
You can control which users and what features can be accessed in addition to where and when,
giving you ultimate control of your production environments and given you the ability to make
quick decisions when it matters.
Additional articles on Progressive Delivery can be found on the [LaunchDarkly blog](https://launchdarkly.com/blog/progressive-delivery-a-history-condensed/), [RedMonk](https://redmonk.com/jgovernor/2018/08/06/towards-progressive-delivery/) and [The New Stack](https://thenewstack.io/the-rise-of-progressive-delivery-for-systems-resilience/), as well as our own blog posts highlighting [Feature Flags](/2019/08/06/feature-flags-continuous-delivery/) and [Review Apps](/2019/04/19/progressive-delivery-using-review-apps/).
Delivering software to your environments automatically is the first step, and modern technologies like Kubernetes are now allowing on-demand environments to be created like never before. By tying your source repo to intelligent infrastructure that understands the intentions of developers, you can enable a true one-click workflow to deliver to your internal or external end users.
Related Epics:
- [Progressive Delivery MVC](https://gitlab.com/groups/gitlab-org/-/epics/1198) (Release)
- [A/B/n testing using Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/712) (Release)
- [Visual Review Tool MVC](https://gitlab.com/groups/gitlab-org/-/epics/960) (Verify)
\ No newline at end of file
One proposed aspect of GitOps, apart from keeping Git as the source of truth and doing operations by Merge Request which we have embraced, is inverting the deployment model to be from push (where jobs execute and _push_ changes to an environment, which can then be monitored for divergence) to pull (where the environment itself runs an operator that monitors Git and itself, ensuring that everything stays in sync.) There are potential control benefits here, in that the CI/CD system does not need to maintain access to the target environment, but the reality is is that the CI/CD system will continue to be able to influence the environment in various ways by changing state in Git. Additionally, bringing the state change automation inside the cluster brings benefits to observability by seeing the environment and the state change in a single place.
For us, the benefits here are less clear than the core GitOps principles of everything-as-code, everything in Git, and change via Merge Request. We'll continue to monitor how this area evolves, and potentially change course as more innovation or clear benefits to this aspect are realized, but in the meantime we are not investing in this area.
\ No newline at end of file
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
At the core, GitLab CI/CD was built from the ground up with speed and scalability in mind. This is reflected both in the product design and product vision ([automated testing, testing all the things](/2018/02/05/test-all-the-things-gitlab-ci-docker-examples/)) 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](https://xkcd.com/303/) isn't fun, but we do want people to be able to contribute at the speed of development.
Time to First Byte is the first measure we're improving, which is the time it takes to set up the execution agent for every job, before the first line of your script is run. This can be fetching the image, provisioning a host, running internal setup, polling from the runner, and so on. All of these add delays to every job, but do not contribute to actually doing the important thing that needs to be done. To track and understand how we measure this, see the [time to first byte child epic](https://gitlab.com/groups/gitlab-org/-/epics/830). This also includes elements of improving the way the fleet of shared runners works, such as re-enabling registry mirroring ([infrastructure#3158(https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/3158)), and doing things like [pre-creating the runner environment for upcoming jobs](https://gitlab.com/gitlab-org/gitlab-ee/issues/8813)
[Wall clock time](https://en.wikipedia.org/wiki/Elapsed_real_time) for a pipeline is also an interesting measure. This is the one you really feel - when you make a commit and a pipeline starts, and you need to go have lunch before you see the result, you're really suffering. Our vision here is to have GitLab help you identify the bottlenecks in your pipelines and ideally remediate them automatically, but at least make it visibile where the bottlenecks are so you can investigate. Issues like our [auto-determining the test parallelization factor](https://gitlab.com/gitlab-org/gitlab-ee/issues/12282) represent how we want GitLab CI/CD to automatically find and solve these problems for you, and our [dependency proxy](https://about.gitlab.com/direction/package/dependency_proxy) is part of how we're building speed into the workflow itself.
Related Epics:
- [CI/CD Reporting & Analytics improvements](https://gitlab.com/groups/gitlab-org/-/epics/358) (Verify & Release)
- [Cross-project pipeline triggering & visualization](https://gitlab.com/groups/gitlab-org/-/epics/414) (Verify & Release)
- [Better management of stability in master](https://gitlab.com/groups/gitlab-org/-/epics/101) (Release)
- [More efficient pipeline execution](https://gitlab.com/groups/gitlab-org/-/epics/439) (Verify)
- [Improve speed of CI pipeline execution](https://gitlab.com/groups/gitlab-org/-/epics/296) (Verify)
- [Load/performance testing and impact of merge request](https://gitlab.com/groups/gitlab-org/-/epics/118) (Verify)
- [Shared workspaces for CI/CD jobs](https://gitlab.com/groups/gitlab-org/-/epics/1418) (Verify)
- [Define and record Verify time to first byte](https://gitlab.com/groups/gitlab-org/-/epics/830) (Verify)
- [Improve performance and reliability of the GitLab Registry](https://gitlab.com/groups/gitlab-org/-/epics/1850) (Package)
\ No newline at end of file
<!-- Introduce theme, stages, and categories it applies to and reference liberally. Highlight
important features, epics and issues from that theme specifically. Concentrate not on what we will do
but also what we won't do over the next 12 months. Themes should include concrete items what we're not going to do.
Themes need to reference very specific deliverables rather than being abstract concepts. -->
Developers rely on a variety of language-specific package manager clients to access, build and publish packages. Our vision is to provide a universal package manager, one that integrates with the most commonly used clients and makes them accessible in a single, shared location. Success is defined by our ability to not only support a wide variety of package manager clients, but to provide a consistent, delightful user experience with each integration. We currently support Maven, NPM and Docker. We will be adding support for C++ (Conan), .net (NuGet), Linux (Debian, RPM), and Helm charts (Kubernetes).
Most universal package managers in the market today work as point solutions that integrate with other services for source code management, continuous integration and deployment. This introduces risk for administrators who are forced to support multiple platforms and multiple authentication protocols. And it introduces inefficiencies for developers who face unnecassary context switching and increased complexity.
We believe that by building a universal package management system into GitLab, that we can help solve those problems on behalf of our users. It is critical that we continue to build a solution that leverages the benefits of GitLab's [single application](https://about.gitlab.com/handbook/product/single-application/). Beyond authentication and colocation, we will ensure that we utilize GitLab's data to help provide context, evidence and an optimized user experience as you build, test and deploy your code.
Related Epics:
- [Standardize authentication and permissions for the GitLab Registry](https://gitlab.com/groups/gitlab-org/-/epics/1243) (Package)
- [Lower the cost of the registry by improving storage management](https://gitlab.com/groups/gitlab-org/-/epics/434) (Package)
- [Create visibility and transparency for the GitLab Package and Container Registry](https://gitlab.com/groups/gitlab-org/-/epics/1244) (Package)
- [Expand our user base by supporting additional package managers](https://gitlab.com/groups/gitlab-org/-/epics/1245) (Package)
- [Improve the usability of the GitLab Package Registry](https://gitlab.com/groups/gitlab-org/-/epics/1241) (Package) (Package)
- [Improve the performance and reliability of the GitLab Registry](https://gitlab.com/groups/gitlab-org/-/epics/1850) (Package)
- [Reduce open source risk by providing visibility and transparency into external dependencies](https://gitlab.com/groups/gitlab-org/-/epics/1248) (Package)
......@@ -13,20 +13,6 @@ effective way is a competitive advantage that cannot be understated. GitLab is
taking improvements in this area seriously, with a unified vision across several
of our [DevOps stages](/direction/#devops-stages).
To see an example of where we're headed and the kinds of easy-to-use flows we
have in mind, check out
[this video](https://www.youtube.com/watch?v=325FyJt7ZG8) where we demonstrate
making a change to a mobile app using an iPad pro, send the build over to a
MacOS runner, and receive a working copy back to test on the very same device
using TestFlight. You can also see how to get up and running with Android builds
and publishing today in our
[recent blog post](/2019/01/28/android-publishing-with-gitlab-and-fastlane/)
(look for the iOS version coming shortly.)
Part of supporting Mobile builds includes our vision for better [multi-platform support](/direction/cicd/#theme-multi-platform-support),
making shared runners available for MacOS and Windows which will allow for mobile
builds that require these platforms to be easier to get up and running.
## North Stars
We apply our global product strategy to thinking about Mobile users. We treat the following
......
......@@ -3,6 +3,8 @@ layout: markdown_page
title: "Product Vision - Package"
---
{:.no_toc}
- TOC
{:toc}
......@@ -19,40 +21,32 @@ Feel free to reach out to PM Tim Rizzi ([E-Mail](mailto:trizzi@gitlab.com)) if y
- See an up-to-date [roadmap](https://gitlab.com/groups/gitlab-org/-/roadmap?scope=all&utf8=✓&state=opened&label_name[]=devops%3A%3Apackage)
- Stage usage can be tracked at the Package [SMAU (Stage Monthly Active Users) Dashboard](https://app.periscopedata.com/app/gitlab/491720/Package-Dashboard)
## North Stars
## Vision
<%= partial("direction/cicd/strategies/package") %>
## Themes
There are a few important north stars we are keeping sight of to guide us forward in this space. With each of these, we're focusing on complete (what we call minimally lovable) features.
We track epics for many of the major deliverables associated with these north stars,
you can view them on a calendar at [this link](https://gitlab.com/groups/gitlab-org/-/roadmap?label_name%5B%5D=devops%3A%3Apackage&scope=all&sort=end_date_asc&state=opened&layout=QUARTERS).
### Universal Package Management
Developers rely on a variety of language-specific package manager clients to access, build and publish packages. Our vision is to provide a universal package manager, one that integrates with the most commonly used clients and makes them accessible in a single, shared location. Success is defined by our ability to not only support a wide variety of package manager clients, but to provide a consistent, delightful user experience with each integration. We currently support Maven, NPM and Docker. We will be adding support for C++ (Conan), .net (NuGet), Linux (Debian, RPM), and Helm charts (Kubernetes).
Related Epics:
- [Support additional package manager clients](https://gitlab.com/groups/gitlab-org/-/epics/1245)
- [Improve the usability of the GitLab Package Registry](https://gitlab.com/groups/gitlab-org/-/epics/1241)
### Secure, Accessible Integrations
As we roll out support for additional package management clients, we must ensure that we provide a secure, unified method of authentication. Our vision is to allow users to leverage their [personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) for authenticating with any of the GitLab package repositories. In order to support managing dependencies from CI/CD builds, we will also support authenticating with [CI_JOB_TOKEN](https://docs.gitlab.com/ee/user/project/new_ci_build_permissions_model.html#job-token)
#### Single Application CI/CD
Related Epics:
<%= partial("direction/cicd/themes/integrated_solutions") %>
- [Standardize authentication and permissions for the GitLab Registry](https://gitlab.com/groups/gitlab-org/-/epics/1243)
#### Do Powerful Things Easily
### Dependable and Performant Supply Chains
<%= partial("direction/cicd/themes/cool_things") %>
Developers rely on an ever-growing list of external, 3rd party dependencies. Each of those dependencies must be downloaded, stored, and updated as part of the software development lifecycle. Our vision is to provide users a reliable, performant location for downloading, caching and managing all of their external dependencies.
#### Compliance as Code & Secure Secrets
We are actively working on improving our storage optimization features, which will allow administrators to better track usage, set limits, and establish policies to reduce the overall cost of storage of the GitLab Package Registry. We will continue to roll out the GitLab Dependency Proxy to a broader audience. This will minimize the number of external downloads, improve build times, and reduce the risk of 3rd party outages.
<%= partial("direction/cicd/themes/compliance_as_code") %>
Related Epics:
#### Universal Package Management
- [Lower the cost of the registry by improving storage management](https://gitlab.com/groups/gitlab-org/-/epics/434)
- [Roll out the dependency proxy to all users](https://gitlab.com/groups/gitlab-org/-/epics/1372)
<%= partial("direction/cicd/themes/universal_package_management") %>
<%= partial("direction/categories", :locals => { :stageKey => "package" }) %>
......
......@@ -3,6 +3,8 @@ layout: markdown_page
title: "Product Vision - Release"
---
{:.no_toc}
- TOC
{:toc}
......@@ -26,7 +28,11 @@ any questions about what's coming.
See the responsibilities and members of this stage group in the [Release product category](/handbook/product/categories/#release-stage), and our UX vision in the [UX Strategy page](/handbook/engineering/ux/stage-group-ux-strategy/release/).
## North Stars
## Vision
<%= partial("direction/cicd/strategies/release") %>
## Themes
There are a few important north stars we are keeping sight of to guide us forward
in this space. With each of these, we're focusing on complete (what we call minimally
......@@ -38,53 +44,29 @@ them to grow into more complete and comprehensive solutions.
you can view them on a calendar at [this link](https://gitlab.com/groups/gitlab-org/-/roadmap?scope=all&utf8=✓&state=opened&label_name[]=devops%3A%3Arelease)
- Stage usage can be tracked at the Release [SMAU (Stage Monthly Active Users) Dashboard](https://app.periscopedata.com/app/gitlab/451468/Release-Stage-Dashboard)
##### Zero-Touch Delivery
#### Single Application CI/CD
Technologies like AutoDevOps are leading the way in making it possible for
developers to focus on building code and letting the automation handle figuring out
how to handle the deployment. Our vision is for CD to take over from your build
system and predictably manage your delivery for you while remaining completely
customizable to support any unique cases. We're achieving this through templates,
smart defaults, and feature flags that give you the confidence to release smaller
changes more frequently.
<%= partial("direction/cicd/themes/integrated_solutions") %>
Related Epics:
#### Multi-Platform Support
- [Make CD more reliable and require less interaction](https://gitlab.com/groups/gitlab-org/-/epics/770)
- [Better management of stability in master](https://gitlab.com/groups/gitlab-org/-/epics/101)
- [CI/CD Reporting & Analytics improvements](https://gitlab.com/groups/gitlab-org/-/epics/358)
- [A/B/n testing using Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/712)
<%= partial("direction/cicd/themes/multi_platform") %>
##### On-Demand Environments
#### Do Powerful Things Easily
Delivering software to your environments automatically is the first step, and
modern technologies like Kubernetes are now allowing on-demand environments to be
created like never before. By tying your source repo to intelligent infrastructure
that understands the intentions of developers, you can enable a true one-click
workflow to deliver to your internal or external end users.
<%= partial("direction/cicd/themes/cool_things") %>
Related Epics:
#### Progressive Delivery
- [Make environments easier to use and manage](https://gitlab.com/groups/gitlab-org/-/epics/767)
- [Improve certificate handling for Pages](https://gitlab.com/groups/gitlab-org/-/epics/766)
<%= partial("direction/cicd/themes/progressive_delivery") %>
##### Secure, Compliant, and Well-Orchestrated Deployments
#### Mobile Support
Releasing in GitLab takes advantage of our [deeply connected ecosystem](/handbook/product/#single-application)
to provide traceability and auditing all the way from planning through monitoring.
Compliance and security evidence is gathered and validated at each step of
the way, giving you confidence that what you're delivering is what you expect.
Deployments are separated from builds and tests, ensuring a clear boundary
between developers and production environments, thanks to your well-orchestrated
and automated delivery process.
<%= partial("direction/cicd/themes/mobile_support") %>
Related Epics:
#### Compliance as Code & Secure Secrets
- [Make Releases feature viable](https://gitlab.com/groups/gitlab-org/-/epics/764)
- [Lock down path to production](https://gitlab.com/groups/gitlab-org/-/epics/762)
- [Cross-project pipeline triggering and visualization](https://gitlab.com/groups/gitlab-org/-/epics/414)
- [Mature release orchestration](https://gitlab.com/groups/gitlab-org/-/epics/771)
- [Improve mobile CI/CD using GitLab](https://gitlab.com/groups/gitlab-org/-/epics/769)
<%= partial("direction/cicd/themes/compliance_as_code") %>
<%= partial("direction/categories", :locals => { :stageKey => "release" }) %>
......
......@@ -3,6 +3,8 @@ layout: markdown_page
title: "Product Vision - Verify"
---
{:.no_toc}
- TOC
{:toc}
......@@ -22,66 +24,38 @@ Note that this stage is also involved in delivering improvements for our
[mobile development and delivery](/direction/mobile) and [CI/CD](/direction/cicd)
use cases. If you have an interest in these topics, please also take a look there.
## Overview
## Vision
<figure class="video_container">
<iframe src="https://www.youtube.com/embed/ePPEhfaQ6TM?rel=0" frameborder="0" allowfullscreen="true" width="640" height="360"> </iframe>
</figure>
<%= partial("direction/cicd/strategies/verify") %>
## North Stars
## Themes
We track epics for many of the major deliverables associated with these north stars,
you can view them on a calendar at [this link](https://gitlab.com/groups/gitlab-org/-/roadmap?label_name%5B%5D=devops%3A%3Averify&scope=all&sort=end_date_asc&state=opened&layout=QUARTERS).
### Gateway to Operations
CI was one of the first "additions" to GitLab where there was a hotly contested debate about placing it
into a single application. As the [first stage after Dev](/handbook/product/categories/#verify-stage),
Verify has the unique ability to tie together what developers are doing (every commit) with what
operators need (reliable, tested deployments). Therefore, Verify will continue to strive to be a "shining city on a hill" of the
tangible and emergent [benefits of a single application](/handbook/product/single-application/),
avoiding the pitfalls of legacy systems that optimize only for one stage of the DevOps lifecycle.
#### Single Application CI/CD
Related Epics:
* [Gateway to Operations parent epic](https://gitlab.com/groups/gitlab-org/-/epics/814)
* [Lock down path to production](https://gitlab.com/groups/gitlab-org/-/epics/762)
* [Variables and secrets management](https://gitlab.com/groups/gitlab-org/-/epics/816)
<%= partial("direction/cicd/themes/integrated_solutions") %>
### Speed & Scalability
#### Multi-Platform Support
At the core, GitLab CI/CD was built from the ground up with speed and scalability in mind. This is reflected both in the product design and product vision
([automated testing, testing all the things](https://about.gitlab.com/2018/02/05/test-all-the-things-gitlab-ci-docker-examples/))
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.
<%= partial("direction/cicd/themes/multi_platform") %>
Related Epics
* [Speed & Scalability parent epic](https://gitlab.com/groups/gitlab-org/-/epics/786)
* [Define and record Verify time to first byte](https://gitlab.com/groups/gitlab-org/-/epics/830)
* [More efficient pipeline execution](https://gitlab.com/groups/gitlab-org/-/epics/439)
#### Speedy, Reliable Pipelines
### Lovable solutions to complex problems
<%= partial("direction/cicd/themes/speedy_pipelines") %>
Our users are solving some of the hardest problems on the cutting edge of software development. The promise of GitLab overall is to provide a simple, lovable application for the entire DevOps lifecycle. Many parts of that cycle - including Verify - are traditionally complex to solve. Our goal is to provide a lovable solution to these complex problems so that users focus on their code - not building a DevOps environment.
#### Do Powerful Things Easily
Related Epics:
* [Make CI Lovable parent epic](https://gitlab.com/groups/gitlab-org/-/epics/811)
* [Lovable for microservices](https://gitlab.com/groups/gitlab-org/-/epics/813)
* [Lovable for monorepos](https://gitlab.com/groups/gitlab-org/-/epics/812)
* [Review and Overhaul CI/CD Docs](https://gitlab.com/groups/gitlab-org/-/epics/784)
* [UX improvements](https://gitlab.com/groups/gitlab-org/-/epics/876)
* [Handling complex only/except logic](https://gitlab.com/groups/gitlab-org/-/epics/1237)
<%= partial("direction/cicd/themes/cool_things") %>
#### Mobile Support
### Journey to DevOps Maturity
<%= partial("direction/cicd/themes/mobile_support") %>
Often, when businesses invest in continuous integration, they plateau
once they have have the code building and tests running. However, to deploy effectively,
we need to embrace code review, dependency assurance, security scanning and performance metrics for every commit.
GitLab's vision for Verify is to help users accelerate their journey to DevOps maturity.
#### Compliance as Code & Secure Secrets
Related Epics:
* [Review and Overhaul CI/CD Docs](https://gitlab.com/groups/gitlab-org/-/epics/784)
* [Verify UX research](https://gitlab.com/groups/gitlab-org/-/epics/592)
* [CI/CD Reporting & Analytics](https://gitlab.com/groups/gitlab-org/-/epics/358)
<%= partial("direction/cicd/themes/compliance_as_code") %>
<%= partial("direction/categories", :locals => { :stageKey => "verify" }) %>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment