Skip to content
Snippets Groups Projects
Commit e55f5f3c authored by Sid Sijbrandij's avatar Sid Sijbrandij
Browse files

Merge branch 'master' into 'patch-261' 

# Conflicts:
#   source/okrs/index.html.md
parents 43348b76 bc4639b5
No related branches found
No related tags found
1 merge request!6348Update index.html.md for CMO
Pipeline #
Hide whitespace changes
Inline Side-by-side
Showing
with 601 additions and 303 deletions
.gitlab/merge_request_templates/Release-Post.md
+ 7
− 1
View file @ e55f5f3c
Release Post :tada:
**Review Apps** link: https://release-x-y.about.gitlab.com/YYYY/MM/22/gitlab-x-y-released/
Release post :rocket:
 
- Blog handbook: https://about.gitlab.com/handbook/marketing/blog/
- Release post handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/
@@ -26,6 +28,10 @@ Due date: MM/DD (6th working day before the 22nd)
 
### Review
 
Ideally, complete the review until the 4th working day before the 22nd,
so that the 3rd and the 2nd working day before the release
could be left for fixes and small improvements.
#### Content review (PMs)
 
Due date: MM/DD (2nd working day before the 22nd)
.gitlab/route-map.yml
+ 4
− 1
View file @ e55f5f3c
@@ -14,6 +14,9 @@
- source: /source\/(.*)\/template\..*/ # source/direction/template.html.md.erb
public: '\1/' # direction/
 
- source: /generators\/direction.rb/
public: 'direction/'
# Other files
- source: /source\/(.*)/ # source/images/blogimages/around-the-world-in-6-releases-cover.png
public: '\1' # images/blogimages/around-the-world-in-6-releases-cover.png
\ No newline at end of file
public: '\1' # images/blogimages/around-the-world-in-6-releases-cover.png
data/events.yml
+ 20
− 0
View file @ e55f5f3c
@@ -168,3 +168,23 @@
location: Los Angeles, CA USA
social_tags: OpenSourceSummit2017
event_url: http://events.linuxfoundation.org/events/open-source-summit-north-america
- topic: USENIX LISA 2017
type: Training, Conference
date: October 29 - November 3 2017
date_ends: November 3, 2017 # Month DD, YYYY
description: |
Our partners at Vertical Sysadmin will be leading a training course on, "Git Foundations: Unlocking the Mysteries and Setting up CI/CD Pipelines." The CI/CD course will cover GitLab CI and Jenkins (the conference wanted a vendor-neutral approach).
location: San Francisco, CA USA
social_tags: LISA17
event_url: https://www.usenix.org/conference/lisa17
- topic: AWS Reinvent
type: Cloud, Conference
date: November 27 - December 1 2017
date_ends: December 1, 2017 # Month DD, YYYY
description: |
AWS re:Invent is a learning conference hosted for the global cloud computing community. The event features keynote announcements, training and certification opportunities.
location: Las Vegas, NV USA
social_tags: AWSreinvent
event_url: https://reinvent.awsevents.com/
data/resellers.yml
+ 50
− 30
View file @ e55f5f3c
#
- name: Creationline
image: /images/resellers/creationline_logo_type-01_CMYK_01.png
region: APAC
content: |
Creationline is Japanese company providing solutions for cloud integration, microservices, IoT, big data, automation, DevOps. We have a wide experience with enterprise customers, and strong relationships with our overseas vendors.
Creationlineはクラウドインテグレーション、マイクロサービス化、IoT、データ解析、インフラ構築・運用などの自動化を実現する技術ノウハウを持つテクノロジスト集団。 国内外の大手通信事業者、データセンター事業者、サービス提供事業者などに対して多くの実績を持っている。 DevOps、マイクロサービスを実現する上で必要な要素となる技術を持つDocker社、Chef社などの海外ベンダーとの強いパイプを持ち、最先端なテクノロジーを国内でスピード感を持って提供することができる数少ない企業である。
email: GitLab@CreationLine.com
contact:
- address: 東京、日本
phone: +81 (03) 5829-8355
- website: http://www.creationline.com/gitlab/
social:
- type: twitter
url: https://twitter.com/creationline
- type: facebook
url: https://www.facebook.com/creationline/
#
- name: Emerasoft
image: /images/resellers/emerasoft.png
region: EMEA
@@ -30,37 +50,37 @@
url: https://gitlab.com/Emerasoft
- type: other
url: https://www.slideshare.net/emerasoft
#
#- name: Fierce Software
# image: /images/resellers/logo_fiercesoftware-horizontal.png
# image: /images/resellers/fierceSW.png
# region: NA
# content: |
#
# Fierce Software is more than a trusted IT solutions provider. Yes, we provide Federal and Commercial
# organizations with information technology and business process solutions, but in order to ensure
# success in today’s IT environments takes much more.
# Our customers have the advantage of working alongside a trusted partner that will help you to identify
# your needs, pinpoint the most innovative technologies and help implement the most effective solutions
# all while keeping your best interests in the forefront of our process.
#
# email: GitLab@FierceSW.com
# contact:
# - address: Ashburn/VA, USA
# phone: +1 (888)576-1572
# - website: https://www.fiercesw.com
# social:
# - type: twitter
# url: https://twitter.com/fierce_software
# - type: linkedin
# url: https://www.linkedin.com/company-beta/3721309/
# - type: facebook
# url: https://www.facebook.com/FierceSoftware/
# - type: youtube
# url: https://www.youtube.com/channel/UCyXXjI4aqn0rV_lKtvcdiLA/featured
# - type: other
# url: http://fiercesw.com/blog
#
- name: Fierce Software
image: /images/resellers/logo_fiercesoftware-horizontal.png
region: NA
content: |
Fierce Software is more than a trusted IT solutions provider. Yes, we provide Federal and Commercial
organizations with information technology and business process solutions, but in order to ensure
success in today’s IT environments takes much more.
Our customers have the advantage of working alongside a trusted partner that will help you to identify
your needs, pinpoint the most innovative technologies and help implement the most effective solutions
all while keeping your best interests in the forefront of our process.
email: GitLab@FierceSW.com
contact:
- address: Ashburn/VA, USA
phone: +1 (888)576-1572
- website: https://www.fiercesw.com/gitlab
social:
- type: twitter
url: https://twitter.com/fierce_software
- type: linkedin
url: https://www.linkedin.com/company-beta/3721309/
- type: facebook
url: https://www.facebook.com/FierceSoftware/
- type: youtube
url: https://www.youtube.com/channel/UCyXXjI4aqn0rV_lKtvcdiLA/featured
- type: other
url: http://fiercesw.com/blog
#
- name: ReleaseTEAM
image: /images/resellers/release-team-logo.png
data/team.yml
+ 0
− 26
View file @ e55f5f3c
@@ -721,16 +721,6 @@
story: |
Amanda began her career as a technical writer and consultant. She went to her first conference in 2011, which is when she decided that she wanted to take a more active role in community building. The rest was history. When she's not on the road, you'll find her nose-deep in a book or wrangling code for some obscure project or another.
 
- name: Ryan Caplin
locality: Orem, UT
country: USA
role: <a href="https://about.gitlab.com/jobs/sales-development-representative/">Sales Development Representative</a> - East Specialist
reports_to: Sales Development Representative Lead
picture: ryan.jpg
twitter:
gitlab: rycap
story: |
Before coming to GitLab, Ryan could occasionally be spotted in the driver’s seat of a recycling truck as co-founder of a recycling startup. His cleaner roles have been in marketing and strategy within a variety of tech and non-tech companies, mostly startups. When the work’s done and the sun’s still out, Ryan is likely to be found shredding the trails on his mountain bike, shooting hoops, or thinking about garbage.
 
- name: Felipe Artur
locality: Goiânia, GO
@@ -1046,22 +1036,6 @@
story: |
John's interest in systems engineering surpassed 'normal' when he amassed a small data center in his house to explore theoretical design scenarios. Passionate about open source and taking his role as a 'unix beard' seriously, John loves to spread the gospel of technology to anyone who will listen. Wearing his Chef hat, and harnessing the magic of ChatOps, he is determined to make things fit into their containers.
 
- name: Marat Kalibekov
locality: Astana
country: Kazakhstan
role: <a href="https://about.gitlab.com/jobs/production-engineer/">Junior Production Engineer</a>
reports_to: Production Lead
picture: marat.png
twitter: maratkalibek
gitlab: maratkalibek
expertise: |
<li>On-call hero!</li>
story: |
Marat is interested in computers since school. He learned how to program from books without any help,
wrote his first programs on paper and typed them in school labs during breaks. This was the reason why
he chosed study Computer Science in university. After graduating from university, he moved to
Astana and worked mostly on government projects. Interested in Programming and Maths.
- name: Alejandro Rodríguez
locality: Santiago
country: Chile
doc/AAAA_MM_DD_gitlab_x_y_released.yml → doc/YYYY_MM_DD_gitlab_x_y_released.yml
+ 5
− 4
View file @ e55f5f3c
@@ -2,13 +2,14 @@
#
# Release post data file
#
# Start the release post with this file, named `AAAA_MM_22_gitlab_X_Y_released.yml`
# Start the release post with this file, named `YYYY_MM_22_gitlab_X_Y_released.yml`
# placed into `data/release_posts/`.
#
# Notes:
# - All description fields support markdown. Make sure the indentation is respected.
# - All description entries support markdown. Use it as you do for a regular markdown file.
# Just make sure the indentation is respected.
#
## Optional fields:
## Optional entries:
#
# - Features
# - Top:
@@ -111,7 +112,7 @@ features:
documentation_link: # webpage or documentation - optional
description: | # supports markdown
Lorem ipsum [dolor sit amet](#link), consectetur adipisicing elit.
Perferendis nisi vitae quod ipsum saepe cumque quia `veritatis`.
Perferendis nisi vitae quod ipsum saepe cumque quia `veritatis`.
 
- name: Performance Improvements
available_in: [ce, ees, eep] # required
generators/direction.rb
+ 17
− 31
View file @ e55f5f3c
@@ -4,7 +4,7 @@ PRIVATE_TOKEN = ENV["PRIVATE_TOKEN"]
 
class GitLabInstance
def initialize(endpoint, private_token, name)
@endpoint = "#{endpoint}/api/v3"
@endpoint = "#{endpoint}/api/v4"
@private_token = private_token
@name = name
end
@@ -35,10 +35,10 @@ class GitLabProject
end
 
def milestones
result = @instance.call("/projects/#{@id}/milestones")
result = result.select { |ms| ms["state"] != "closed" && /^\d{1,}.\d{1,}$/.match(ms["title"])}
result = @instance.call("/projects/#{@id}/milestones?state=active")
result = result.select { |ms| ms["due_date"] }
result.sort_by! do |ms|
ms["title"].split(".").map! {|i| i.to_i}
Date.parse ms["due_date"]
end
end
 
@@ -50,18 +50,8 @@ class GitLabProject
@instance.call("/projects/#{@id}/issues", "?milestone=#{milestone_id}&labels=direction")
end
 
def all_direction_issues
@direction_issues ||= @instance.call("/projects/#{@id}/issues", "?labels=direction&state=opened&per_page=100&sort=asc")
#result << @instance.call("/projects/#{@id}/issues", "?labels=direction&state=opened&per_page=100&sort=asc&page=2")
end
def coming_soon_issues
result = all_direction_issues.select { |issue| issue["labels"].include? "coming soon" }
end
def wishlist_issues(label,not_label=nil)
result = all_direction_issues.select { |issue| issue["labels"].include? label }
result = result.reject { |issue| (issue["labels"].include? "coming soon")}
result = @instance.call("/projects/#{@id}/issues", "?labels=direction,#{label}&state=opened&per_page=100&sort=asc")
result = result.select { |issue| (issue["labels"] & not_label).empty? } if (not_label)
result = result.select { |issue| issue["milestone"].nil? || issue["milestone"]["title"] == "Backlog" }
end
@@ -98,13 +88,13 @@ def generate_direction
 
edition.each do |project|
milestones = project.milestones
direction_output << "## #{project.name}\n\n"
direction_output << "### #{project.name}\n\n"
 
milestones.each do |ms|
if ms["due_date"] && Date.parse(ms["due_date"]) >= Date.today
 
issues = project.milestone_direction_issues(ms["title"])
direction_output << "### [#{ms["title"]}](#{project.web_url}/milestones/#{ms["iid"]}) \n\n"
direction_output << "#### [#{ms["title"]}](#{project.web_url}/milestones/#{ms["iid"]}) \n\n"
 
issues.each do |issue|
direction_output << issue_bullet(project,issue)
@@ -113,16 +103,6 @@ def generate_direction
direction_output << "\n"
end
end
issues = project.coming_soon_issues
if(issues)
direction_output << "### [Coming Soon](#{project.web_url}/issues?label_name[]=coming%20soon)\n\n"
issues.each do |issue|
direction_output << issue_bullet(project,issue)
end
direction_output << "\n"
end
end
print "\n"
 
@@ -139,9 +119,14 @@ def edition
end
end
 
def label_list(label,not_label=nil)
def label_list(label,not_label=nil,editions=nil)
output = ''
edition.each do |project|
if editions.nil?
editions = edition
end
editions.each do |project|
issues = project.wishlist_issues(label, not_label)
issues.each do |issue|
output << issue_bullet(project,issue)
@@ -154,11 +139,12 @@ end
def generate_wishlist
print "Generating wishlist..."
wishlist_output = {}
["chat commands", "ci-build", "code review", "container registry", "deploy", "deliver", "EE Premium", "EE Ultimate", "issue boards", "issues", "pages", "pipeline", "major wins", "moderation", "moonshots", "open source", "performance", "Prometheus", "service desk", "test", "usability", "vcs for everything", "wiki"].each do |label|
["chat commands", "ci-build", "code review", "container registry", "deploy", "deliver", "EE Premium", "EE Ultimate", "issue boards", "issues", "pages", "pipeline", "major wins", "moderation", "moonshots", "open source", "performance", "Prometheus", "service desk", "test", "usability", "vcs for everything", "wiki", "HA", "Cloud Native"].each do |label|
wishlist_output[label] = label_list(label)
end
wishlist_output["CI"] = label_list("CI",["ci-build", "deploy", "deliver", "pages", "pipeline", "test", "container registry", "chat commands"])
wishlist_output["build"] = label_list("direction",["HA", "Cloud Native"],Array(edition[2]))
print "\n"
 
wishlist_output
source/community/index.html.haml
+ 5
− 0
View file @ e55f5f3c
@@ -50,4 +50,9 @@ extra_css:
= image_tag "/images/icons/mvp.png", alt: "Hall of fame", id: "mvp"
%h2 Hall of Fame
%p The most valuable persons in past releases.
.col-sm-6.col-md-4
%a{href: "/community/issue-bash"}
= image_tag "/images/icons/issue_bash.png", alt: "Issue Bash", id: "issue-bash"
%h2 Issue Bash
%p Quarterly Community Event.
.clearfix.visible-sm-block
source/courses/dev-501/index.html.md 0 → 100644
+ 23
− 0
View file @ e55f5f3c
---
layout: markdown_page
title: "DEV 501 - Contributing to Golang projects"
---
## Aim
This course is for people who have no previous experience with Golang,
but they know another programming language (for example Ruby or JavaScript)
and want to contribute to GitLab projects that are written in Golang.
## Steps
1. Install Go tools by
[following the official instructions](https://golang.org/doc/install)
1. Complete ["A Tour of Go"](https://tour.golang.org)
1. Join `#golang` and `#workhorse` Slack channels
1. Read a [critique of Golang](http://yager.io/programming/go.html)
to be aware of its limitations / weak sides
1. Take a look at [Golang subreddit](https://www.reddit.com/r/golang/) to get
a general feeling what the community is up to these days
1. Pick an issue from GitLab Workhorse issue tracker, preferably with
["Accepting Merge Requests" label](https://gitlab.com/gitlab-org/gitlab-workhorse/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting%20Merge%20Requests)
source/courses/index.html.md 0 → 100644
+ 67
− 0
View file @ e55f5f3c
---
layout: markdown_page
title: "Courses"
---
## On this page
{:.no_toc}
- TOC
{:toc}
## Adding a course
If you have anything to share (no matter the quality level) please add it to this page by:
1. Making sure all the content is publicly viewable. Upload video's to our YouTube channel. If there is a presentation in Google Sheets make sure anyone can view it. If there is written content either add it to the relevant part of the handbook or create a page like https://about.gitlab.com/handbook/people-operations/courses/sls-101
1. Give the code a unique identifier in the form of AAA111, first three letters are for the department, numbers are unique and first number specifies the difficulty level of the course.
1. Add the course to the bottom of this page. If you made a course list on another page (like university or support) you can use just one link to link to the entire list. If the courses are not in one list please link to each individually.
1. Optionally you can create a quiz in Grovo.
Notes:
- We do not create custom course content in Grovo because everyone should be able to contribute to the courses. The courses are part of our handbook or documentation and versioned with git so people can contribute via merge requests. The exception to this are the the individual (IC) and manager (MGR) courses that consist of standard Grovo content.
- All videos are publicly listed on Youtube under our account so they are easy to discover and accessible from many different platforms.
## Individual Contributor (IC) courses
- IC 004 Social Media (28 mins):In today's connected world social media is becoming an essential tool for generating business, responding to customers and sharing content. This course provides some hints, advice and guidance on how to use social media responsibly.
- IC 120 Building Effective Communication Skills (13 mins):Communication is a blend of art and science. To be effective communicators, we must be diligent about practicing and improving our skills.
- IC 130 Collaboration & Consensus (8 mins):Collaboration and consensus are effective ways to work together as a team towards a common goal. Find out more about these approaches in this course.
- IC 140 Productivity Under Pressure (10 mins):Explore ways to effectively manage your workload when the pressure is really on.
- IC 141 Effective Productivity (30 mins):Discover how to schedule time efficiently, prioritize effectively and improve concentration so that your productively is maximized.
- IC 143 How to Manage Projects (36 mins): This course will give an overview of the general process of managing projects. This includes defining, scoping and identifying project tasks. The second half of the course will cover how to include others in your project plan.
## Manager (MGR) courses
- MGR 100 The Role of a Manager (15 mins): Taking the leap from individual contributor to manager is great for your career, but it will also introduce challenges you haven't dealt with before. Learn how to effectively navigate in the role of a manager.
- MGR 101 Develop yourself as a Manager (1hr): This course has five chapters covering; management styles, decision making approaches, data driven management, being human and professional development. This is to provide you with a fuller perspective on how you as a manager can really develop yourself and your role.
- MGR 120 [IC Communicating Effectively](#for-individual-contributors) (18 mins)
- MGR 140 Productivity Under Pressure (12 mins)
- MGR 160 Managing Performance Issues (12 mins): Identifying and addressing performance issues early will impact positively on a team's moral, engagement and ability to achieve results while also reducing turnover. Managers who establish and expect accountability will develop stronger individual contributors and earn the respect of their team.
- MGR 161 Develop Your Team (31 mins): Your team members are all different, which is part of what makes them unique. Before you get the best out them you need to first take some time and understand their working styles, strengths and weaknesses. A crucial part of a manager's role is to give feedback. In addition, you need to know when to give it and the types of approaches to feedback so that your team members respond in a positive way.
- MGR 162 Motivate & Enable Your Team (43 mins): Learn how to motivate your team and understand what it means to be engaged. Discover if you have a strong team commitment and what motivates your team to invest in their work.
- MGR 165 Self Improvement & Team Dynamics (31 mins): Understanding yourself, your emotions and reactions allows you to master them so you can better support your team. A crucial part of getting the most out of your team is by letting them know you can be trusted and they can trust each-other
- MGR 170 Financial Fundamentals (18 mins no quiz): Learn all about generating revenue and profit. Understand the foundations of financial information and the importance of budgeting
- MGR 200 Strategic Management (35 mins): Big picture thinking requires planning and understanding the business at all levels of management. Leading or directing across teams requires influence and excellent communication skills. You need to establish and leverage good networks to get the results and resources you need to make everyone succeed.
- MGR 210 Fostering Creativity & Innovation (44 mins): Discover tools and techniques that will encourage your team to bring their great ideas forward. Ask yourself what does it mean to be creative and how can you as leader use design thinking to encourage others in your team to do the same? The final chapter of this course is all about change, be ready to adapt to change by planning and communicating your vision. Here you will also learn how to measure and evaluate the effectiveness of change initiatives.
## University (UNI) courses
- TODO Code all courses on [https://docs.gitlab.com/ce/university/](https://docs.gitlab.com/ce/university/) and add a single link from here (instead of listing all courses which would lead to duplication).
## Sales (SLS) courses
- TODO
## Finance (FIN) courses
- TODO
## Build (BLD) courses
- BLD101 XYZ TODO
## Engineering (DEV) courses
- [DEV 501 - Contributing to Golang projects](/courses/dev-501)
source/direction/template.html.md.erb
+ 17
− 0
View file @ e55f5f3c
@@ -122,6 +122,23 @@ very much welcome contributions that implement any of these things.
 
<%= wishlist["chat commands"] %>
 
### Build and packaging
GitLab is the engine that powers many companies' software businesses so it is important to ensure it is as easy as possible to deploy, maintain, and stay up to date.
Today we have a mature and easy to use Omnibus based build system, which is the foundation for nearly all methods of deploying GitLab. It includes everything a customer needs to run GitLab all in a single package, and is great for installing on virtual machines or real hardware. We are committed to making our package easier to work with, highly available, as well as offering automated deployments on cloud providers like AWS.
We also want GitLab to be the best cloud native development tool, and offering a great cloud native deployment is a key part of that. We are focused on offering a flexible and scalable container based deployment on Kubernetes, by using enterprise grade Helm Charts.
#### GitLab High Availability
<%= wishlist["HA"] %>
#### Cloud Native Deployment
<%= wishlist["Cloud Native"] %>
#### Other Build Objectives
<%= wishlist["build"] %>
### CI / CD
 
We want to help developers get their code into production; providing convenience and confidence to the developer in an integrated way. CI/CD focuses on steps 6 through 9 of our [scope](#scope): Test (CI), part of Review (MR), Staging (CD), and part of Production (Chatops). When viewed through the CI/CD lens, we can group the scope into CI, CD, and things that are currently beyond any definition of CD.
source/gitlab-com/settings/index.html.md
+ 2
− 1
View file @ e55f5f3c
@@ -87,7 +87,7 @@ Below are the shared Runners settings.
 
| Setting | GitLab.com | Default |
| ----------- | ----------------- | ----------|
| [GitLab Runner] | `9.1.0 (0118d89)` | - |
| [GitLab Runner] | `9.2.0 (adfc387)` | - |
| Executor | `docker+machine` | - |
| Default Docker image | `ruby:2.1` | - |
| `privileged` (run [Docker in Docker])| `true` | `false` |
@@ -129,6 +129,7 @@ The full contents of our `config.toml` are:
AccessKey = "ACCESS_KEY"
SecretKey = "ACCESS_SECRET_KEY"
BucketName = "runner"
Shared = true
```
 
## Sidekiq
source/handbook/engineering/index.html.md
+ 1
− 0
View file @ e55f5f3c
@@ -18,6 +18,7 @@ title: "Engineering"
 
- [Developer onboarding](/handbook/developer-onboarding)
- [Engineering Workflow](/handbook/engineering/workflow)
- [Performance](/handbook/engineering/performance)
- [Issue Triage Policies](/handbook/engineering/issues/issue-triage-policies)
- [Critical Security Release Process](/handbook/engineering/critical-release-process)
 
source/handbook/engineering/performance/index.html.md 0 → 100644
+ 156
− 0
View file @ e55f5f3c
---
layout: markdown_page
title: "Performance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
## Other Related Pages
{:.no_toc}
- [GitLab.com (infra) architecture](handbook/infrastructure/production-architecture/)
- [Monitoring GitLab.com](handbook/infrastructure/monitoring/)
- [Application Architecture documentation](https://docs.gitlab.com/ce/development/architecture.html)
- [GitLab.com Settings](https://about.gitlab.com/gitlab-com/settings/)
- [GitLab performance monitoring documentation](https://docs.gitlab.com/ce/administration/monitoring/performance/introduction.html)
## Flow of information in various scenarios, and its performance
Issue that spawned this page: https://gitlab.com/gitlab-com/infrastructure/issues/1878
All items that start with the <i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>
symbol represent a step in the flow that we _measure_ . Wherever possible, the
tachometer icon links to the relevant dashboard in our [monitoring](handbook/infrastructure/monitoring/).
### Flow of web request
Considering the scenarios of a user opening their browser, and surfing to their dashboard
by typing `gitlab.com/dashboard`, here is what happens:
1. User enters gitlab.com/dashboard in their browser and hits enter
1. Browser looks up IP address in DNS server
- DNS request goes out and comes
back (typically ~10-20 ms, [can use link to data]; often times it is already cached so
then it would be faster).
- We use Route53 for DNS, and will start using DynDNS soon as well.
- For more details on the steps from browser to application, enjoy reading
https://github.com/alex/what-happens-when
- not measured
1. From browser to load balancers
- Now that the browser knows where to find the IP address, browser sends the web
request (for gitlab.com/dashboard) to Azure; Azure determines where to route the
packet (request), and sends the request to our Frontend Load Balancer(s) (also
referred to as HAProxy).
- not measured
1. Load Balancer forwards to NGINX in one of our front end workers
- In this case, since we are tracking a web request, it would be the nginx box in the
"Web" box; but alternatively the request can come in via API or a git command
from the command line, hence the API, and git "boxes")
- not measured
1. NGINX does SSL negotiation with the browser (takes time)
- not measured
- [todo, follow up on "there are some Web settings that may help: https://linux-audit.com/optimize-ssl-tls-for-maximum-security-and-speed/"]
1. NGINX gathers all network packets related to the request ("request buffering")
- the request may be split into multiple packets by the intervening network,
for more on that, read up on [MTUs](https://en.wikipedia.org/wiki/Maximum_transmission_unit).
- In other flows, this won't be true. Specifically, request buffering is
[switched off for LFS](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/130)
- not measured, and not in our control.
1. NGINX forwards full request to workhorse (in one combined request)
- not measured
1. Workhorse splits the request into parts to forward to
- [<i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>](https://performance.gitlab.net/dashboard/db/transaction-overview?panelId=13&fullscreen&orgId=1)Unicorn (time spent waiting for Unicorn to pick up a request = `HTTP queue
time`).
- [not in this scenario, but not measured in any case] Gitaly
- [not in this scenario, but not measured in any case] NFS (git clone through HTTP)
- [not in this scenario, but not measured in any case] Redis (long polling)
1. Unicorn (often just called "Rails", or "application server"), translates the
request into a Rails controller request; in this case `RootController#index`. RailsController requests are sent to:
- [<i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>](https://performance.gitlab.net/dashboard/db/transaction-overview?panelId=9&fullscreen&orgId=1) PostgreSQL (`SQL timings`),
- [<i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>](https://performance.gitlab.net/dashboard/db/daily-overview?panelId=14&fullscreen&orgId=1) NFS (`git timings`),
- [<i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>](https://performance.gitlab.net/dashboard/db/daily-overview?panelId=13&fullscreen&orgId=1) Redis (`cache timings`).
- In this `gitlab.com/dashboard` example, the controller addresses all three [<i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>](https://performance.gitlab.net/dashboard/db/rails-controllers?orgId=1&var-action=RootController%23index&var-database=Production).
Typically 20 ms in cache, git timings in the 100's of ms (peaky), sql timings
(mean in 10's of ms, peaks to 5 s).
- There are usually _multiple_ SQL calls (or file, or cache, etc.) calls for a given
controller request. These add to the overall timing, especially since they are
sequential. For example, in
this scenario, there are [29 SQL calls (search for `Load`)](http://profiler.gitlap.com/20170524/901687e2-9fa1-4256-8414-c4835dc31dbc.txt.gz)
when this _particular user_ hits `gitlab.com/dashboard/issues`. The number of SQL calls
will depend on how many projects the person has, how much may already be in cache, etc.
- There's generally no multi-tasking within a single Rails request. In a
number of places we multi-task by serving a HTML page that uses AJAX to
fill in some data, for example on `gitlab.com/username` the contribution
calendar and the "most recent activity" sections are loaded in parallel.
- In the Rails stack, middleware typically adds to the number of round trips
to Redis, NFS, and PostgreSQL, per controller call, in addition to the
timings of Rails controllers. Middleware is used for {session state, user
identity, endpoint authorization, rate limiting, logging, etc} while the
controllers typically have at least one round trip for each of {retrieve
settings, cache check, build model views, cache store, etc.}. Each such
roundtrip _estimated_ to take < 10 ms.
1. Unicorn receives the information from the database, NFS, and cache
- no data on the round trip time for asking / receiving the data.
1. [<i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>](https://performance.gitlab.net/dashboard/db/transaction-overview?panelId=8&fullscreen&orgId=1) Unicorn constructs the relevant html blob (view) to be served back to the user.
- In our gitlab.com/dashboard example, view timings p99 in multiple seconds
with mean < 1s. See the `View Timings`.
- A particular view in Rails will often be constructed from multiple partial
views. These will be used from a template file, specified by the controller
action, that is, itself, generally included within a layout template.
Partials can include other partials. This is done for good code
organization and reuse. As an example, when the _particular user_ from the
example above loads `gitlab.com/dashboard/issues`, there are [56 nested / partial views rendered (search for `View::`)](http://profiler.gitlap.com/20170524/901687e2-9fa1-4256-8414-c4835dc31dbc.html.gz)
- GitLab renders a lot of the views in the backend (i.e. in Unicorn) vs.
frontend. To see the split, use your browser's "inspect" tool and look at
TTFB (time to first byte, this is the browser waiting to hear anything back,
which is due to work happening in the backend) and compare it to the
download time.
- Some of these blobs are expensive to compute, and are sometimes hard-coded
to be sent from Unicorn to Redis (i.e. to cache) once rendered.
1. [<i class="fa fa-tachometer fa-fw" aria-hidden="true"></i>](https://performance.gitlab.net/dashboard/db/transaction-overview?panelId=2&fullscreen&orgId=1) Unicorn sends html blob back to workhorse
- The round trip time it takes for a request to _start_ in Unicorn and _leave_ Unicorn
is what we call `Transaction Timings`.
1. Workhorse sends html blob to NGINX
- not measured
1. NGINX sends html blob to browser
- not measured
1. Browser renders page.
- not measured
- The rendering refers to the html blob. However, the browser also needs to
load JS, CSS, images, and webfonts before the user can interact with it. As
the page is streamed to the browser, the browser will be incrementally parsing
it, looking for additional resources that it can start fetching. If these
resources are on a different hostname, the browser will need to perform
further DNS lookups (see step 2). For more, see the [related
issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/33501).
### Flow of git commit push
First read [Flow of web request](#Flow-of-web-request) above, then pick up the
thread here.
After pushing to a repository, e.g. from the _web UI_:
1. In a web browser, make an edit to a repo file, type a commit message, and
hit "Commit"
1. NGINX receives the git commit and passes it to Workhorse
1. Workhorse launches a `git-receive-pack` process (on the workhorse machine)
to save the new commit to NFS
1. On the workhorse machine, `git-receive-pack` fires a [git hook](/glossary/#git-hook)
to trigger `GitLab Shell`.
- GitLab Shell accepts Git payloads pushed over SSH and acts upon them (e.g.
by checking if you're authorized to perform the push, scheduling the data
for processing, etc).
- In this case, GitLab Shell provides the `post-receive` hook, and
the `git-receive-pack` process passes along details of what was pushed to the
repo to the `post-receive` hook. More specifically, it passes a list of three items: old
revision, new revision, and ref (e.g. tag or branch) name.
1. Workhorse then passes the `post-receive` hook to Redis, which is the Sidekiq queue.
- Workhorse informed that the push succeeded or failed (could have failed due to the repo not available, Redis being down, etc.)
1. Sidekiq picks up the job from Redis and removes the job from the queue
1. Sidekiq updates PostgreSQL
1. Unicorn can now query PostgreSQL.
source/handbook/glossary/index.html.md
+ 11
− 0
View file @ e55f5f3c
@@ -88,6 +88,17 @@ A copy of an original repository that you can put somewhere else or where you ca
 
#### [Git](https://git-scm.com/about)
 
##### [Git Hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
From the page that is linked in the title: "Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits."
Difference between a webhook and a git hook: a git hook is local to its repo
(usually) while a webhook is not (it can make API or http calls). So for example
if you want your linter to fire before you commit, you can set that up with a git hook. If
the linter fails, the commit does not go through. A git hook _can_ be configured
to go beyond its repo, e.g. by having it make an API call.
#### [GitLab Geo](https://docs.gitlab.com/ee/gitlab-geo/README.html)
 
#### [GitLab Pages](https://pages.gitlab.io/?_ga=1.99536669.2048946469.1469722633)
source/handbook/infrastructure/monitoring/index.html.md
+ 9
− 1
View file @ e55f5f3c
@@ -14,6 +14,7 @@ title: "Monitoring Performance"
- [Production Architecture](production-architecture)
- [GitLab.com Settings](https://about.gitlab.com/gitlab-com/settings/)
- [GitLab performance monitoring documentation](https://docs.gitlab.com/ce/administration/monitoring/performance/introduction.html)
- [Performance of the Application](/handbook/engineering/performance)
 
## Monitoring
 
@@ -66,10 +67,17 @@ interfaces are:
## GitLab Profiler
 
[GitLab profiler data](http://redash.gitlab.com/dashboard/gitlab-profiler-statistics)
is a dashboard with links to
is a dashboard with links to
[request profiles](https://docs.gitlab.com/ee/administration/monitoring/performance/request_profiling.html)
and SQL queries run when loading pages on GitLab.com.
 
To add a page to this dashboard, create a merge request to the
[gitlab-com/gitlab-profiler](https://gitlab.com/gitlab-com/gitlab-profiler)
project.
## Instrumenting Ruby to monitor performance
Blocks of Ruby code can be "instrumented" to measure performance.
- [Documentation of instrumentation](https://docs.gitlab.com/ce/development/instrumentation.html)
with more detail on [how to implement this](https://docs.gitlab.com/ce/development/instrumentation.html#instrumenting-ruby-blocks)
- An example of how this is used for GitLab itself, can be found in this [initializer](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/initializers/8_metrics.rb).
source/handbook/infrastructure/production-architecture/index.html.md
+ 2
− 1
View file @ e55f5f3c
@@ -20,6 +20,7 @@ are not integral to the public facing operations of GitLab.com.
- [GitLab.com Settings](https://about.gitlab.com/gitlab-com/settings/)
- [Monitoring Performance of GitLab.com](monitoring)
- [GitLab performance monitoring documentation](https://docs.gitlab.com/ce/administration/monitoring/performance/introduction.html)
- [Performance of the Application](/handbook/engineering/performance)
 
## Diagram of the Architecture
 
@@ -107,7 +108,7 @@ We are currently investigating Google Cloud.
## Monitoring
 
See how it's doing, for more information on that, visit the [monitoring
handbook](monitoring/).
handbook](/handbook/infrastructure/monitoring/).
 
## Technology at GitLab
 
source/handbook/infrastructure/security/index.html.md
+ 67
− 45
View file @ e55f5f3c
@@ -125,23 +125,23 @@ and dealing with spam. Common targets for spam are public snippets, projects, is
merge requests, and comments. Advanced techniques for dealing with these types of spam
are detailed in the [Spam Fighting runbook](https://docs.google.com/document/d/1V0X2aYiNTZE1npzeqDvq-dhNFZsEPsL__FqKOMXOjE8).
 
## Risk Assessments
## Always "WIP" Risk Assessment
{: #risk-assessment}
 
GitLab conducts regular Risk Assessments and all team members are encouraged to
GitLab has an "always WIP" Risk Assessment and all team members are encouraged to
participate. The Risk Assessment consists of a list of all risks or threats to
the GitLab infrastructure and GitLab as a company, their likelihood of occuring,
the GitLab infrastructure and GitLab as a company, their likelihood of occurring,
the impact should they occur, and what actions can be taken to prevent these
risks from damaging the company or mitigate the damage should they be realized.
 
All Risk Assessments are stored as Google Sheets and are available to all team
members. Risk Assessments should not be shared with people outside of the company
The [Risk Assessment is stored as a Google Sheet](https://docs.google.com/a/gitlab.com/spreadsheets/d/1xtuoemhFhyh7Og-76pQhHWtQHkaaeU9uqjyuJkvNfS0/edit?usp=sharing) and is available to all team
members. It should not be shared with people outside of the company
without permission.
 
[Current Risk Assessment](https://docs.google.com/a/gitlab.com/spreadsheets/d/1xtuoemhFhyh7Og-76pQhHWtQHkaaeU9uqjyuJkvNfS0/edit?usp=sharing)
The format of the Risk Assessment may seem intimidating at first. If you do not
know what values to use for risk ratings, impact ratings, likelihoods or any other
value leave them blank and they will be filled in by the appropriate team. It
value leave them blank and reach out to the Security Team to help you determine
appropriate values. It
is more important to have all risks documented than it is to have all values
completed when adding new risks. Guidelines and instructions for how to add a
risk and how to calculate each rating or score are included on the
@@ -149,25 +149,67 @@ risk and how to calculate each rating or score are included on the
 
## HackerOne Reports
 
GitLab utilizes [HackerOne] for its bug bounty program. Security researchers can
GitLab utilizes [HackerOne](https://www.hackerone.com) for its bug bounty program. Security researchers can
report vulnerabilities in GitLab applications or the GitLab infrastructure
via the HackerOne website. Team members authorized to respond to HackerOne
reports use procedures outlined here.
 
[HackerOne]: https://www.hackerone.com
### Initial reports
### How to handle HackerOne reports
 
When a report is received, an initial determination should be made as to
severity and impact. Critical vulnerabilities should have a confidential issue
opened on the appropriate issue tracker immediately (usually [CE](https://gitlab.com/gitlab-org/gitlab-ce/issues)),
the issue should be assigned the `SL1` and `security` labels, and the appropriate
team members should be notified via the issue, Slack, and Email if necessary.
severity and impact.
#### Regular flow
- Open a confidential issue the appropriate issue tracker **within 24 hrs** of
receiving the report (usually [CE](https://gitlab.com/gitlab-org/gitlab-ce/issues)),
_except_ in the case of an obviously invalid report, see below.
- HackerOne provides an "export" option that simplifies copying data from the HackerOne
issue to GitLab. Export the data in markdown format and paste it into the new
issue.
- Always add the `~HackerOne` label to these issues, for later reporting and tracking.
- If the you are unsure as to the validity or impact of the finding this should be stated in the
issue so that others can investigate.
- Attempt to verify the report and triage the vulnerability.
- Add the appropriate [Security Priority Labels](#security-priority-labels)
- As applicable, notify relevant team members via the issue, chat, and email,
depending on the chosen security level.
- Change the state of the report to "Triaged" in HackerOne and include a link to the issue
as the reference.
- At this point, but **always within 24 hrs** of the receiving the report, the
HackerOne researcher should be notified that the issue has been triaged. Always
let the researcher know:
* Whether or not the finding has been verified.
* That the issue has been triaged and provide a link to the confidential issue. Do
not invite the researcher to the issue via their GitLab account if they ask. Sensitive
data such as related vulnerabilities are sometimes discussed in these issues.
* That the GitLab issue will be opened to the public when a patch has been released.
* That they will be updated on our progress via HackerOne as soon as we know more.
* Always mention that they can contact us at any time for an update.
- Discussion and remediation of vulnerabilities can sometimes take longer than we
would prefer. Even so, frequent communication with reporters is far better than
leaving reporters in the dark, even if our progress is slow. Therefore:
- For vulnerabilities where patches are actively being worked on,
reporters should be updated at least **weekly**.
- In the case where fixes are not as clear or discussion is still on-going
as to whether a patch will be created at all, reporters should be notified
of updates at least **monthly**.
- In any case, no report should go "stale" where updates are not provided
within the last month.
#### If a report is unclear
 
If a report is unclear, or the reviewer has any questions about the validity of
the finding or how it can be exploited, now is the time to ask. Move the report to the
"Needs More Info" state until the researcher has provided all the information necessary to
determine the validity and impact of the finding.
determine the validity and impact of the finding. Use your best judgement to determine
whether it makes sense to open a confidential issue anyway, noting in it that you
are seeking more information from the reporter. When in doubt, err on the side
of opening the issue.
One the report has been clarified, follow the "regular flow" described above.
#### If a report violates the rules
 
If a report violates the rules of GitLab's bug bounty program use good judgement
in deciding how to proceed. For instance, if a researcher has tested a vulnerability
@@ -176,38 +218,17 @@ placed GitLab user data at risk, notify them that they have violated the terms
of the bounty program but you are still taking the report seriously and will treat
it normally. If the researcher has acted in a dangerous or malicious way, inform
them that they have violated the terms of the bug bounty program and will not
receive credit. Then continue with issue triage as you normally would.
receive credit. Then continue with the "regular flow" as you normally would.
#### If the report is invalid
 
If in your determination the report is invalid or does not pose a security risk
If the report is invalid (in your determination) or does not pose a security risk
to GitLab or GitLab users it can be closed without opening an issue on GitLab.com.
When this happens inform the researcher why it is not a vulnerability and close
the issue as "Informational". HackerOne offers the option to close an issue
as "Not Applicable" or "Spam". Both of these categories result in damage to the
researcher's reputation and should only be used in obvious cases of abuse.
 
### Triage
Once all required data has been entered by the HackerOne researcher and the finding
has been verified a confidential issue should be opened on the appropriate issue
tracker and associated team members should be notified via the issue, Slack,
and Email, depending on the chosen security level. If the reviewer is unsure
as to the validity or impact of the finding this should be stated in the issue
so that others can investigate.
HackerOne provides an "export" option that simplifies copying data from the HackerOne
issue to GitLab. Export the data in markdown format and paste it into the new
issue.
At this point the HackerOne researcher should be notified that the issue has been
triaged. Always let the researcher know:
* Whether or not the finding has been verified.
* That the issue has been triaged and provide a link to the confidential issue. Do
not invite the researcher to the issue via their GitLab account if they ask. Sensitive
data such as related vulnerabilities are sometimes discussed in these issues.
* That the GitLab issue will be opened to the public when a patch has been released.
* That they will be updated on our progress via HackerOne as soon as we know more.
### When a patch is ready
 
When a patch has been developed, tested, approved, merged into the security
@@ -235,9 +256,10 @@ On the day of the security release several things happen in order:
the reporting researchers.
 
Once all of these things have happened notify the HackerOne researcher that the
vulnerability and patch are now public. The issue should be closed and public
disclosure should be requested if they have not objected to doing so.
vulnerability and patch are now public. The GitLab issue should be closed and
the HackerOne report should be closed as "Resolved". Public disclosure should be
requested if they have not objected to doing so. Any sensitive information
contained in the HackerOne report should be sanitized before disclosure.
 
### Swag for reports
 
source/handbook/marketing/blog/release-posts/index.html.md
+ 137
− 158
View file @ e55f5f3c
@@ -45,7 +45,7 @@ these templates, and follow their instructions
to insert content. Please make sure to use
the most recent template available.
 
- [Monthly release](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.html.md)
- [Monthly release](#getting-started)
- [Patch release](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/patch_release_blog_template.html.md)
- [Security release](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/security_release_blog_template.html.md)
 
@@ -74,13 +74,13 @@ The new layout was [introduced](https://gitlab.com/gitlab-com/www-gitlab-com/mer
 
### Getting started
 
To create a new monthly release post, add two files to the [about.GitLab.com repository]() (consider the release of GitLab X.Y, released in AAAA/MM/DD):
To create a new monthly release post, add two files to the [about.GitLab.com repository](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/) (consider the release of GitLab X.Y, released in YYYY/MM/DD):
 
- A YAML data file, containing all the release post content
- Into `data/release_posts/`, add a new file called `AAAA_MM_22_gitlab_X_Y_released.yml`
- Template ([latest version](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/AAAA_MM_DD_gitlab_x_y_released.yml))
- Into `data/release_posts/`, add a new file called `YYYY_MM_22_gitlab_X_Y_released.yml`
- Template ([latest version](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/YYYY_MM_DD_gitlab_x_y_released.yml))
- A blog post file, containing the introduction and the blog post frontmatter information
- Into `source/posts/`, add a new file called `AAAA-MM-22-gitlab-X-Y-released.html.md`
- Into `source/posts/`, add a new file called `YYYY-MM-22-gitlab-X-Y-released.html.md`
- Template ([latest version](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.html.md))
 
**Important!** Please use the most recent templates for each of these files.
@@ -90,6 +90,8 @@ To create a new monthly release post, add two files to the [about.GitLab.com rep
Create a merge request with the introductory changes _before the kick off call_
to make the post available to receive contributions from the team.
 
Please use the release post template for your MR:
![release post MR template](release-post-mr-template.png){:.shadow}
 
<!-- #### Authorship
@@ -131,10 +133,11 @@ time for the release date, please set due dates for:
 
- [General contributions](#general-contributions)
from the team: 6th working day before the 22nd
- [Review](#review): 4th working day before the 22nd
- [Review](#review): 2nd working day before the 22nd
 
Ideally, the 3rd and the 2nd working day before the release
should be left for fixes and small improvements.
Ideally, the review should be completed until the 4th working day before the 22nd,
so that the 3rd and the 2nd working day before the release
could be left for fixes and small improvements.
 
### General contributions
 
@@ -146,7 +149,7 @@ the 22nd. Please fill all the [sections](#sections).
You are responsible for the content you add to the blog post. Therefore,
make sure that:
 
- all the fields are correct and not missing (especially links to
- all the entries are correct and not missing (especially links to
the documentation or feature webpages when available).
- feature availability: add the correct entry (CE, EES, EEP)
- all images are optimized (compressed with [ImageOptim](https://imageoptim.com),
@@ -162,25 +165,23 @@ the [markdown guide](/handbook/product/technical-writing/markdown-guide/).
## Monthly release blog post sections
{:#sections}
 
- Introduction
- CTA buttons
- MVP
- Features
- Top feature
- Primary features
- Secondary features (improvements)
- Illustrations (screenshots, gifs, or videos)
- [Introduction](#introduction)
- [CTA buttons](#cta)
- [MVP](#mvp)
- [Features](#features)
- [Top feature](#top-feature)
- [Primary features](#primary-features)
- [Secondary features (improvements)](#improvements)
- [Illustrations](#illustrations) (screenshots, gifs, or videos)
accompanying their respective features
- Up-to-date documentation link
- Availability
- Performance improvements (added as a secondary feature)
- Omnibus GitLab (added as a secondary feature)
- Upgrade barometer
- Deprecations
- [Upgrade barometer](#upgrade-barometer)
- [Deprecations](#deprecations)
 
### Introduction
 
Add the introduction to the blog post file (`AAAA-MM-DD-gitlab-X-Y-released.html.md`),
Add the introduction to the blog post file (`YYYY-MM-DD-gitlab-X-Y-released.html.md`),
in regular markdown.
 
Add a short paragraph before the `<!-- more -->` separator, and
@@ -199,7 +200,7 @@ Introduction (regular markdown)
 
Call-to-action buttons displayed at the end of the introduction.
A CTA to the [events page](/events/) is added by default. Add webcasts,
or custom buttons to this field whenever necessary.
or custom buttons to this entry whenever necessary.
 
```yaml
cta:
@@ -209,7 +210,6 @@ cta:
- link:
```
 
### MVP
 
To display the MVP of the month, use the information
@@ -220,7 +220,7 @@ Don't forget to link to the MR with the MPV's contribution.
mvp:
fullname: Dosuken Shinya # full name
gitlab: dosuken123 # gitlab.com username
description: | # supports markdown. Pls link to the MR.
description: | # supports markdown. Please link to the MR with the MVP's contribution.
Dosuken extended our [Pipelines API](http://docs.gitlab.com/ce/api/pipelines.html#list-project-pipelines)
by [adding additional search attributes](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9367).
This is a huge improvement to our CI API, for example enabling queries to easily return the latest
@@ -231,84 +231,70 @@ mvp:
 
### Features
 
- Feature blocks
- `name`: feature name, capitalized
- `available_in`: availability of that feature in GitLab:
- For Community Edition, use `[ce, ees, eep]`
- For Enterprise Edition Starter, use `[ees, eep]`
- For Enterprise Edition Premium, use `[eep]`
- `documentation_link`: use to insert a link to the documentation. Required for the top feature, optional for primary and secondary features.
- `documentation_text`: use to customize the text for `documentation_link`. Required for the top feature and optional for primary and secondary features.
- `image_url`: link to the image which illustrates that feature. Required for primary features, optional for secondary features, n/a for top feature.
- `image_noshadow: true`: if an image (`image_url`) already has shadow the entry `image_noshadow` will remove the shadow applied with CSS by default. Optional.
- `description: |`: add the feature's description in this entry. Make sure your cursor is in the line below the pipeline symbol `|` intended once. All `description` fields fully support
[markdown](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/), the only thing you need to be worried about is respecting the indentation.
The most relevant features of the release are included in the post by team members.
Classify the feature according to its relevance and to where you want to place it in the blog post:
 
<!--
#### Top feature
 
### Top Feature
The most important feature of the release, mentioned right after the MVP section.
Images can be added at will in the description entry. A link to the documentation is required.
 
The top feature is the most important of the release. Fill in the information according to the following example:
```yaml
top:
- name: Amazing Feature # the feature's name (short title) - required
available_in: [ees, eep] # (availability of that feature) - required
documentation_link: 'https://docs.gitlab.com/#amazing' # link to the feature's webpage or documentation - required
documentation_text: "Learn more about Amazing Feature" # optional
description: | # supports markdown - required
Lorem ipsum dolor sit amet, [consectetur adipisicing](#link) elit.
```
#### Primary features
 
### Primary Features
Features with higher impact, displayed
in rows after the top feature, with an image next to its text. An image accompanying the description is required.
 
Start with the top feature wrapped into
[one column](#one-column) section.
#### Secondary features (other improvements)
{:#improvements}
 
```html
primary:
- name: Lorem ipsum # the feature's name (short title) - required
available_in: [ce, ees, eep] # (availability of that feature) - required
documentation_link: '/features/cycle-analytics' # link to the feature's webpage or documentation - required
documentation_text: "Learn more about Cycle Analytics" # optional
image_url: '/images/9_2/i18n.png' # required
description: | # supports markdown - required
Lorem ipsum [dolor sit amet](#link), consectetur adipisicing elit.
Perferendis nisi vitae quod ipsum saepe cumque quia `veritatis.
```
Relevant improvements in GitLab. Image is not required, but recommended.
 
### Feature blocks
 
### Secondary features
Use feature blocks to add features to the YAML data file.
The layout will be applied automatically by Middleman's
[templating system](/2016/06/10/ssg-overview-gitlab-pages-part-2/#template_engine).
 
Start this part of the blog post with the [loose heading](#loose-headings):
Feature blocks in the YAML data file contain the following entries, as exemplified below:
 
```yaml
secondary:
- name: Lorem ipsum
available_in: [eep]
documentation_link: 'https://docs.gitlab.com/#'
documentation_text: "Learn more on how to lorem ipsum."
image_url: '/images/9_2/create_new_merge_request.png'
description: | # supports markdown - required
Lorem ipsum [dolor sit amet](#link), consectetur adipisicing elit.
Perferendis nisi vitae quod ipsum saepe cumque quia `veritatis`.
- name: Pipeline Graphs
available_in: [ce, ees, eep]
documentation_link: 'https://docs.gitlab.com/ce/ci/pipelines.html#pipeline-graphs'
documentation_text: "Learn more about Pipeline Graphs"
image_url: 'https://about.gitlab.com/images/8_11/pipeline_graph2.png'
image_noshadow: true
description: |
Lorem ipsum dolor sit amet, [consectetur adipisicing](#link) elit.
```
 
To display **secondary features**, use the same logic as described
previously for [two columns](#text-on-the-left-image-on-the-right).
The difference is that images will be placed among the content,
not on the right or left of the text. To do so, use two columns
in a row and add all the features in between:
The tricky part is to balance the content between the
columns to make them finish as near to a baseline as possible.
![secondary features - baseline](other-features.png){:.shadow}
-->
These entries represent:
- `name`: feature name, capitalized
- `available_in`: availability of that feature in GitLab:
- For Community Edition, use `[ce, ees, eep]`
- For Enterprise Edition Starter, use `[ees, eep]`
- For Enterprise Edition Premium, use `[eep]`
- `documentation_link`: use to insert a link to the documentation.
Required for the top feature, optional for primary and secondary features.
- `documentation_text`: use to customize the text for `documentation_link`.
Required for the top feature and optional for primary and secondary features.
- `image_url`: link to the image which illustrates that feature.
Required for primary features, optional for secondary features, n/a for top feature.
- `image_noshadow: true`: if an image (`image_url`) already has shadow
the entry `image_noshadow` will remove the shadow applied with CSS by default. Optional.
- `description: |`: add the feature's description in this entry.
Make sure your cursor is in the line below the pipeline symbol `|` intended once.
All `description` fields fully support
[markdown](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/),
the only thing you need to be worried about is respecting the indentation.
 
### Cover image license
 
According to our [Blog handbook](/handbook/marketing/blog/#cover-image), it's necessary
to provide the source of the cover image. Fill in the entry below to display
this info at the very end of the blog post:
```yaml
cover_img:
image_url: '#link_to_original_image'
@@ -316,8 +302,25 @@ cover_img:
licence_url: '#link_to_licence'
```
 
### Upgrade barometer
Describes the information about upgrading GitLab to the new version.
```yaml
barometer:
description: |
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Dignissimos blanditiis reprehenderit voluptate ea quidem
eveniet similique tempore [quibusdam fugiat](#link) magni, eius,
quasi aperiam corrupti `tempora` rerum amet totam maiores.
Reiciendis.
```
### Deprecations
 
Describe the deprecations happening on that release or in upcoming releases.
Let our community know about a future deprecation as soon as possible.
```yaml
deprecations:
- feature_name: Lorem ipsum dolor
@@ -327,8 +330,7 @@ deprecations:
Veritatis, quisquam.
```
 
For multiple deprecations, use multiple feature blocks:
For multiple deprecations, use multiple feature deprecation blocks:
 
```yaml
deprecations:
@@ -344,20 +346,14 @@ deprecations:
Veritatis, quisquam.
```
 
### Review
 
### Upgrade barometer
The review is performed after content has been added, so it's important
to respect the due dates, otherwise reviews will have to be done repeatedly.
 
```yaml
barometer:
description: |
Lorem ipsum dolor sit amet, consectetur adipisicing elit.
Dignissimos blanditiis reprehenderit voluptate ea quidem
eveniet similique tempore [quibusdam fugiat](#link) magni, eius,
quasi aperiam corrupti `tempora` rerum amet totam maiores.
Reiciendis.
```
### Review
Ideally, the review should be completed by the 4th working day before the 22nd,
so that the 3rd and the 2nd working day before the release
can be left for fixes and small improvements.
 
#### Content review
 
@@ -370,8 +366,6 @@ copyedit and check for grammar, spelling, and typos.
Please follow the checklist in the MR description to
guide you through the review.
 
The review should be finished by the 4th working day before the 22nd.
#### Structural Check
 
Once the post is filled with content, the technical writing,
@@ -416,21 +410,38 @@ layout: release
 
### Markdown
 
In fields that support markdown, use regular
For entries that support markdown, use regular
[markdown Kramdown](/handbook/product/technical-writing/markdown-guide/),
as we use to all blog posts and webpages for about.GitLab.com.
as we use for all blog posts and webpages on about.GitLab.com.
 
### Illustrations
 
#### Images
 
- Make sure every image has an
- {:#alt} Make sure every image has an
[alternative text](/handbook/product/technical-writing/markdown-guide/#image-alt-text)
- Each image should be compressed with [ImageOptim](https://imageoptim.com),
- {:#images-compressed} Each image should be compressed with [ImageOptim](https://imageoptim.com),
[TinyPNG](https://tinypng.com/), or similar tool
- Each image should not surpass 300KB, gifs included
- If a gif isn't necessary, replace it with a static image (.png, .jpg)
- If an animation is necessary but the gif > 300KB, use a video instead
- {:#image-size-limit} Each image should not surpass 300KB, gifs included
- {:#gifs} **Animated gifs**:
- If a gif isn't necessary, replace it with a static image (.png, .jpg)
- If an animation is necessary but the gif > 300KB, use a video instead
- {:#cover-image} **Cover image**:
use an unique image as cover to every post, and add
[the required copyright info](#cover-image-license) into the Yaml file.
This image should be eyes-catching and inspiring.
- {:#image-shadow} **Image shadow**:
when you add images though the text,
make sure all images have the class shadow applied:
- `![image alt text](#img-url){:.shadow}`
- If the original image already has shadow applied, don't use `{:.shadow}`.
- If you're inserting the image in the YAML file via `image_url` entry, add the `image_noshadow: true` [entry](#feature-blocks) right after `image_url`.
- {:#social-sharing-image} **Social sharing image**:
It's recommended to add a [social sharing image](/handbook/marketing/social-marketing/#defining-social-media-sharing-information)
to the blog post. It is the image that will display on
social media feeds whenever the link to the post is shared.
The image should be placed under `source/images/tweets/`
and named after the post's filename (`gitlab-X-X-released.png`).
 
#### Videos
 
@@ -449,57 +460,25 @@ is displayed responsively.
Consult the [markdown guide](/handbook/product/technical-writing/markdown-guide/#videos)
for the correct markdown markup to apply to different sources (YouTube, Google Drive, HTML video).
 
<!--
#### Feature with no images
When a primary feature does not contain a related image,
you can either display it in a section with [one column](#one-column) or
move it to a secondary feature section.
#### Feature with multiple images
When there's more than one image for a single feature, put them
together in their designated column:
![multiple images for a feature](main-multi-img.png){:.shadow}
Do not indent divs, it will not render correctly if you do so.
{:.alert alert-info}
#### Cover image
If the post doesn't have a cover image yet, please
add one, and don't forget to add a [reference](../#cover-image)
to it [at the very end](#cover-image-reference) of the post. -->
<!-- #### Social sharing image
It's recommended to add a [social sharing image](/handbook/marketing/social-marketing/#defining-social-media-sharing-information)
to the blog post. It's the image that will display on
social media feeds whenever the link to the post is shared.
The image should be placed under `source/images/tweets/`
and named after the post's filename (`gitlab-X-X-released.png`).
#### Badges
Every feature should be accompanied by a badge (CE, EES, EEP).
To display them, use the content of the template `available in: (CE/EES/EEP)`,
adding the acronyms to each heading. They can be applied
to `h2` and `h3` elements.
- `## Feature XXX ce ee` will display the badges
`CE` and `EE` (use it for every feature available in GitLab CE)
- `### Feature YYY ees` will display the badge
`EES` (use it for features available in EES and EEP)
- `## Feature ZZZ eep` will display the badge
`EEP` (use it for features available in EEP only) -->
<!-- ## Technical aspects
## Technical aspects
 
Understand how a release post is formed:
 
-->
- **Template:**
- [Layout (Haml) file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/source/layouts/release.haml):
creates a layout for the final HTML file, and requires the include file below.
- [Include (Haml) file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/source/includes/release.html.haml):
builds the content of the post applying custom styles. Its markup includes semantic SEO improvements.
- **Content:**
- **YAML data file**: gathers the actual content for the blog post, except the introduction ([template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/YYYY_MM_DD_gitlab_x_y_released.yml), [example](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/release_posts/2017_05_22_gitlab_9_2_released.yml))
- **Blog post file**: the blog post file, which holds the introduction of the blog post and its frontmatter ([template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.html.md), [example](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/source/posts/2017-05-22-gitlab-9-2-released.html.md))
The template files form the blog post, therefore, don't need to be changed every release.
The content files are the ones to be added every release with its unique content, as described
by the section [getting started](#getting-started).
To learn more how the templating system works, read through an overview on
[Modern Static Site Generators](/2016/06/10/ssg-overview-gitlab-pages-part-2/).
 
<style>
pre { margin-bottom: 20px; }
source/handbook/marketing/business-development/index.html.md
+ 1
− 4
View file @ e55f5f3c
@@ -148,7 +148,7 @@ Director of Federal Sales = Paul Almeida
- Only work new business leads
 
### Lead Source<a name="leadSource"></a>
Lead Source is set upon First "known" touch attribution. It should never be changed or overwritten. If merging leads, choose to keep the Lead Source that was created first (if you can tell). If creating a Lead/Contact and you are unsure what Lead Source to use, ask on #Lead-Questions channel in Slack.
Lead Source is set upon first "known" touch attribution. It should never be changed or overwritten. If merging leads, keep the Lead Source that was created first (if you can tell). If creating a Lead/Contact and you are unsure what Lead Source to use, ask on #Lead-Questions channel in Slack.
- Advertisement
- AE Generated
- CE Download
@@ -165,7 +165,6 @@ Lead Source is set upon First "known" touch attribution. It should never be chan
- External Referral
- GitLab.com
- GitLab Hosted
- GitLab Web User
- Gitorious
- Leadware
- Legacy
@@ -176,8 +175,6 @@ Lead Source is set upon First "known" touch attribution. It should never be chan
- Partner
- Public Relations
- Security Newsletter
- Seminar - Internal
- Seminar - Partner
- Trade Show
- Training Request
- Web
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