Skip to content
Snippets Groups Projects
Commit f6f8eceb authored by Julie Manalo's avatar Julie Manalo
Browse files

Merge branch 'master' into 'patch-19826111318' 

# Conflicts:
#   source/handbook/sales/territories/index.html.md
parents 2fadc43d dc3926ec
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 454 additions and 554 deletions
source/direction/manage/access/administration/index.html.md deleted 100644 → 0
+ 0
− 50
View file @ 2fadc43d
---
layout: markdown_page
title: "Category Vision - Administration"
---
- TOC
{:toc}
| Category Attribute | Link |
| ------ | ------ |
| [Stage](https://about.gitlab.com/handbook/product/categories/#hierarchy) | [Manage](https://about.gitlab.com/direction/manage) |
| [Maturity](/direction/maturity/#maturity-plan) | [Not applicable](#maturity) |
| Labels | [admin dashboard](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=admin%20dashboard), [spam fighting](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=spam%20fighting) |
## Administration
After a GitLab instance has been set up, it must be maintained. The GitLab administrator manages configuration and user activity on an ongoing basis - our mission is to ensure that this power user has the tools and endpoints they need in order to manage their instance effectively and efficiently.
## Target audience and experience
GitLab administrators of complicated instances are who we're building for - these are privileged users with the keys to the castle, but likely with a multitude of applications to manage and limited amounts of time. Finding settings should be straightforward, and the admin area should provide an admin with the information and levers needed in order to effectively manage the instance and its users.
## Maturity
As the admin panel in GitLab is fairly application-specific, Administration is considered a non-marketing category without a [maturity level](/direction/maturity/) that can be compared to other competing solutions.
## How you can help
As with any category in GitLab, it's dependent on your ongoing feedback and contributions. Here's how you can help:
1. Comment and ask questions regarding this category vision by commenting in the [public epic for this category](https://gitlab.com/groups/gitlab-org/-/epics/651).
1. Find issues in this category accepting merge requests. [Here's an example query](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=admin%20dashboard&label_name[]=Accepting%20merge%20requests)!
## What's next & why
### Current
We're focusing on the needs of our internal customer, the GitLab Support team, by adding a number of improvements to make GitLab.com (and other large instances) easier to manage. Please see https://gitlab.com/groups/gitlab-org/-/epics/645.
## Top user issue(s)
[Adding search](https://gitlab.com/gitlab-org/gitlab-ce/issues/50145) to the admin area is a top need. As the admin panel only becomes more complex under the weight of more features and configuration, adding search will go a long way to keeping this area of GitLab navigable.
## Top internal customer issue(s)
The GitLab Support team has created [an epic](https://gitlab.com/groups/gitlab-org/-/epics/645). We need to also focus on the abuse team's needs in issues like [templating abuse reports](https://gitlab.com/gitlab-org/gitlab-ce/issues/47950).
## Top Vision Item(s)
MVC of an admin page for a group Owner.
source/direction/manage/access/index.html.md deleted 100644 → 0
+ 0
− 67
View file @ 2fadc43d
---
layout: markdown_page
title: "Manage - Access Group"
---
- TOC
{:toc}
## Access
### Introduction and how you can help
Thanks for visiting this overview of the Access group’s product vision. The Access group is 1 of 2 groups that compose the Manage stage. You can read more about Manage and how it fits into the GitLab product here.
This page is a work in progress, and everyone can contribute:
* Please comment and contribute in the linked issues and epics on this category page. Contributing your feedback directly on GitLab.com is the best way to contribute to our shared vision.
* Please also share feedback with the PM for this stage (Jeremy Watson) via email, Twitter, or on a video call. If you’re one of the GitLab administrators described in the Overview below, we’d especially love to hear from you and how we can make your job easier.
Onward!
### Overview
One of the pillars for the Manage stage of the DevOps lifecycle is **helping organizations prosper with configuration and analytics that enables them to work more efficiently**. As part of Manage, the Access group primarily focuses on the **configuration** part of this mission.
Access is here to serve the GitLab administrator. These are privileged users with the keys to the kingdom; they may range from a CEO/CTO at a smaller organization to an IT manager at a larger company - in any size instance, they’re one of the primary users responsible for setting up, configuring, and maintaining an instance. They’re also busy, frustrated with lengthy configuration steps and tedious workarounds, and keen to automate away tasks they find themselves doing frequently.
As GitLab instances scale, we typically see these problems grow in turn. Not only do the number of members increase, but so do the number of requirements from the business on how they’d like their instance to behave. As native configuration begins to fall short, administrators may fill the gap with their own solutions - whether it’s nginx to manage ingress/egress, or a custom cronjob to periodically check user activity - which demand maintenance and upkeep of their own.
Access’s mission is to solve for these needs directly in GitLab. Onboarding shouldn’t be a tedious task; our supported authentication and identity management should be able to support your enterprise’s existing solution. Security and compliance should be configurable and monitorable.
Ultimately, we want to natively support the configuration and guardrails an administrator needs to work efficiently - and get a good night’s sleep.
### Categories
Access's relevant categories center around this focus on configuration and access:
| Category | Description |
| ------ | ------ |
| Governance | Ongoing governance of how GitLab is used. Covers audit management, workflow policies, and traceability. |
| [Authentication and authorization](https://about.gitlab.com/direction/manage/access/auth/) | SAML, LDAP, OAuth, and more. |
| [Groups](https://about.gitlab.com/direction/manage/access/groups/) | Creating and managing groups and subgroups. |
| [Users](https://about.gitlab.com/direction/manage/access/users/) | Nearly anything related to users in GitLab: how they're managed, our permissions model, user profiles, and user registration. |
| [Administration](https://about.gitlab.com/direction/manage/access/administration/) | Admin panel and managing abuse in GitLab. |
### Themes
#### Working at enterprise scale
Whether you’re an “enterprise” or not, GitLab should be maintainable at scale. As described above, Access seeks to find areas where large instances find themselves doing things that don’t scale - whether or not that’s onboarding new employees by hand or managing inactive users.
#### Security and compliance
The task of managing risk is always on. GitLab should help administrators manage the risk of internal and external threats with a strong, configurable permissions model and with full audit capabilities when further investigation is required.
### What’s next and why
#### Current (what we're focusing on now)
Details to come.
#### Next (3-4 releases)
Details to come.
#### Future (5-8 releases)
Details to come.
source/direction/manage/policies/index.html.md → source/direction/manage/compliance-controls/index.html.md
+ 63
− 0
View file @ f6f8eceb
@@ -8,27 +8,41 @@ title: "Category Vision - Compliance Controls"
 
## Compliance Controls: Introduction
 
Thanks for visiting the strategy page for Compliance Controls in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the [corresponding epic](https://gitlab.com/groups/gitlab-org/-/epics/720) for this category.
Thanks for visiting the strategy page for Compliance Foundation in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the [corresponding epic](https://gitlab.com/groups/gitlab-org/-/epics/720) for this category.
 
For enterprises operating in regulated environments where maintaining control over permissions is critical, organizations typically rely on GitLab's roles and permissions controls to maintain acceptable controls. However, some organizations fitting this profile may consider GitLab's role system to be too broad and without the fine-grained controls they need to manage risk. For many customers, "they often resort to setting everyone to Maintainer and trusting their colleagues to not make mistakes" ([see research](https://gitlab.com/gitlab-org/ux-research/issues/62)). This is a painful state for instances - and for some, a hard barrier that completely prevents adoption of GitLab.
For enterprises operating in [regulated environments](link-to-compliance-insight), organizations need to ensure the technology they use complies with the various requirements of a particular framework (e.g. GDPR, SOC 2, ISO, PCI-DSS, SOX, COBIT, HIPAA, FISMA, NIST). GitLab necessarily needs to build features that enable customers to comply with these frameworks beginning with a strong foundation.
## Problems to Solve
Customers rely on organizations like GitLab to make the compliance process easier, often times by simply not making things more difficult or adding risk. Our goal is to provide "out-of-the-box" solutions where we can, and customization where it makes sense. In order to do this, we must first establish the framework(s) our customers adhere to so we can have a strong foundation to build upon.
* What success looks like: GitLab should provide framework-specific settings or policies that enable customers to quickly ensure the activities within their GitLab instance are conforming to organizational requirements. For example, Merge Requests should have a setting to toggle that introduces SOC2-focused requirements to meet before the MR can be approved.
When customers adhere to internal or external compliance frameworks, often times a need for customization arises. One organization's process for an activity can vary greatly from another's and this can create friction or usability issues. To facilitate better usability within GitLab towards compliance efforts, we'll be introducing features that enable customers to define specific policies or requirements their users and instance should abide by.
* What success looks like: Customers will be able to specify specific rules the instance must follow at an instance, group, project, and user-level to maintain tighter control of their environments. These rules should come from "standard" settings GitLab provides and provide an option to customize those rules as necessary to suit individual customer needs.
 
In almost all cases, these users want to *further constrain* existing roles, instead of permitting their users to do more. Without an ability to maintain a separation of duties between individuals at work, administrators for these organizations are faced with few workarounds: they can tolerate higher risk, lock down an instance and manage additional administrative overhead at the price of velocity, or build and maintain layers of automation on their own. For enterprises to thrive, this is a problem that demands a high-quality, native solution in GitLab.
 
* What success looks like: Customers should be able to finely tune GitLab's permissions to meet their needs, but without the complexity and headache of massive configuration time.
## What's Next & Why
 
Organizations need control of all technology they use to mitigate risk and adhere to compliance frameworks. GitLab's Compliance Controls category aims to address this need by introducing features and experiences that enable our customers to introduce better controls on their instances.
There'll never be a perfect role for every organization; as we've learned from [user feedback](https://docs.google.com/document/d/1-MZItci-Uxn4m-uEh5wR5VnC2sTeR_8UYdgaZmO6Yik/edit), organizations want customizable, deep control on a wide swath of settings and features. It's possible for us to iterate on our existing permissions framework by adding additional configuration and roles, but we're skeptical that we can offer the level of customization that can work for organizations with complex compliance needs.
 
We've considered [custom roles](https://gitlab.com/gitlab-org/gitlab-foss/issues/12736) in the past, but we feel there's a need for a new framework that can allow an instance to constrain roles without requiring the overhead and complexity of fully custom roles.
 
This category - Compliance Controls - is intended to be that solution; instead of writing custom roles, we'd like to be able to write custom conditions for what the existing roles in GitLab are able to do, under different conditions. We're inspired by [identity-based policies in systems like AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based) that allow policies to be defined and applied to resources we'd like to protect.
This category - Compliance Foundation - is designed to introduce that solution; instead of writing custom roles, we want to introduce "out-of-the-box" permissions, but enable custom conditions for what the existing roles in GitLab are able to do, under different cirumstances. We're inspired by [identity-based policies in systems like AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based) that allow policies to be defined and applied to resources we'd like to protect.
 
By introducing a layer of enforcement on top of our existing [RBAC](https://en.wikipedia.org/wiki/Role-based_access_control), this system lends us a high degree of flexibility in GitLab and reduces risk by adding to our permissions system instead of supplanting it.
 
The first step on this journey is introducing a Minimal, viable version of Compliance Controls - described further in our Maturity Plan below.
The first step on this journey is introducing a Minimal, viable version of Policies - described further in our Maturity Plan below.
 
### How you can help
 
As we're still the conceptual stages of developing Compliance Controls, **your feedback is critical** to successfully shaping this category so that it works for your organization's needs. If you're interested in this problem space, please [comment on your needs and experiences with permissions in GitLab](https://gitlab.com/groups/gitlab-org/-/epics/1982). We're especially interested in:
As we're still the conceptual stages of developing Policies, **your feedback is critical** to successfully shaping this category so that it works for your organization's needs. If you're interested in this problem space, please [comment on your needs and experiences with permissions in GitLab](https://gitlab.com/groups/gitlab-org/-/epics/1982). We're especially interested in:
* How are you currently working around permissions and compliance problems in GitLab?
* What specific controls would you like introduced?
* Which conditions would ideally determine which users are not able to take a particular action? Conversely, which conditions would ideally determine who is?
@@ -36,14 +50,14 @@ As we're still the conceptual stages of developing Compliance Controls, **your f
 
### [Maturity Plan](https://gitlab.com/groups/gitlab-org/-/epics/720)
 
Compliance Controls is currently **Planned**. The next step in Compliance Controls' maturity is to **Minimal** maturity.
Policies is currently **Planned**. The next step in Policies' maturity is to **Minimal** maturity.
* You can read more about GitLab's [maturity framework here](https://about.gitlab.com/direction/maturity/), including an approximate timeline.
 
To achieve a minimal version of Compliance Controls, we'll conduct deep discovery on the problem space before taking our first step. An [MVC](https://about.gitlab.com/handbook/product/#the-minimally-viable-change-mvc) for Compliance Controls will likely allow an administrator or Owner to define a basic Policy and apply the ruleset to a particular project. We're fans of version control at GitLab, so we should be able to take a compliance-as-code approach that allows us to store these rules in a structured file.
To achieve a minimal version of Policies, we'll conduct deep discovery on the problem space before taking our first step. An [MVC](https://about.gitlab.com/handbook/product/#the-minimally-viable-change-mvc) for Policies will likely allow an administrator or Owner to define a basic Policy and apply the ruleset to a particular project. We're fans of version control at GitLab, so we should be able to take a compliance-as-code approach that allows us to store these rules in a structured file.
* Please track the Minimal maturity plan in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/1982).
 
Once we've achieved a minimal version of Compliance Controls, achieving a **Viable** level of maturity will involve collecting customer feedback and reacting. Assuming we're on the right track, we'll likely scale the solution in two dimensions:
* Increase the number of settings and features you can write policies for. The MVC will likely focus on 1-2 common compliance use cases, and we'll need to increase the breadth of controls offered,
Once we've achieved a minimal version of Policies, achieving a **Viable** level of maturity will involve collecting customer feedback and reacting. Assuming we're on the right track, we'll likely scale the solution in two dimensions:
* Increase the number of settings and features you can write Policies for. The MVC will likely focus on 1-2 common compliance use cases, and we'll need to increase the breadth of controls offered,
* Increase the number of user states that a Policy can use to permit/deny an action. Again, the MVC will likely focus on allowing/disallowing actions with only a few ways to write rules: likely allowing/disallowing a particular action for all users. We anticipate needing further depth, such as allowing an action if a user is a member of a particular group.
 
Finally, once we've achieved a ruleset that's sufficiently flexible and powerful for enterprises, it's not enough to be able to define these rules - we should be able to measure and confirm that they're being adhered to. Achieving **Complete** or **Lovable** maturity likely means further expansion of the two dimensions above, plus visualizing/reporting on the state of Compliance Controls across the instance.
Finally, once we've achieved a ruleset that's sufficiently flexible and powerful for enterprises, it's not enough to be able to define these rules - we should be able to measure and confirm that they're being adhered to. Achieving **Complete** or **Lovable** maturity likely means further expansion of the two dimensions above, plus visualizing/reporting on the state of Policies across the instance.
source/direction/manage/devops-score/index.html.md
+ 3
− 10
View file @ f6f8eceb
@@ -13,25 +13,18 @@ title: "Category Strategy - DevOps Score"
| [Manage](/direction/manage/) | [Minimal](/direction/maturity/) |
 
### Introduction and how you can help
Thank you for visiting the category strategy page for DevOps Score. This page belongs to [Virjinia Alexieva](https://gitlab.com/valexieva) ([E-Mail](mailto:valexieva@gitlab.com), [Twitter](https://twitter.com/virjinialexieva)).
Thank you for visiting the category strategy page for DevOps Score.
 
This strategy is a work in progress and everyone can contribute by sharing their feedback directly on [GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/1499), via e-mail, or Twitter.
<!-- Eric, I am going to use this epic and modify rather than start a new one -->
 
### Overview
<!-- A good description of what your category is today or in the near term. If there are
special considerations for your strategy or how you plan to prioritize, the
description is a great place to include it. Provide enough context that someone unfamiliar
with the details of the category can understand what is being discussed. -->
With [VSM](https://about.gitlab.com/direction/manage/value_stream_management/) and [Code Analytics](https://about.gitlab.com/direction/manage/code-analytics), GitLab is trying to improve organizations' understanding of how their people and codebase interact in order to improve the speed and quality of software delivery. More and more new users are signing up on GitLab.com and through that expanding community, we hope to be able to draw insights into how the usage of GitLab's different components correlates with and improves the efficiency, velocity and quality of an organization. We would also like to enable Executives to compare their organization with the rest of the community and identify areas for improvement.
 
Our first attempt at providing instances with a single metric for GitLab adoption and engagement was [ConvDev Index](https://docs.gitlab.com/ee/user/instance_statistics/convdev.html). As soon as the index was released, however, we recognized that it has opened an enormous space for research, which will evolve with our software.
 
### Where we are Headed
<!-- Describe the future state for your category. What problems will you solve?
What will the category look like once you've achieved your strategy? Use narrative
techniques to paint a picture of how the lives of your users will benefit from using this
category once your strategy is fully realized - Availability - Service level agreements - Failed deployments - Error rates - Application usage and traffic - Application performance - Customer tickets - customer support tickets are often a good indication of the quality of software -->
The goal of DevOps is to increase quality, velocity and performance and we are helping customers to improve across these dimenions with [Value Stream Management](https://about.gitlab.com/direction/manage/value_stream_management/). There are multiple levels of detail required to manage and improve bottlenecks, but it's also important to define clear top line metrics that can be comparable across industries and companies. We believe the 4 main DORA metrics for DevOps success are a great start to that, which we will complement with other measures that companies have found powerful in providing a holistic picture of the health of their software development. Some of these include:
- Deployment frequency - reducing the size and time between deployments makes it easier to test and release (staging, canary, production)
- Defect escape rate - % of bugs identified after software is released in production
source/direction/manage/importers/index.html.md 0 → 100644
+ 19
− 0
View file @ f6f8eceb
---
layout: markdown_page
title: "Category Vision - Importers"
---
- TOC
{:toc}
## Importers
Thanks for visiting the strategy page for Importers in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the [corresponding epic](https://gitlab.com/groups/gitlab-org/-/epics/2248) for this category.
## What's Next & Why
At the moment, the group is focused on enabling GitLab.com adoption through the introduction of [group import/export](https://gitlab.com/groups/gitlab-org/-/epics/1952). More details on this category's vision are currently under construction.
## Maturity Plan
Our maturity plan is currently under construction. If you'd like to contribute feedback on areas you'd like to see prioritized, please add them as comments in the [epic](https://gitlab.com/groups/gitlab-org/-/epics/2248).
source/direction/manage/templates/index.html.md 0 → 100644
+ 19
− 0
View file @ f6f8eceb
---
layout: markdown_page
title: "Category Vision - Templates"
---
- TOC
{:toc}
## Templates
Thanks for visiting the strategy page for Templates in GitLab. If you'd like to provide feedback on this page or contribute to this vision, please feel free to open a merge request for this page or comment in the [corresponding epic](https://gitlab.com/groups/gitlab-org/-/epics/2249) for this category.
## What's Next & Why
This section is under construction.
## Maturity Plan
Our maturity plan is currently under construction. If you'd like to contribute feedback on areas you'd like to see prioritized, please add them as comments in the [epic](https://gitlab.com/groups/gitlab-org/-/epics/2249).
source/direction/monitor/apm/logging/index.html.md
+ 4
− 22
View file @ f6f8eceb
@@ -17,24 +17,22 @@ Thanks for visiting this category strategy page on Logging in GitLab. This categ
 
This strategy is a work in progress, and everyone can contribute:
- Please comment and contribute in the linked [issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aapm&label_name[]=Category%3ALogging) and [epics](https://gitlab.com/groups/gitlab-org/-/epics?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aapm&label_name[]=Category%3ALogging) on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
- Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your Metrics usage, we'd especially love to hear your use case(s)
- Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your Logging usage, we'd especially love to hear your use case(s)
 
## Background
A fundamental requirement for running applications is to have a centralized location to manage and review the logs. While manually reviewing logs could work with just a single node app server, once the deployment scales beyond one you need solution which can [aggregate and centralize them](https://gitlab.com/gitlab-org/gitlab-ee/issues/3711) for review.
Much like we do with Prometheus, GitLab can integrate with existing open source logging solutions to provide an integrated experience.
## Target Audience and Experience
Being able to capture and review logs are an important tool for all users across the DevOps spectrum. From pure developers who may need to troubleshoot their application when it is running in a staging or review environment, as well as pure operators who are responsible for keeping production services online.
 
The target workflow includes a few important use cases:
1. Aggregating logs from multiple hosts/containers
1. Aggregating logs from multiple pods and containers from all namespaces
1. Filtering by host, container, service, timespan, regex, and other criteria. These filtering options should align with the filter options and tags/labels of our other monitoring tools, like metrics.
1. Log alerts should also be able to be created, triggering alerts under specific user defined scenarios.
 
## What's Next & Why
The next step is to install Elasticsearch as a base for our aggregated logging. Once we complete our evaluation we will offer our users a centralize logging solution, within Gitlab UI, based on Elasticsearch, with the push of a button.
In the distributed nature of cloud-native applications, it is crucial and critical to collect logs across multiple services and infrastructure, present them in an aggregated view, so users could quickly search through a list of logs that originate from multiple pods and containers.
Therefore, our next step allows our users, with a push of a button to install Elasticsearch on their monitored cluster and collect automatically, all logs from all namespaces in the cluster to facilitate an aggregated logging solution. This enhances our logging capabilities and offers advanced filtering and a full-text search across aggregated logs in a single view.
 
## Epics
* [Logging - viable](https://gitlab.com/groups/gitlab-org/-/epics/1348)
@@ -43,21 +41,5 @@ The next step is to install Elasticsearch as a base for our aggregated logging.
## Competitive Landscape
[Splunk](https://www.splunk.com) and [Elastic](https://www.elastic.co/) are the top two competitors in this space.
 
## Analyst Landscape
There does not seem to be a Forrester or Gartner analysis for this product category.
We will be reaching out and setting up meetings with analysts to get their insight soon.
## Top Customer Success/Sales Issue(s)
[Aggregated logs](https://gitlab.com/gitlab-org/gitlab-ee/issues/3711)
## Top Customer Issue(s)
[Aggregated logs](https://gitlab.com/gitlab-org/gitlab-ee/issues/3711)
## Top Internal Customer Issue(s)
 
## Top Direction Item(s)
- [Aggregated logs](https://gitlab.com/gitlab-org/gitlab-ee/issues/3711)
- [Application log filtering and search](https://gitlab.com/gitlab-org/gitlab-ce/issues/64919)
- [Application log alerts](https://gitlab.com/gitlab-org/gitlab-ee/issues/3626)
 
source/direction/release/continuous_delivery/index.html.md
+ 18
− 21
View file @ f6f8eceb
@@ -58,12 +58,10 @@ Incremental rollout also serves as a key pillar for our [Progressive Delivery](/
strategy.
## What's Next & Why
We recently released support for parallel Merge Trains ([gitlab#11222](https://gitlab.com/gitlab-org/gitlab/issues/11222)). After using this internally, we discovered that some tweaking is needed
in order to use this in a widespread manner, our first concern is performance, that is why we are working on [gitlab#31692](https://gitlab.com/gitlab-org/gitlab/issues/31692) tuning the concurrency of the number of merges in a single train.
Another exciting feature that we are working on is to allow fork pipelines to run in parent project ([gitlab#11934](https://gitlab.com/gitlab-org/gitlab/issues/11934)). Some development teams are forking instead of a branching git workflows.
We want to provide a way to run a pipeline in this way, with the appropriate security considerations accounted for that will support these CI/CD projects as well.
GitLab CI/CD was built from the ground up with speed and scalability in mind, and we are always working hard to enable [Speedy, Reliable Pipelines](https://about.gitlab.com/direction/cicd/#speedy-reliable-pipelines). With that in mind, we are currently working on [gitlab#15536](https://gitlab.com/gitlab-org/gitlab/issues/15536), which will limit pipeline job concurrency using named semaphores. Sometimes there is a need to limit a resource or environment and this will ensure that there will only be one deployment at a time
Another important theme that we are working on is [Do Powerful Things Easily](https://about.gitlab.com/direction/cicd/#do-powerful-things-easily), which includes [Natively supporting hypercloud deployments](https://gitlab.com/groups/gitlab-org/-/epics/1804). To start we are focusing on creating base images that will make it easier to use GitLab for deployment to any one of the major could providers, starting with [gitlab#31167](https://gitlab.com/gitlab-org/gitlab/issues/31167), even when not using Kubernetes.
## Maturity Plan
@@ -77,8 +75,8 @@ Key deliverables to achieve this are:
- [Limit pipeline concurrency using named semaphores](https://gitlab.com/gitlab-org/gitlab/issues/15536)
- [More out of the box incremental rollout options](https://gitlab.com/gitlab-org/gitlab-ee/issues/1387)
- [Support typed AWS environment variables](https://gitlab.com/gitlab-org/gitlab-ce/issues/57780)
- [Allow only forward deployments](https://gitlab.com/gitlab-org/gitlab/issues/25276)
- [Post-deployment monitoring MVC](https://gitlab.com/gitlab-org/gitlab-ee/issues/8295)
- [Deploy button to make initial CI/CD setup easier](https://gitlab.com/gitlab-org/gitlab-ce/issues/52880)
- [Better guidance for more CD approaches](https://gitlab.com/gitlab-org/gitlab-ce/issues/52875)
- [Actionable CI/CD metrics](https://gitlab.com/gitlab-org/gitlab-ee/issues/7838)
@@ -103,7 +101,7 @@ we must provide more advanced deployment operator solutions via
Additionally, these products manage the deployment all the way through
to monitoring, which we will introduce via [gitlab#8295](https://gitlab.com/gitlab-org/gitlab/issues/8295).
 
We are conducting research for [Spinnikar](https://gitlab.com/gitlab-org/gitlab/issues/35219) and [Harness](https://gitlab.com/gitlab-org/gitlab-foss/issues/40722) and invite you to chime in on the issues and provide your insights and feedback as well.
We are conducting research for [Spinnaker](https://gitlab.com/gitlab-org/gitlab/issues/35219) and [Harness](https://gitlab.com/gitlab-org/gitlab-foss/issues/40722) and invite you to chime in on the issues and provide your insights and feedback as well.
## Analyst Landscape
@@ -111,6 +109,7 @@ In our conversations with industry analysts, there are a number of key trends
we're seeing happening in the CD space:
### Cloud Adoption
Cloud adoption of CI/CD is growing, with Docker adoption leading the
way and serverless likely next. People need guidance solving CD
because they are stepping out into the dark without mature solutions
@@ -118,17 +117,20 @@ already available to them; for example, AWS' current solution for
serverless (functions) CI is just "edit them live." Customers
complained that their products were starting to feel legacy, but
where they go next is unclear.
We invite you to follow our plans to [natively support hypercloud deployments](https://gitlab.com/groups/gitlab-org/-/epics/1804) and to offer feedback or ask questions.
### Customer Experience
Customer experience is becoming a key metric. Users are looking for
the ability to not just measure platform stability and other
performance KPIs post-deployment but also want to set targets for
customer behavior, experience, and financial impact. Tracking and
customer behavior, experience, and financial impact, as part of [gitlab#37139](https://gitlab.com/gitlab-org/gitlab/issues/37139). Tracking and
measuring this indicators after deployment solves an important
pain point. In a similar fashion, creating views which managing
pain point. In a similar fashion, creating views which are managing
products not projects or repos will provide users with a more
relevant set of data.
### Other Topics
In addition to supporting the trends above, there are some key areas
where we can focus that will improve our solution in areas that
@@ -140,7 +142,7 @@ analysts are hearing customer demand:
that make these complex relationships between environments and
deployments clear.
- [gitlab#8295](https://gitlab.com/gitlab-org/gitlab/issues/8295): **Deployment status reporting, monitoring behavior, and error handling**,
including [automated rollbacks](https://gitlab.com/gitlab-org/gitlab/issues/35404), incremental rollouts, and other intelligent
including [automated rollbacks](https://gitlab.com/gitlab-org/gitlab/issues/35404), [incremental rollouts](https://gitlab.com/gitlab-org/gitlab/issues/27264), and other intelligent
built-in and customizable strategies and behaviors. This can include
predictive analytics/ML and reporting about successes, failures, and pipeline health,
both retrospective and runtime. Customizable and tailored for the
@@ -150,7 +152,7 @@ analysts are hearing customer demand:
potential automatic remediation.
- [gitlab#11222](https://gitlab.com/gitlab-org/gitlab/issues/8295): Take control of your software delivery by **assembling associated changes into merge trains**
which can flow through your environments and on to production as a coherent
group. (Delivered in 12.1)
group.
## Top Customer Success/Sales Issue(s)
@@ -163,6 +165,7 @@ implemented via [gitlab#8295](https://gitlab.com/gitlab-org/gitlab/issues/8295).
Our most popular customer request is [gitlab#15536](https://gitlab.com/gitlab-org/gitlab/issues/15536),
When there are consecutive deploys to the same environment, it may cause unwanted problems.
We are working on an ability to allow users to limit concurrency to prevent simultaneous deploys from different projects to the same environment.
## Top Internal Customer Issue(s)
Our most popular internal customer issue is adding a way to notify the user about the maximum commits behind the source branch
@@ -177,9 +180,7 @@ this to see how this would be modeled in GitLab; see also the
- [gitlab#26691](https://gitlab.com/gitlab-org/gitlab/issues/26691) sets a maximum commits behind to merge
We are also working to internally adopt some recently released features:
- Pipelines for Merge Requests: [gitlab#26523](https://gitlab.com/gitlab-org/gitlab/issues/26523)
Our delivery team is also working on [gitlab#35741](https://gitlab.com/gitlab-org/gitlab/issues/35741) which displays the deployment information on the merge request, including when the first deployment took place, and also will tell you for a specific deployment which merge requests were merged.
### SRE Team
@@ -191,9 +192,5 @@ From an SRE standpoint, see:
## Top Vision Item(s)
Beyond completing the 2019 vision, the most important major step
forward for GitLab CD is [gitlab-org#8295](https://gitlab.com/gitlab-org/gitlab/issues/8295)
which will introduce post-deployment monitoring, creating a foundation
for advanced deployment features like automated rollbacks and summary
reports of environment behavior before and after the deployment.
 
Our top vision item is to [Natively support hypercloud deployments](https://gitlab.com/groups/gitlab-org/-/epics/1804), we want to help make it easier and quicker to get started and deploy to any one of the big cloud providers using GitLab's CI/CD.
source/direction/release/feature_flags/index.html.md
+ 19
− 20
View file @ f6f8eceb
@@ -8,15 +8,14 @@ title: "Category Vision - Feature Flags"
 
## Feature Flags
 
A feature flag is a technique in SW development that enables a feature to be tested even before it is completed and ready for release.
Feature flag is used to hide, enable or disable the feature during run time.
The technique allows developers to release a version of a product that has unfinished features.
These unfinished features are hidden (toggled) so they do not appear in the user interface.
Feature Flags can be used as part of software development to enable a feature to be tested even before it is completed and ready for release.
A feature flag is used to hide, enable or disable the feature during run time.
The unfinished features are hidden (toggled) so they do not appear in the user interface.
This allows many small incremental versions of software to be delivered without the cost of constant branching and merging.
 
Feature flags unlock faster, more agile delivery workflows by providing
control over the flexibility of deployment to a specific environment or audience. In addition it reduces risk to production, in case a problem is detected,
disabling the feature is as easy as turning off a switch.
because disabling the feature is as easy as turning off a switch.
 
Feature Flags is built with an [Unleash](https://github.com/Unleash/unleash)-compatible
API, ensuring interoperability with any other compatible tooling,
@@ -38,13 +37,12 @@ are more than welcome.
 
Now that we have released feature flags that support two different strategies,
% rollout ([gitlab#8240](https://gitlab.com/gitlab-org/gitlab/issues/8240)) and userID ([gitlab#11459](https://gitlab.com/gitlab-org/gitlab/issues/11459)),
we are moving forward with using feature flags internally as part of our deployment process ([gitlab#26842](https://gitlab.com/gitlab-org/gitlab/issues/26842)).
we are moving forward with using feature flags internally as part of our deployment process ([gitlab#26842](https://gitlab.com/gitlab-org/gitlab/issues/26842)). This will allow us to get internal feedback and improve feature flag functionality for both our internal customers and the wider GitLab community.
 
In addition, we are working on a powerful integration between feature flags and the issues and/or merge requests
that are affected by them. Since GitLab serves as a single application tool, users can now associate feature flags
directly form the issue or merge request and vice versa and view the current deployment status
from any location ([gitlab#26456](https://gitlab.com/gitlab-org/gitlab/issues/26456)).
that are affected by them. Since GitLab serves as a single application tool, users who use our feature flags and issue management, can associate feature flags
directly from the issue and vice versa and view the current deployment status
from any location ([gitlab#26456](https://gitlab.com/gitlab-org/gitlab/issues/26456)). This will provide visibility from the issue itself, and will let you know which feature flag is associated to it, it's status and percent rollout from the feature flag view, enabling you control and insights from wherever you wish to manage your feature flags.
 
## Maturity Plan
 
@@ -59,14 +57,18 @@ Key deliverables to achieve this are:
- [UserID-based access](https://gitlab.com/gitlab-org/gitlab/issues/11459) (Complete)
- [Add ability to associate feature flag with contextual issue/epic/MR](https://gitlab.com/gitlab-org/gitlab/issues/26456)
- [Feature Flag Gradual Rollout strategy based on groups](https://gitlab.com/gitlab-org/gitlab/issues/13308)
- [Multiple strategies per Feature Flags](https://gitlab.com/gitlab-org/gitlab/issues/35554)
- [Cookie-based access](https://gitlab.com/gitlab-org/gitlab/issues/11456)
- [API/CDN caching for feature flags](https://gitlab.com/gitlab-org/gitlab/issues/9479)
- [More explicit logging for accesses](https://gitlab.com/gitlab-org/gitlab/issues/9157)
- [A/B testing based on Feature Flags](https://gitlab.com/gitlab-org/gitlab/issues/34813)
- [Add Rule based Feature Flag rollout strategy support](https://gitlab.com/gitlab-org/gitlab/issues/33315)
- [Permissions for Feature Flags](https://gitlab.com/gitlab-org/gitlab/issues/8239)
- [Feature Flags user metrics](https://gitlab.com/gitlab-org/gitlab/issues/31442)
 
If you are interested in understanding the roadmap in a more granular fashion, you are welcome to follow these epics:
- [Refactor Feature Flags UX](https://gitlab.com/groups/gitlab-org/-/epics/2130)
- [Feature Flags Improvements - user action enhancements](https://gitlab.com/groups/gitlab-org/-/epics/2134)
- [Feature Flags Dashboard](https://gitlab.com/groups/gitlab-org/-/epics/2236)
## Competitive Landscape
 
Other feature flag products offer more comprehensive targeting and
@@ -84,7 +86,7 @@ more a part of what's fundamentally needed for a continuous delivery
platform, in order to minimize blast radius from changes. Often,
solutions in this space are complex and hard to get up and running
with, and they are not typically bundled or well integrated with CD
solutions. It's also unclear how to get started.
solutions.
 
This backs up our desire to not overcomplicated the solution space
here, and highlights the need for guidance. [gitlab#9450](https://gitlab.com/gitlab-org/gitlab/issues/9450)
@@ -97,20 +99,17 @@ None yet, but feedback is welcome.
 
## Top Customer Issue(s)
 
Being able to manage feature flags from an environment view [gitlab#9098](https://gitlab.com/gitlab-org/gitlab/issues/9098)
- Our most popular customer issue is the ability to manage feature flags from an environment view [gitlab#9098](https://gitlab.com/gitlab-org/gitlab/issues/9098). Users would like to be able to get a high level view of which feature flags exist per environment.
 
## Top Internal Customer Issue(s)
 
- Being able to control permissions ([gitlab#8239](https://gitlab.com/gitlab-org/gitlab/issues/8239))
on a per-environment basis for feature flags is a key driver of adoption
for our own production usage.
- Enabling Unleash in our codebase to enable internal use of our feture flag solution ([gitlab-ee#57943](https://gitlab.com/gitlab-org/gitlab-ce/issues/57943))
- Our top internal customer feature is [gitlab#26456](https://gitlab.com/gitlab-org/gitlab/issues/26456) which allows you to associate feature flags with issues. This gives the users the flexibility to see on the issue level which feature flags are associated, their status and their percent rollout all in the issue view, but also from the feature flag level lets you see which issues are linked to that feature flag.
- Enabling Unleash in our codebase to enable internal use of our feature flag solution ([gitlab-ee#57943](https://gitlab.com/gitlab-org/gitlab-ce/issues/57943)) is our main focus, as part of our values we believe it is important for us to use our own features and collect feedback to improve the experience of the greater GitLab community.
 
### Delivery Team
 
- [framework#64](https://gitlab.com/gitlab-com/gl-infra/delivery/issues/64) enables dashboard annotations for feature flags
- Feature Flags: [framework#216](https://gitlab.com/gitlab-com/gl-infra/delivery/issues/216) and [framework#32](https://gitlab.com/gitlab-com/gl-infra/delivery/issues/32)
 
## Top Vision Item(s)
 
Our top vision item is to [Natively support hypercloud deployments](https://gitlab.com/groups/gitlab-org/-/epics/1804), we want to help make it easier and quicker to get started and deploy to any one of the big cloud providers using GitLab's CI/CD..
One of our main themes in CI/CD is [Progressive delivery](https://about.gitlab.com/direction/cicd/#progressive-delivery). Feature flags, by definition is a form of progressive delivery as it allows you to deploy code incrementally and control the audience that will receive the new code. Our top vision item is to allow simple monitoring and management of the feature flags in the system, which can become a complex take once there are many feature flags in place. A feature flag dashboard as described in [gitlab#2236](https://gitlab.com/groups/gitlab-org/-/epics/2236) will make this an easy task.
source/direction/release/pages/index.html.md
+ 10
− 6
View file @ f6f8eceb
@@ -29,14 +29,18 @@ experience; it's truly one of our most "personal" features in the Release stage.
We do not plan to provide a market-leading solution for static web page hosting,
but we do want to offer one that is capable for most basic needs, in particular
for hosting static content and documentation that is a part of your software
release.
release. Popular issues and compelling blockers for our users hosting static content and documentation will be the top priority for Pages.
 
## What's Next & Why
In order to improve pages performance, we are working on changing the [pages architecture](https://gitlab.com/groups/gitlab-org/-/epics/1316).
The first improvement will be speeding up the initialization time ([gitlab#28782](https://gitlab.com/gitlab-org/gitlab/issues/28782)).
Now that we have delivered the first improvement to speed up the initialization time ([gitlab#28782](https://gitlab.com/gitlab-org/gitlab/issues/28782)),
our next focus will be to support Let's Encrypt more effectively in Pages ([gitlab#30660](https://gitlab.com/gitlab-org/gitlab/issues/30660),
[gitlab#35608](https://gitlab.com/gitlab-org/gitlab/issues/35608)). We are working on validating supporting custom domains and will expect to have
a path to redirect to custom domains ([gitlab#14243](https://gitlab.com/gitlab-org/gitlab/issues/14243)) following the Pages re-architecture effort.
Our most popular issue for Pages, Multiple version Pages support ([gitlab#16208](https://gitlab.com/gitlab-org/gitlab/issues/16208))
will need to wait until the new architecture is in place, but we are working on an alternative solution of using environments for achieving the same thing [gitlab#33822](https://gitlab.com/gitlab-org/gitlab/issues/33822).
will need to wait until the new architecture is in place, but we are working on an alternative solution of using environments for achieving the same
functionality ([gitlab#33822](https://gitlab.com/gitlab-org/gitlab/issues/33822)).
 
 
## Maturity Plan
@@ -47,8 +51,8 @@ Key deliverables to achieve this are:
 
- [Automatic certificate renewal](https://gitlab.com/gitlab-org/gitlab-foss/issues/28996) (Complete)
- [Access controls for Pages on gitlab.com](https://gitlab.com/gitlab-org/gitlab/issues/25362) (Complete)
- [Speed up Pages initialization time by using configuration API](https://gitlab.com/gitlab-org/gitlab/issues/28782)
- [Pages without DNS wildcard](https://gitlab.com/gitlab-org/gitlab/issues/17584)
- [Speed up Pages initialization time by using configuration API](https://gitlab.com/gitlab-org/gitlab/issues/28782) (Complete)
- [Pages without DNS wildcard](https://gitlab.com/gitlab-org/gitlab/issues/17584) (12.6)
- [Multiple version support](https://gitlab.com/gitlab-org/gitlab/issues/16208)
- [Redirect from GitLab pages URL to custom domain when one exists](https://gitlab.com/gitlab-org/gitlab/issues/14243)
- [Per-site, in-repo configuration](https://gitlab.com/gitlab-org/gitlab-pages/issues/57)
@@ -89,4 +93,4 @@ From a vision standpoint, adding Review Apps for Pages ([gitlab#16907](https://g
is interesting because it allows for more sophisticated development flows
involving testing, where at the moment the only environment that GitLab
understands is production. This would level up our ability for Pages to
be a more mission-critical part of projects and groups.
be a more mission-critical part of projects and groups. Another vision item being investigated is to leverage JAMSTACK for Pages. The primary goal would be to enhance the user experience ([gitlab#2179](https://gitlab.com/groups/gitlab-org/-/epics/2179)) and allow easy to set up pages from the UI.
source/direction/release/release_governance/index.html.md
+ 9
− 6
View file @ f6f8eceb
@@ -26,25 +26,27 @@ are more than welcome.
 
## What's Next & Why
 
Up next is our first feature that is part for evidence collection for SDLC [gitlab#26019](https://gitlab.com/gitlab-org/gitlab/issues/26019). We will start by adding a snapshot of the metadata of the release to the release page, in order to know if and what has been tampered with. It is important to know everything
Up next is our first feature that is part for evidence collection for SDLC ([gitlab#26019](https://gitlab.com/gitlab-org/gitlab/issues/26019)). We will start by adding a snapshot of the metadata of the release to the release page, in order to know if and what has been tampered with. It is important to know everything
that happens in your software delivery pipeline. We want to make it easy to answer: what, where, when, and by whom any change in the software happened,
without any additional effort, by making this data accessible from the release itself.
 
In addition, we have been challenged by monitoring the deployment of merge requests to different environments internally, and want to solve this problem for us and for customers alike [gitlab-infra#477](https://gitlab.com/gitlab-com/gl-infra/delivery/issues/477).
Another obstacle that we need to overcome internally is using an external environment for deployment, while still having the need to monitor it's activity for compliance and governance [gitlab#22513](https://gitlab.com/gitlab-org/gitlab/issues/22513).
A consistent challenge across GitLab users is being able to track deployments to GitLab.com, which is a top focus for [gitlab-infra#477](https://gitlab.com/gitlab-com/gl-infra/delivery/issues/477).
In [gitlab#22513](https://gitlab.com/gitlab-org/gitlab/issues/22513), we are looking to support a common use case of leveraging an external environment for deployment and having the need to monitor it's activity for compliance and governance.
By popular demand, we are validating and researching several issues of which include logging auto-stop actions ([gitlab#36407](https://gitlab.com/gitlab-org/gitlab/issues/36047)) as well as access control by users and roles for protected enviornments ([gitlab#36665](https://gitlab.com/gitlab-org/gitlab/issues/36665)).
 
 
## Maturity Plan
 
This category is currently at the "Planned" maturity level, and
our next maturity target is Viable (see our [definitions of maturity levels](/direction/maturity/)).
Key deliverables to achieve this are:
 
- [Wait for approvals in pipelines](https://gitlab.com/gitlab-org/gitlab/issues/15819) (Complete)
- [Evidence collection for Releases - snapshot of release metadata at moment of release](https://gitlab.com/gitlab-org/gitlab/issues/26019) (12.6)
- [Capture Release actions in the audit log page](https://gitlab.com/gitlab-org/gitlab/issues/32807)
- [User access policy for Production environment](https://gitlab.com/gitlab-org/gitlab/issues/15778)
- [Wait for approvals in pipelines](https://gitlab.com/gitlab-org/gitlab/issues/9187)
- [Evidence collection for Releases - snapshot of release metadata at moment of release](https://gitlab.com/gitlab-org/gitlab/issues/26019)
- [Blackout periods for environments MVC](https://gitlab.com/gitlab-org/gitlab/issues/24295)
- [Binary Authorization MVC](https://gitlab.com/gitlab-org/gitlab/issues/7268)
 
@@ -93,6 +95,7 @@ environments instead of relying on more broad-based project permissions.
- [Releases Page](https://gitlab.com/gitlab-org/gitlab-ce/releases)
- [gitlab#9187](https://gitlab.com/gitlab-org/gitlab/issues/9187) (Approval jobs)
- [gitlab#26019](https://gitlab.com/gitlab-org/gitlab/issues/26019) (Evidence collection)
- [gitlab#36665](https://gitlab.com/gitlab-org/gitlab/issues/36665) (Production Access Policies)
 
### Ongoing efforts to support
 
@@ -113,4 +116,4 @@ moment however this only works with GKE so ultimate user adoption is limited. As
keeping an eye on adoption, but have not yet implemented an MVC.
 
Blackout periods ([gitlab#24295](https://gitlab.com/gitlab-org/gitlab/issues/24295))
will help compliance teams enforce periods where production needs to remain stable/not change.
will help compliance teams enforce periods where production needs to remain stable/not change. We are beginning to research blackout period relevancy and if you are interested in participating in research tune into [gitlab#146](https://gitlab.com/gitlab-org/ux-research/issues/146).
source/direction/release/review_apps/index.html.md
+ 7
− 2
View file @ f6f8eceb
@@ -28,10 +28,12 @@ are more than welcome.
## What's Next & Why
 
Next up we will provide several mechanisms to make it easier to clean up environments. We
understand that environments tend to grow exponentially and it is a burden to mantain them:
understand that environments tend to grow exponentially and it is a burden to maintain them:
* Adding an expiration time for environments ([gitlab#20956](https://gitlab.com/gitlab-org/gitlab/issues/20956))
* Provide a mechanism to clean stale environments ([gitlab#19724](https://gitlab.com/gitlab-org/gitlab/issues/19724))
 
We recently conducted research around Review apps and have collected valuable user insights on improvements needed to make Review Apps loveable. We encourage you to comment and contribute to this [epic](https://gitlab.com/groups/gitlab-org/-/epics/2251).
## Maturity Plan
 
This category is currently at the "Complete" maturity level, and
@@ -61,17 +63,20 @@ to clean them up. There are two main items that look to address this challenge:
 
- [gitlab#20956](https://gitlab.com/gitlab-org/gitlab/issues/20956) builds in an expiration date for review apps, beyond which they will automatically be terminated.
- [gitlab#19724](https://gitlab.com/gitlab-org/gitlab/issues/19724) (also the #2 customer issue) implements a way to clean up environments that either did not have an expiration date or were not terminated for other reasons.
## Top Customer Issue(s)
 
The top customer issue impacting users of Review Apps is [gitlab#20956](https://gitlab.com/gitlab-org/gitlab/issues/20956)
which sets an expiration date for an environment.
## Top Internal Customer Issue(s)
 
In some cases after a review app is not availiable for a specific MR
In some cases after a review app is not available for a specific Merge Request
([gitlab#10733](https://gitlab.com/gitlab-org/gitlab/issues/10733)), adding some
information to the user as to what action needs to be done in order to resolve this and
taker action directly from the MR itself, would help not only our customers,
but also our own developers.
## Top Vision Item(s)
 
Our focus for the vision is to bring Review Apps to mobile workflows via
source/events/commit/index.html.haml
+ 4
− 4
View file @ f6f8eceb
---
title: GitLab Commit 2019
description: "GitLab Commit 2019: GitLab’s premier user conference"
title: GitLab Commit 2020
description: "GitLab Commit 2020: GitLab’s premier user conference"
image_title: '/images/events/gitlab-commit/gitlab-commit-header.png'
layout: default
suppress_header: true
@@ -75,7 +75,7 @@ extra_js:
.tab-content
.tab-pane.active{ id: 'schedule-sanfrancisco', role: 'tabpanel' }
.row.u-margin-top-sm.u-margin-bottom-sm
%h5.text-center Coming soon. Stay tuned!
%iframe{ src: 'https://gitlabcommit2020sf.sched.com/' }
 
 
.row.js-in-page-nav-section#past
@@ -89,4 +89,4 @@ extra_js:
= partial "/includes/events/commit/2019/sponsors"
 
 
= partial "/includes/events/commit/2019/eventbrite-widgets"
\ No newline at end of file
= partial "/includes/events/commit/2019/eventbrite-widgets"
source/events/commit/sanfrancisco/index.html.haml
+ 13
− 23
View file @ f6f8eceb
---
title: GitLab Commit 2019
description: "GitLab Commit 2019: GitLab’s premier user conference"
title: GitLab Commit 2020
description: "GitLab Commit 2020: GitLab’s premier user conference"
image_title: '/images/events/gitlab-commit/gitlab-commit-header.png'
layout: default
suppress_header: true
@@ -31,18 +31,13 @@ extra_js:
%h2.u-text-brand{ style: "display: none" } Attend
.row
.container
.u-margin-top-md.u-padding-bottom-sm.text-left
.u-margin-top-sm.u-padding-bottom-sm.text-left
%h2.u-text-brand.text-center Attend
%ul.compare-tabs.dark-tabs.attend-tabs.text-center{ role: "tablist" }
%li{ role: "presentation" }
%a{ 'data-target' => '#attend-london', 'data-toggle' => 'tab', 'aria-controls' => 'attend-london', role: 'tab', href: "#attend-london" }
London
%li.active{ role: "presentation" }
%a{ 'data-target' => '#attend-sanfrancisco', 'data-toggle' => 'tab', 'aria-controls' => 'attend-sanfrancisco', role: 'tab', href: "#attend-sanfrancisco" }
San Francisco
.tab-content
.tab-pane{ id: 'attend-london', role: 'tabpanel' }
= partial "/includes/events/commit/2019/attend-london"
.tab-pane.active{ id: 'attend-sanfrancisco', role: 'tabpanel' }
= partial "/includes/events/commit/2019/attend-sanfrancisco"
.container
@@ -60,16 +55,10 @@ extra_js:
%h2.u-text-brand Featured Speakers
%h5.subtitle Our lineup will continue to grow, so please check back for more details.
%ul.compare-tabs.speakers-tabs.text-center{ role: "tablist" }
%li{ role: "presentation" }
%a{ 'data-target' => '#speakers-london', 'data-toggle' => 'tab', 'aria-controls' => 'speakers-london', role: 'tab', href: "#speakers-london" }
London
%li.active{ role: "presentation" }
%a{ 'data-target' => '#speakers-sanfrancisco', 'data-toggle' => 'tab', 'aria-controls' => 'speakers-sanfrancisco', role: 'tab', href: "#speakers-sanfrancisco" }
San Francisco
.tab-content
.tab-pane{ id: 'speakers-london', role: 'tabpanel' }
.row.u-margin-top-sm.u-margin-bottom-sm
= partial "/includes/events/commit/2019/speakers-london"
.tab-pane.active{ id: 'speakers-sanfrancisco', role: 'tabpanel' }
.row.u-margin-top-sm.u-margin-bottom-sm
= partial "/includes/events/commit/2019/speakers-sanfrancisco"
@@ -80,23 +69,24 @@ extra_js:
.u-margin-top-sm
%h2.u-text-brand.text-center Schedule
%ul.compare-tabs.dark-tabs.schedule-tabs.text-center{ role: "tablist" }
%li{ role: "presentation" }
%a{ 'data-target' => '#schedule-london', 'data-toggle' => 'tab', 'aria-controls' => 'schedule-london', role: 'tab', href: "#schedule-london" }
London
%li.active{ role: "presentation" }
%a{ 'data-target' => '#schedule-sanfrancisco', 'data-toggle' => 'tab', 'aria-controls' => 'schedule-sanfrancisco', role: 'tab', href: "#schedule-sanfrancisco" }
San Francisco
.tab-content
.tab-pane{ id: 'schedule-london', role: 'tabpanel' }
.row.u-margin-top-sm.u-margin-bottom-sm
%iframe{ src: 'https://gitlabcommit2019london.sched.com/' }
.tab-pane.active{ id: 'schedule-sanfrancisco', role: 'tabpanel' }
.row.u-margin-top-sm.u-margin-bottom-sm
%h5.text-center Coming soon. Stay tuned!
%iframe{ src: 'https://gitlabcommit2020sf.sched.com/' }
.row.js-in-page-nav-section#past
.col-md-10.col-md-offset-1.text-center
%h2.u-text-brand{ style: "display: none" } Past Events
%h2.u-text-brand Past Commit Events
= partial "/includes/events/commit/2019/past-commits"
 
 
.row.u-margin-top-md.js-in-page-nav-section#sponsor
.row.js-in-page-nav-section#sponsor
= partial "/includes/events/commit/2019/sponsors"
 
 
= partial "/includes/events/commit/2019/eventbrite-widgets"
\ No newline at end of file
= partial "/includes/events/commit/2019/eventbrite-widgets"
source/events/gitlab-contribute/index.html.haml
+ 3
− 3
View file @ f6f8eceb
---
title: GitLab Contribute
description: "Contribute is our annual GitLabber community event. We get together to get face time with one another, build community, and get some work done! Since our team is scattered all over the globe, we try to plan a different location for each GitLab Contribute."
description: "Contribute is our annual GitLabber community event. We get together to get face time with one another, build community, reinforce our values, and get some work done! Since our team is scattered all over the globe, we try to plan a different location for each GitLab Contribute."
image_title: '/images/events/gitlab-commit/gitlab-commit-header.png'
layout: default
suppress_header: true
@@ -32,7 +32,7 @@ extra_js:
.container
.u-margin-top-md
%h2.u-text-brand Timelines
%p The registration portal will open October 29. At that time, you'll be able to book travel, express rooming preferences, extended stay preferences, suggest workshops, and express interest in excursions. <b>Please refrain from booking any travel prior to registration opening; we're working on a more seamless solution for flights and transportation this year</b>. On the last day of every month, we'll send out a newsletter to the team with updates on the event and tips on how to prep. Questions? Please feel free to reach out to <a href="mailto:contribute@gitlab.com">contribute@gitlab.com</a>.
%p You'll have 30 days from the time you receive the registration email to register for Contribute and book flights. On the last day of every month, we'll send out a newsletter to the team with updates on the event and tips on how to prep. Questions? Please feel free to reach out to <a href="mailto:contribute@gitlab.com">contribute@gitlab.com</a>.
 
%h3 Sample agenda
%p <em>Details subject to change slightly</em>
@@ -98,7 +98,7 @@ extra_js:
.container
.u-margin-top-md
%h2.u-text-brand Ambassadors and volunteers
%p Want to nominate yourself or someone else to be a Contribute Ambassador? <a href="https://docs.google.com/forms/d/e/1FAIpQLSf_mGw8eahy3XfTZfrnUTuXlqm9bdeF52Gp8fU6pUceTlW_-A/viewform">Submit this form</a>. Warning: Being an Ambassador is not for the faint of heart. You'll experience Contribute more from the perspective of the organizers, rather than as an attendee. It can be very rewarding, and we love your help, but if you love your sleep, this might not be the best fit for you, considering Ambassadors will help 1,200 attendees! Still want to help out, but don't have the bandwidth to dedicate your entire time to organizing? Please consider becoming a volunteer and complete <a href="https://docs.google.com/forms/d/e/1FAIpQLSf_mGw8eahy3XfTZfrnUTuXlqm9bdeF52Gp8fU6pUceTlW_-A/viewform"> this form</a>.
%p <a href="https://gitlab.com/gitlab-com/marketing/contribute/contribute-2020/blob/master/Contribute-Ambassadors.md">Contribute Ambassadors</a> assist the Contribute event team with a plethora of tasks while the rest of the company can focus on building bonds, having a good time, and contributing to the GitLab community. Volunteers assist Ambassadors in executing tasks, such as Team Day planning, excursions, and workshops. To volunteer at Contribute, please complete <a href="https://docs.google.com/forms/d/e/1FAIpQLSf_mGw8eahy3XfTZfrnUTuXlqm9bdeF52Gp8fU6pUceTlW_-A/viewform">this form</a>.
 
.row.js-in-page-nav-section#about
.container
source/handbook/CHANGELOG.html.md
+ 170
− 319
View file @ f6f8eceb
This diff is collapsed.
source/handbook/alliances/integration-instructions/index.html.md 0 → 100644
+ 77
− 0
View file @ f6f8eceb
---
layout: markdown_page
title: "Integrate with GitLab"
description: Learn about integrating with GitLab, as well as partnership, marketing, and licensing opportunities.
---
## On this page
{:.no_toc}
- TOC
{:toc}
## Instructions for getting listed as a GitLab Technology Partner
Once the product integration has been completed, the next step is to submit a Merge Request to get listed on our [Partners page](https://about.gitlab.com/partners/). To add your app, you will need:
* A URL page with details on the integration
* A link to the technical documentation on the steps required to set it up. A Screencast / video walk through is highly preferred.
* A short description of the integration (up to 314 characters)
* Listed name for the integration on the applications page
* Your logo
> **Picture Requirements**
> * Crop image to a perfect square.
> * Keep maximum dimension under 400 by 400 pixels.
> * Use the JPEG (`.jpg`) or PNG (`.png`) format.
> * Name file `company_name_in_lowercase` and add the appropriate file extension.
## Adding your app to our Partners Page
Once you have the above items, follow these steps to add yourself to the Partners page:
1. Sign into gitlab.com and navigate to the home project of www.gitlab.com found [here](https://gitlab.com/gitlab-com/www-gitlab-com). Click on the **’Fork’** button at the top right to make a copy of the repository within your account.
2. Next, click on the **’Web IDE**’ button to make changes to specific YAML files.
3. Navigate to the ‘/data’ directory in the left pane and you will see the `applications.yml` file within the folder. Click on the file to open it within the WebIDE. Add the following fields to the correct category of the file and enter the following application information into each of the blank fields:
```yaml
- title: Company Name
content: Description
links:
- url: Company URL
title: Company Name
- url: Technical documentation URL
title: Company Name for GitLab
```
Choose the app's category accordingly. The code block is to be added **to the end** of the category list it belongs to.
**Notes**:
* Write in sentence case, using capital letters for the beginning of the sentences, product names, method names, and feature names.
* Always write GitLab with a capital G and L.
* Respect the YAML file's indentation.
* Avoid special characters, particularly colons and quotes, otherwise they may need to be manually escaped to not break the YAML syntax.
4. After updating `applications.yml`, use the file browser on the left side of the screen to navigate to `source/images/applications/apps/`.
5. Click the `⋁` icon next to the `apps` directory, select upload file, and upload you company logo. Be sure to follow the picture requirements listed above and confirm that the file name matches your `picture` entry in `applications.yml`.
>**Note:** The image name should match the application title exactly. For example, if your app is titled ‘GitLab Inc’ then the image name being uploaded would be ‘gitlab_inc.png’ and it will then map to your app listing when the site is generated.
6. Once you have finished this, click the `Commit` button in the bottom left. It should say something like `2 unstaged and 0 staged changes`. This will bring up a sidebar with an `Unstaged` and `Staged` area.
7. Check the files to ensure your updates are what you expect. If they are, click the check mark next to the filename to "stage" these changes.
8. Once you have verified all of the edits, enter a short commit message including what you've changed. Choose `Create a new branch`. Name the branch in the format of `CompanyName-partners-page` or similar. Tick the `Start a new merge request` checkbox. Then click `Commit` once more.
9. A new merge request will then initiate and you will be able to fill out a description and details around the MR. Select the ‘Applications’ template and fill out the information accordingly.
10. When you have filled out the merge request details. **Please ensure you tick the box to `Allow commits from members who can merge to target branch` as detailed on the [Allow collaboration on merge requests across forks](https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html#enabling-commit-edits-from-upstream-members) page in our docs.**
> Make sure when submitting the MR, the source is the branch that was just created from the MR and the destination/target is the `gitlab-com/www-gitlab-com/`.
11. Once the MR is created, use the Application template and complete the instructions.
## If you’d like to do further development
Open an issue in the [Alliance project](https://gitlab.com/gitlab-com/alliances/alliances) requesting a joint private project in the Alliance group.
* Review the checklist items on what needs to be done
* Share your GitLab username and your SEs as well. You will both be able to create sandbox projects for anyone wanting to get technical and hands-on experience.
This gives our partners a home base for testing integrations, workflows and a place to create any public-facing demos. Initially, it will be set to private, but once there is content in the projects, we can always switch the project to public.
We will need a list of the email addresses that were used to create a GitLab.com account. Within your group you'll be able to create projects and repositories for any development/testing.
## Questions?
We are here to help. The Alliance team works from issues and issue boards. If you are needing our assistance with any project, please [open an issue](http://gitlab.com/gitlab-com/alliances/alliances/issues/new) and we’ll get back to you as soon as we can! When creating an issue, please select *new_partner* issue template in the drop down. If it’s technical assistance you’re looking for, please see below for troubleshooting.
## Troubleshooting
We're always here to help you through your efforts of integration. If there's a missing API call from our current API, or you ran into other difficulties in your development please feel free to create a new issue on the [Community Edition issue tracker](https://gitlab.com/gitlab-org/gitlab-foss/issues) and apply the `Ecosystem` label.
source/handbook/benefits/inc-benefits-us/index.html.md
+ 16
− 1
View file @ f6f8eceb
@@ -236,6 +236,8 @@ Dental is provided by Cigna, plan: DPPO.
 
Dental does not come with individualized insurance cards from Cigna, although you can download them by setting up a Cigna account through https://my.cigna.com. Lumity's site will house individualized ID cards team members can access at any time. For the most part, dental providers do not request or require ID cards as they look up insurance through your social security number. If you need additional information for a claim please let People Ops know. Cigna'a mailing address is PO Box 188037 Chattanooga, TN, 37422 and the direct phone number is 800-244-6224.
 
When submitting a claim, you can mail it to Cigna Dental PO Box 188037 Chattanooga, TN, 37422 or fax it to 859-550-2662.
### Dental 2019 and 2020 Calendar Year Plan
 
Please note there are no changes to our dental plan from Calendar Year 2019 to Calendar Year 2020
@@ -269,6 +271,8 @@ The following costs are monthly rates which would be deducted from your paycheck
 
Vision is provided by Cigna.
 
When submitting a claim, you can mail it to Cigna Vision PO Box 385018 Birmingham, AL 35238 or fax it to 859-550-2662.
### Vision 2019 and 2020 Calendar Year Plan
 
Please note there are no changes to our dental plan from Calendar Year 2019 to Calendar Year 2020.
@@ -343,7 +347,18 @@ The company offers a 401k plan in which you may make voluntary pre-tax contribut
GitLab offers matching 50% of contributions on the first 6% with a yearly cap of 1,500 USD. All employer contributions are pre-tax contributions. Team members can still make Roth team member contributions and receive pre-tax employer contributions.
 
**Vesting:**
The employer match has a four year vesting schedule with a one year cliff based on hire date. Once the team member reaches their 5th year of service employer contributions will be 100% vested. _Employee_ contributions are the assets of those team members and are not applicable to this vesting schedule.
Employer contributions vest according to the following schedule:
| Years of Vesting Service | Vesting Percentage |
|--------------------------------------|:------------------:|
| Less than One Year | 0% |
| One Year but less than Two Years | 25% |
| Two Years but less than Three Years | 50% |
| Three Years but less than Four Years | 75% |
| Four or More Years | 100% |
*Employee* contributions are the assets of those team members and are not applicable to this vesting schedule.
 
**Administration of the 401(k) Match:**
* The employer will use the calculation on each check date effective as of January 1, 2019.
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