GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsGitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpshello-bar
)GitLab's Marketing Website (about.gitlab.com) is led by the Inbound Marketing Team and anyone can contribute. Please visit the repo to file issues and make merge requests.
The DRI for the the Marketing Website is Danielle Morrill, and internal GitLab team members can drop questions in Slack at #website
Specific targets can be found here
Serve the needs and interests of our key audiences:
Generate demand for GitLab by:
The GitLab marketing website, or simply the "GitLab Website" refers to all of the content on https://about.gitlab.com
except the blog and handbook.
The website does not include
docs.gitlab.com
gitlab.com
about.gitlab.com/handbook
about.gitlab.com/blog
See Where should content go? to learn which web property is the most appropriate place to put different types of content. To learn what section of the website different content belongs see definitions.
The Growth Marketing team supports the design, development, and strategic integration of the following pages with content from Strategic Marketing. You can see the performance of these pages in the Strategic + Growth Marketing dashboard.
about.gitlab.com/devops-tools/
about.gitlab.com/solutions/
about.gitlab.com/learn/
about.gitlab.com/stages-devops-lifecycle/
about.gitlab.com/customers/
about.gitlab.com/analysts/
A topic is an industry trend, theme, or technology related to GitLab and our customers. For example, DevOps, GDPR, Containers, etc. Topic pages on our website educate the reader about the topic and share GitLab’s point of view while providing additional links to resources related to that topic. These pages are intended to attract search traffic.
Topic pages should exist at the root level of the website without being nested inside of another directory. e.g. /continuous-integration
Examples of other companies who have topic pages:
A solution is a combination of products and services that solve a business problem. For example, accelerating software delivery, enabling remote teams, ensuring compliance, etc. Solution pages on our website show the application of GitLab capabilities and services to address a business problem while providing additional links to resources related to that solution.
Solution pages should be nested inside of the solutions directory. e.g. /solutions/continuous-integration
Examples of other companies who have solutions pages:
The product section of our website has pages that describe what GitLab does and the value provided. The functionality of GitLab is ordered in a hierarchy with 4 levels: Stage, Categories, Capabilities, and Features. You can find details on the Product Categories Handbook
Category pages should be nested inside of the product directory. e.g. /product/continuous-integration
Examples of companies who have product/features pages: https://mailchimp.com/features/ https://www.groovehq.com/features
There are two comparison sections on our website, /compare/
and DevOps tools.
The DevOps tools section provides an in-depth, feature by feature comparison of GitLab and our competitors. Pages in the DevOps tools section are maintained by the Competitive Intelligence team, which is part of the Strategic Marketing team.
Pages in /compare/
are shorter and focused on a single Call to Action that offers relevant resources to visitors arriving via paid advertising. Pages in /compare/
are maintained by Growth Marketing team and Marketing Program Managers.
Examples of companies who have comparison pages: https://postmarkapp.com/compare/sendgrid-alternative https://www.zendesk.com/support/features/zendesk-vs-intercom/
Similar content can appear as a topic, solution, and in the product section with different emphases on each page. For example continuous integration:
/continuous-integration
would talk about what CI is at a functional level./solutions/continuous-integration
. would talk about why CI is important for businesses to adopt./product/continuous-integration
would talk about the capabilities and features that are part of GitLab's CI functionality and the value it has.Everyone can contribute to the marketing website. While the Strategic Marketing and Inbound Marketing teams have primary responsibility over the website, the goal of these teams is to build systems, structures, and processes and empower everyone to contribute. Below is a breakdown of the ownership between Strategic Marketing and Pipe-to-Spend.
HP
for the homepage. If you have an update to any of the pages in the Doing
column contact @lbanks. More details on CRO and testing in the Online Growth Handbook sectioncta-btn
in their class. looks for this value to fire Google Analytics events and without it we won't be able to see how visitors interact with our CTAs.If your team is unable to update the marketing website, or you need additional levels of support from the Digital Experience team who are responsible for about.gitlab.com
, then this section is for you.
Requests should be made with sufficient lead time to process the request, allocate resources, iterate, and produce related items.
The time needed for your webpage request will vary on a number of factors, including, but not limited to:
Please fill out one of these Issue Templates to request support. Please note that if these are not filled out then we won't have the information needed to support your request.
Use consistent language across the site when naming links, page names, directory names, page titles, etc. If you see inconsistent language, log an issue to correct. We use american english on the site. Here are some examples below. If in doubt, ask in the #marketing
slack channel for language help.
Do use nouns when appropriate
/product/
/community/
/events/
Do use the imperative tense as much as possible
Don't use noun forms of verbs
Don't use present participle ("ing" words)
Nouns may end in "ing"
Use MVCs to update the website. Create new pages and add the minimal amount of viable content. You can add images and more content in iterative steps.
All pages should use lowercase URLs to help avoid unintentional errors when linking to pages on about.gitlab.com.
We have 10-20 seconds to tell visitors why they should stay on our pages. Tell visitors what value the page will give them. Start with a high-level summary opening the page. This could be as simple as a single sentence, but we shouldn’t put the burden of discovering the value of the page on visitors.
The page title and URL should include keywords visitors might use to discover the page you’re creating. If you’re not sure what terms a visitor might use, ask the Growth Marketing team for suggestions in your Merge Request. We have a list of high priority topics and recommended keywords to use.
Below, view a video that shows a typical workflow to update the website.
In the GitLab Unfiltered video below, Sarah D., marketing operations manager at GitLab, shows Wil S., social marketing manager at GitLab, how to add a new page to your section of the handbook complete with a new main page and table of contents.
To create a new page you for follow these steps:
WIP:
.sites
folder. This is where webpages are stored.marketing
directory. If these is an update to the handbook, select the handbook
directory. Once you have selected the site where you would like to make the change, choose the directory where you want your webpage to be. For example, if you put a page in the marketing
folder it will show up at the "root" level, if you create the new directory inside of another directory it will appear at that path.New directory
from the plus sign drop down.solutions
directory and inside the solutions
directory create a new directory called cloud-native
.New file
from the plus sign drop downindex.html.md
---
layout: markdown_page
title: ""
---
## Subheading
Here is your first paragraph replace this text.
index.html.md
and .gitkeep
. Delete the .gitkeep
file. This is a placeholder file from when you created the directory since git cannot track empty directories. A quick way to delete the file on the correct branch is to click on "edit" in the changes tab of your MR. This will open the file editor. click "cancel" and dismiss the popup that says "all changes will be lost". This will then place you in the file view for the .gitkeep
file on your branch. Click the "delete" button to delete the file./product
, /solutions
, /pricing
or any pages related to your page.If you are seeking assistance or need the attention of the website team, please include @gl-website in the issue description to ensure the website team sees it. The @gl-website handle is a group in GitLab that the website team uses to be notified of issues and merge requests from others. For community contributed merge requests, this happens automatically with gitlab-bot and you should see an automated message saying that the website site has been notified of your merge request.
How to create an analyst report page in 5 not-so-easy steps.
analyst_reports.yml
- https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/analyst_reports.yml- url: gartner-aro19
title: "Gartner Application Release Orchestration Report"
subtitle: "Gartner Cites GitLab as a Challenger in MQ for ARO"
resource_link: /resources/gartner-aro/
include_file: /analysts/includes/gartner-aro19
/analysts/includes/<url>
<analyst>-<report><year>
. Make a note of this url
as you'll need it later a few times throughout the process.#
at the beginning of the line. You need to coordinate with MPM to create a landing page to download the report to use as the resource link.</>
/sites/marketing/source/analysts/includes/
plus the file name for the report you are adding using the .html.md
file extension. <analyst>-<report><year>.html.md
/sites/marketing/source/analysts/includes/gartner-eapt20.html.md
/images/analysts/
folder.source
folder, then the images
folder, then the analysts
folder. This is kinda tricky because you have to scroll past a lot of folders to find the one you want. The folders are in alphabetical order.analysts
folder and click on the drop down and select “Upload file”. This is an important step. If you upload the file to a different folder then the image won’t show up on the page./sites/marketing/source/includes/forrester-reports.html.haml
file. Open it in the WebIDE.forrester-waves-container
This is a tricky step because the indentation needs to be exactly the same as the other sections. When you copy you need to copy all the spaces indenting the line. When you paste, be sure to paste with your current not indented at all. This should give you the same spacing. For example: <!–– Gartner ARO 2019 ––>
.forrester-wave-row
.wave-row-content
= image_tag "/images/analysts/gartner-app-release.jpg", class: "forrester-wave-graphic", alt: "GitLab Cloud CI Forrester Wave thumbnail png"
.wave-row-content
%img.gartner-logo{ src: "/images/home/gartner-logo.svg", alt: "Gartner logo svg" }
.text-center.forrester-graphic-title
%p ARO Report
%p Gartner Cites GitLab as a Challenger in MQ for ARO
%a.btn.cta-btn.accent.margin-top20.reports-include-button-aro{ href: '/analysts/gartner-aro19/' } Read more
,
.wave-row-content, or
.text-center.forrester-graphic-title`. The phrases that start with a dot are CSS classes, so if you edit them the page will be formatted strangely..haml
file. You should only ever need to edit .md
and .yml
files.)= image_tag
line. Here you need to reference the image file that you uploaded in the previous step. The image file name here needs to exactly match what you named the file when you created it. It should be “kabaob case” - all lowercase letters with dashes instead of spaces.haml
, or possibly in a separate .yml
file that populates fields in the haml
file. The hello bar is an example of content in a .yml
file.Great care should be taken whenever moving pages on the website. Ideally, pages should never be moved without implementing an immediate 301 redirect.
The Inbound Marketing team can follows this process to create 301 redirects.
If you need to rename a page (e.g. change /company/culture/all-remote/part-remote
to /company/culture/all-remote/hybrid-remote
, as was achieved in this merge request), follow the below steps if using Web IDE.
redirects.yml
.
data/redirects.yml
. Define "sources", "target", and "comp_op" like so: - sources:
- /company/culture/all-remote/part-remote/
- /company/culture/all-remote/part-remote
target: /company/culture/all-remote/hybrid-remote/
comp_op: '='
When adding an image to a webpage, be sure that you optimize the image first.
team.yml
team.yml
and create an MRslug
and reports_to
lines.hello-bar
)/source/includes/hello-bar.html.haml
.Categories and stages are defined in the product handbook. Stages are stored in data/stages.yml
and categories are stored in data/categories.yml
as the single source of truth for engineering and marketing.
These two files power various parts of the website including the homepage, product pages, and product categories handbook.
They are also used by the automated triage operation "Stage and group labels inference from category labels".
Below are attributes that can be added to a stage in data/stages.yml
. Each of these properties is accessed via stages.<stage_key>.foo
display_name
: the name of the Stage in sentence casepm
: the PM leader for this stagemarketing
: boolean, whether or not the stage is a "marketed" stage and should be displayedtw
: boolean, if supported by technical writingimage
: the logo for the stagedescription
: a short description of what the stage coversbody
: a longer-form description of what the stage coversdirection
: where the direction page can be located (ex: /direction/foo
)roadmap
: a URL to where the roadmap for the stage can be foundestablished
: the year the stage was established (ex: 2020
)lifecycle
: integer (1-7), where the stage falls in the devops lifecycleusage_driver_score
:the Product Usage Driver score, used on /handbook/product/investmentrevenue_driver_score
:the Revenue Driver score, used on /handbook/product/investmentsam_driver_score
:the Service Addressable Market score, used on /handbook/product/investmentstage_development_spend_percent
:analyst_reports
: a list of links to relevant analyst reports
analyst_reports.title
: the title of the reportanalyst_reports.url
: the URL of the reportrelated
: the stages related to this stagesection
: the section this stage belongs togroups
: a list of groups that belong to this stage. definitions for their properties belowBelow are attributes that can be added to a group in data/stages.yml
. Groups are defined in the groups
property of a stage. Each of these properties is accessed via stages.<stage_key>.groups.<group_key>.foo
name
: the name of the Group in sentence casefocus
:pm
: the Product Managerpmm
: the Product Marketing Managercm
: the Content Marketerbackend_engineering_manager
: the Backend Engineering Managerfrontend_engineering_manager
: the Frontend Engineering Managersupport
: the Support Engineerpdm
: the Product Design Managerux
: a list of Product Designersuxr
: the User Experience Researchersets
: a list of Software Engineers in Testtech_writer
: the Technical Writertw_backup
: the "backup" Technical Writerappsec_engineer
: the Application Security Engineerbe_team_tag
: the "tag" being used in the department
field in team.yml
for Backend Engineers on this teamfe_team_tag
: the "tag" being used in the department
field in team.yml
for Frontend Engineers on this teamcs_team_tag
: the "tag" being used in the department
field in team.yml
for Customer Success on this teaminternal_customers
: a list of internal customers/stakeholders for this groupinternal_customers.department
: the name of the internal customerinternal_customers.dri
: the DRI assigned for this relationshipusage_driver_score
: the Product Usage Driver score, used on /handbook/product/investmentasp_driver_score
: the ASP score, used on /handbook/product/investmentsam_driver_score
: the Served Addressable Market score, used on /handbook/product/investmentpi_gmau
: A link to the dashboard that displays GMAU for this grouppi_pgmau
: A link to the dashboard that displays Paid GMAU for this groupanalyst_reports
: A link to a location where relevant analyst reports are availablecomp_comparison
: A link to a location where comparisons with competitive products are availablecategories
: a list of categories that are owned by this group. definitions for their properties belowBelow are attributes that can be added to a category in data/categories.yml
. Each of these properties is accessed via categories.<category_key>.foo
.
name
: the name of the category in quotesstage
: what stage the category belongs to.label
: The category label in the gitlab-org
group.
By default, the category label is inferred from its name.
For instance, the Code Analytics
category is represented by the
Category:Code Analytics
label in the gitlab-org
group.
This attribute allows to override that.
For instance, the gitlab-org
label for the Kanban Boards
category is Category:Issue Boards
.feature_labels
: A list of all the feature labels that are associated with this category.
This list is used in the automated triage operation "Stage and group labels inference from category labels".marketing_page
(optional): the path of marketing page for the category. If you include a body
section, then a marketing page will be auto-generated at /product/${lowercase-category-name}
documentation
(optional): the URL of the docs page for the category, required if the category maturity is minimal or above.direction
(required): the URL of the category direction page. Optionally could be the URL of an issue, epic, or issue label search query if a direction page has not yet been created.description
: a short description of the category.roi
: true | false
should this category appear in the ROI calculator. (omitting the line is the same as false
)percent_of_focus
: A value of 0-1
detailing the percent of the group this category is assigned to's focus on this category in terms of developing improvementsavailable
: an ISO date for when the feature was or will be available.viable
: an ISO date for when the category will/did move from minimum to viable on the maturity handbook page.complete
: an ISO date for when the category will/did move from viable to complete on the maturity handbook page.lovable
: an ISO date for when the category will/did move from complete to loveable on the maturity handbook page.maturity
: the current maturity of the category on the maturity handbook page. Valid values are planned
, minimal
(available), viable
, complete
, and lovable
. Provided marketing = true
, a value of planned
will cause the category to appear in the "coming soon" section of the homepage, while other values will cause it to appear in the "Since 20XX GitLab added" section.marketing
: A value of true
will cause this category to appear on our marketing pages, in addition to our handbook. For the home page, a maturity
state is also required. Internationalizaion is a good example of a category the engineering team works on, but is not a "customer-facing category" that appears on marketing pages.body
: content added in markdown will be auto-generated and turned into a page at /product/<category>/
. Features and missing features sections are automatically added to the generated category pages based on what category a feature belongs to in features.yml
. c.f. Project Management (and auto-generated page from the body
section in categories.yml
) with Continuous Integration (a custom page.)opportunity
: values can be Core
, Adjacent
, Distant
- is this category considered part of our existing Core
DevOps platform, a directly Adjacent
set of capabilities or a Distant
vision for future breadth.differentiation
: values can be Winning
,Compelling
,Minimal
- is this category sufficiently differentiated from competitors to be considered capable of consistently winning
, providing an compelling
additive component to our single platform value or adding only minimal
differentiated value.ux_scorecard_score
: value should be a letter score, following the grading rubricux_scorecard_link
: should link to the specific issue for the scorecard for this category. More details on UX Scorecards heredogfooding_status
: values can be planned
, limited
, and exclusive
. Described in detail and used on /source/direction/dogfooding
dogfooding_issue
: should link to the specific issue tracking dogfooding for this issue, per the Dogfooding processThere are five fields in categories.yml
that control a category's maturity. These work together to define what the maturity currently is, how it has evolved over time, and our plans to improve in the future.
maturity
which represents the current maturity of the categoryavailable
, viable
, complete
, and lovable
which are set to ISO dates when we achieved, or plan to achieve, the given maturity.To change or update the current maturity, set the maturity
field to the desired value: planned
(or empty), minimal
(available), viable
, complete
, and lovable
. Next, ensure that the historical and future maturity values are still consistent. For example, if you incremented the maturity of the category from viable to complete, you should also set the field complete
to the date of the GitLab release when it changed.
authentication_and_authorization:
name: "Authentication and Authorization"
stage: manage
documentation: https://docs.gitlab.com/ee/administration/auth/
vision: https://gitlab.com/groups/gitlab-org/-/epics/628
description: "GitLab features multiple auth mechanisms including LDAP (including Active Directory), OmniAuth, CAS, SAML, Okta, and Authentiq."
roi: true
available: 2017-10-01
viable: 2019-05-22
complete: 2019-12-22
lovable:
maturity: minimal
Due to their importance and wide usage throughout the company, changes to Stages, Groups, and Categories need to be reviewed. Open a merge request using the Category-Change
template to get started.
Major changes
Any change to a Stage or Group, or a significant change to a Category, is a major change. Examples of significant category changes include their names, their group membership, and presence on our marketing page.
Due to their impact, executive approval for major changes is required in addition to the PMs, PMMs, and EMs responsible. Follow the approval process defined on the categories page.
Minor changes
Minor changes to Categories are generally routine changes, like updates to maturity and content links. For example, upon shipping an MVC the maturity would change to minimal
, and a link to the documentation would be added.
Approvals should be gathered from the responsible PMs, PMMs, and EMs. Also mention the relevant engineering and product directors, so they are aware of the changes. If changes are included in a release post, ensure the approval team and directors are mentioned on the MR.
To update the responsible person for a role, follow these steps:
data/stages.yml
at the relevant position e.g. pm: John Doe
.sites/handbook/source/includes/product/_categories-names.erb
Here's an example Merge Request.
If the person is not yet listed on the team page, please follow these instructions to add them.
All features and capabilities are listed in a single yaml file
(features.yml
) under the features
section.
It is the single source of truth for multiple pages across the website including:
To add a new feature, add a feature block to under the features:
section of the page. Add the following attributes:
link: https://docs.gitlab.com/ee/user/project/milestones/
screenshot_url: 28-group-milestones.png
Just put the filename of the screenshot. Feature screenshots must go in the following directory: 'images/feature_page/screenshots/'.true
or false
is this feature or capability available in this tier? gitlab_core
, gitlab_starter
, gitlab_premium
, gitlab_ultimate
true
or false
is this feature or capability available on GitLab.com? Because GitLab.com tiers map 1:1 to self-managed tiers setting this will automatically assign the GitLab.com tier. E.g. gitlab_core: true
+ gitlab_com: true
== GitLab.com Free
. Adding a tiers fields is what powers the tier badges on product pages and comparison pages, as well as powers the tier feature comparison of the pricing page.devops_tools:
section such as jira:
, circle_ci:
, blackduck:
, etc. that does or does not have this feature. Holds a value of either true
or false
or partially
or is blank (indicating subfields with details should exist).
true
or false
or partially
: Examples of partially
are if a DevOps tool has some but not all of the feature described, or if they have the feature, but only through a plugin. If using partially
it is highly recommended to instead add details
as to what partially actually means (see next)valid
: Same as true
or false
or paritally
abovedetails
: A short statement about the details that need to be shared. For example: "supports 11 languages", or "only supported through 3rd party plug-ins"true
or false
: this option was created when the pricing page used to be called the "products" page. Setting true cause the feature to show up on the pricing page. Only a limited number of the most important capabilities should be shown on the main pricing page to keep it easily consumable. Folks can click on "see all features" to see the full list of features (self-managed comparison, GitLab.com comparison).For example:
- title: "Group Milestones"
description: "Create and manage milestones across projects, to work towards a target date from the group level. View all the issues for the milestone you’re currently working on across multiple projects."
link_description: "Learn more about Group Milestones"
link: https://docs.gitlab.com/ee/user/project/milestones/
screenshot_url: 'images/feature_page/screenshots/28-group-milestones.png'
solution: plan
category:
- portfolio_management
gitlab_core: true
gitlab_starter: true
gitlab_premium: true
gitlab_ultimate: true
gitlab_com: true
github_com: false
github_enterprise: false
bitbucket_org: false
bitbucket_data_center: false
gogs: false
jira:
valid: true
details: 'only through 3rd party extension'
ca_agile_central: false
Copy and paste this template:
- title: ""
description: ""
link_description: ""
link:
screenshot_url: ''
solution:
category:
-
gitlab_core:
gitlab_starter:
gitlab_premium:
gitlab_ultimate:
gitlab_com:
github_com:
The /devops-tools
section of the website shows info about DevOps tools and a feature comparison of those tools to GitLab. Comparison pages are auto-generated from features.yml
. All you need to do is add a tool to the devops_tools
section and add that tool id to some features and the page will be created.
To add a new comparison page:
features.yml
devops_tools
section add a tool.Although the summary
and include_file
fields are not strictly required by the parser in order to build the page, every tool should have at least one paragraph summarizing the comparison using EITHER the summary
field or the include_file
field (see below for details). summary
only is deprecated. Use include_file
method whenever possible.
travis_ci
)/images/logos/
directory.md
) file that will be embedded on the page. Here is where you can add more robust content about the tool. Please use the template under /source/devops-tools/misc/tool-template.html.md
and store your new file under /source/devops-tools/TOOLNAME/index.html.md
.|
) then add content in markdown indented on the next line. Be sure to add on additional empty line after your content.For example:
With include_file
(preferred method):
jenkins:
name: 'Jenkins'
logo: '/images/devops-tools/jenkins-logo.svg'
category:
- ci
- cd
include_file: devops-tools/jenkins/index.html.md.erb
With summary
(deprecated method):
chef:
name: 'Chef'
logo: '/images/devops-tools/chef.png'
category:
- infrastructure_configuration
summary: |
Chef is a configuration management tool that enables deployment and maintenance of state for large scale infrastructure. Chef excels as managing legacy infrastructure like physical servers and VMs. Chef was designed before widespread container adoption and does not implement Kubernetes natively.
GitLab is a complete DevOps platform, delivered as a single application that includes not only configuration management, but also capabilities for project management, source code management, CI/CD, and monitoring. GitLab is designed for Kubernetes and cloud native applications.
GitLab can be used together with Chef to enable VM and bare metal configuration management. For Cloud Native applications run on Kubernetes, Chef is not required and GitLab can provide all the functionality natively.
Copy and past this template:
unique_tool_id:
name:
logo: '/images/logos/TOOLNAME.png'
category:
-
include_file: 'devops-tools/TOOLNAME/index.html.md'
Be sure to add features that GitLab has that the other tool doesn't and also features the other tool has that GitLab doesn't so that our comparison are transparent and honest (ie. this shouldn't be one sided).
tool id
and then true
, false
, or partially
to indicate support for the feature (what does partially mean?) Add the same details for gitlab tiers. Adding a tool id to a feature is what causes it to show up on the comparison page for that tool. (e.g. if you don't want a feature to show up on a comparison page remove the tool id line from that feature.)For example:
- title: "Free CI/CD with shared or personal Runners"
capability: true
description: "GitLab.com has shared Runners that allow you to use GitLab CI/CD completely free up to 2000 build minutes for private projects and unlimited for public projects. Alternatively, you can set up your own Runner for faster build processing, unlimited build minutes, or special requirements."
link_description: "Explore GitLab.com offerings"
link: /gitlab-com
solution: gitlab_com
gitlab_core: true
gitlab_starter: true
gitlab_premium: true
gitlab_ultimate: true
gitlab_com: true
github_com: false
bitbucket_org: 'partially'
gitlab_ci: true
codestar: false
- title: "Domain Specific Language"
description: "A Domain Specific Language (DSL) for defining infrastructure configuration allows thinking in resources, not files or commands to write declarative rather than procedural code."
# link_description: ""
# link: ''
solution: missing
gitlab_core: false
gitlab_starter: false
gitlab_premium: false
gitlab_ultimate: false
puppet: true
chef: false
/devops-tools/tool-vs-gitlab.html
and you should see it on the
devops-tools table on the main page.The /resources
section of the website contains downloadable files and links to helpful content.
resources.yml
file.resources.yml
:- title:
url:
image: /images/resources/gitlab.png
type: Pick one --> 'Blog post' 'One-pager' 'Report' 'Webcast' 'White paper'
topics:
- Cloud native
- Code review
- Continuous delivery
- Continuous integration
- DevOps
- Git
- GitLab
- On-demand training
- Public Sector
- Security
- Software development
solutions:
- Distributed teams
- Accelerated delivery
- Executive visibility
- Project compliance
- Security and quality
/pdfs/resources/
.The Digital Experience team is incrementally adopting Netlify CMS for the marketing website. It offers a more user-friendly way of editing the marketing site, but comes with some limitations:
Read the Netlify CMS handbook page for up to date directions and status of the system.
As part of GitLab's transparency value, we encourage each GitLab team member to consider adding a README — a great tool for transparently letting others know what it's like to work with you, and how you prefer to be communicated with.
When people are working together for the first time, there's a certain amount of mental and emotional energy exerted in getting to know someone. You're simultaneously doing the work, while trying to confirm or challenge preconceived notions about how a person prefers to be communicated with.
On an individual level, this requires a person to project the ideal version of themselves into each meeting, as it is assumed that this projection is the only meaningful way for another person to understand who they are and how they prefer to communicate and work.
READMEs provide a genuine report on how a person works, reducing bias/assumption and enabling people to work together based on a common framework.
GitLab division README pages are linked below for context. Let these serve as a guide and inspiration as you create your own.
/handbook/marketing/readmes
, creating /handbook/marketing/readmes/dmurph
)readmes
) within your division's handbook section first, then create your username directory within readmes
.Once your README is created, consider adding a link to it in the following places.
This provides maximum visibility to others, so that they may ingest your README in advance of working with you. This allows them to take your working style and communication preferences into account, ideally increasing the overall level of empathy expressed.
READMEs are particularly powerful when working with those outside of GitLab, who may be unfamiliar with our values. A README is a beacon of transparency, and helps set the tone for any working relationship.
For best practices regarding testing and reviewing merge requests, please see our related handbook page for reviewing merge requests.
This is a link to our documentation on how to implement a video band.
Many of our forms are served through a third party tool, Marketo. Sometimes Marketo is blocked by an ad blocker or a strict web browser such as Brave. GDPR and CCPA (among other laws) require us to obtain consent before setting cookies and those cookies are required for many third party functions.
If you are having trouble using a form, please try updating your cookie settings to allow personalization (personal information) cookies. If that does not work, please try a different browser with a less strict adblocker and ensure our domain and subdomains (gitlab.com, about.gitlab.com, and page.gitlab.com) are not blocked.
If you have tried the above solutions but are still having trouble using a form, please file a bug report. Please note that if you do not provide all of the requested information we might be unable to reproduce the bug and therefore unable to fix it.
This is potentially due to cookiebot. Because of how our infrastructure is setup, certain third party content (such as youtube embeds) or advanced javascript may not appear on review apps. If you are unsure of the cause, please contact us so we can help review what might be impacting your project.
If you need to temporarily preview an item in the review app before release, you can try to add the following attribute to the frontmatter of the file: manual_cookiebot: true
. Do not commit that change without removing it before your final merge. Alternately, you can follow this tutorial for steps on how to use developer tools to view a review-app video blocked by cookiebot.
On the about.gitlab.com website we have approval to use the customer logos lisited at the following link, Approved customer logos for promotion
Sometimes a merge train will get stuck in our www-gitlab-com repo pipelines. Please see this related issue for instructions on how to recover a stuck merge train.