Commit f8ddd410 authored by Fabio Busatto's avatar Fabio Busatto

Release post - GitLab 11.5

parent bf69dc8a
......@@ -9,7 +9,7 @@ _Release post:_
_Related files:_
- **Features YAML** link: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-X-Y/data/features.yml
- **Home page banner**: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-X-Y/source/includes/hello-bar.html.haml
- **Home page banner**: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-X-Y/source/includes/home/ten-oh-announcement.html.haml
- **MVPs**: https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-X-Y/data/mvps.yml
_Handbook references:_
......@@ -46,7 +46,7 @@ The PM leading the post is responsible for adding and checking the following ite
- [ ] Update the links and due dates in this MR description
- [ ] Make sure the blog post have all initial files, as well as this MR template contains the latest template
- [ ] Add authorship (author's data)
- [ ] Ask the Marketing reviewer to add the introduction
- [ ] Ask the messaging lead to add the introduction by the 6th working day before the 22nd
- [ ] Add MVP (MVP block)
- [ ] Add MVP to `data/mvps.yml`
- [ ] Make sure the PM for the MVP feature adds a corresponding feature block if applicable, linking from the MVP section
......@@ -108,8 +108,8 @@ Tip: make your own checklist:
- Deprecations
- Documentation updated
- Documentation links added to the post
- Community contributions
- Illustrations added to the post (compressed)
- Community contributions documented and added to the post
- Illustrations added to the post (compressed, max width = 1000 pixels)
- Update `features.yml` (with accompanying screenshots)
### Review
......@@ -128,9 +128,9 @@ Performed by the author of the post: `@mention`
- [ ] Check all comments in the thread (make sure no contribution was left behind)
- [ ] Check Features' names
- [ ] Check Features' availability (Core, Starter, Premium, Ultimate badges)
- [ ] Reorder primary and secondary features according to their relevance to the user (most impactful features come first)
- [ ] Check Documentation links (all feature blocks contain `documentation_link`)
- [ ] Make sure `documentation_link` links to feature webpages when available
- [ ] Update home page banner`source/includes/hello-bar.html.haml`
- [ ] Features were added to `data/features.yml` (with accompanying screenshots)
- [ ] Check all images size < 300KB (compress them all with [TinyPNG](https://tinypng.com/) or similar tool)
- [ ] Pull `master`, resolve any conflicts
......@@ -154,7 +154,8 @@ The [structural review](https://about.gitlab.com/handbook/marketing/blog/release
- [ ] Ensure all text is consistently hard wrapped at a suitable column boundary
- [ ] Check headings are in sentence case
- [ ] Check feature and product names are in capital case
- [ ] Check that images are harmonic/consistent
- [ ] Check if images are harmonic/consistent
- [ ] Check any `.gitkeep` files and delete them if any
- [ ] Add or check cover img reference (at the end of the post). Data in `cover_img` in release post Yaml file
- [ ] Ensure content is balanced between the columns (both columns are even)
- [ ] Ensure links have [meaningful text](https://about.gitlab.com/handbook/communication/#writing-style-guidelines) for SEO (e.g., "click here" is bad link text)
......@@ -181,7 +182,7 @@ The [structural review](https://about.gitlab.com/handbook/marketing/blog/release
- [ ] Description
- [ ] Intro
- [ ] Grammar, spelling, clearness (body)
- [ ] [Homepage Blurb](https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-X-Y/source/includes/home/ten-oh-announcement.html.haml)
- [ ] Update [homepage blurb](https://gitlab.com/gitlab-com/www-gitlab-com/blob/release-X-Y/source/includes/home/ten-oh-announcement.html.haml)
- [ ] Tweet social sharing text (for Twitter, FB, and LinkedIn)
- [ ] Assign the MR to the next reviewer (marketing)
- [ ] Marketing review (PMMs - [messaging lead](https://about.gitlab.com/handbook/marketing/blog/release-posts/#messaging-lead)): `@mention`
......@@ -194,14 +195,22 @@ The [structural review](https://about.gitlab.com/handbook/marketing/blog/release
- [ ] Remove the label ~review-in-progress
- [ ] Assign the MR back to the author
### Merge it :rocket:
### On the 22nd
The author of the post is responsible for merging the MR and following up
with possible adjustments/fixes: `@mention`.
#### Last check before merging
#### At 12:00 UTC
- [ ] Read the [important notes](#important-notes) below
- [ ] At ~12:30 UTC, ping the release managers on the `#releases` Slack
channel asking if everything is on schedule, and to coordinate timing with them:
- If anything is wrong with the release, or if it's delayed, you must ping
the messaging lead on `#release-post` so that they coordinate anything scheduled
on their side (e.g., press releases, other posts, etc).
- If everything is okay, the packages should be published at [13:30 UTC](https://gitlab.com/gitlab-org/release-tools/blob/master/templates/monthly.md.erb#L155), and available
publicly around 14:10 UTC.
- Ask the release managers to ping you when the packs are publicly available (and GitLab.com is up and running on the release version)
- [ ] Mention `@dplanella` to remind him to send the swag pack to the MVP
- [ ] Check if all the anchor links in the intro are working
- [ ] Check if there are no broken links in the review app (use a dead link checker, e.g., [Check my Links](https://chrome.google.com/webstore/detail/check-my-links/ojkcdipcgfaekbeaelaapakgnjflfglf))
......@@ -209,20 +218,29 @@ with possible adjustments/fixes: `@mention`.
- [ ] Check if there isn't any alert on Slack's `#release-post` and `#general` channels
- [ ] Check if there isn't any alert on this MR thread
- [ ] Check if the tweet copy is ready and someone is ready to share on social media
- [ ] Ask the release managers to ping you when the packs are publicly available (and GitLab.com is up and running on the release version)
- [ ] Unlock [`features.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml) just before merging
- [ ] Merge the MR
- [ ] Wait for the pipeline
- [ ] Check the look on social media with [Twitter Card Validator](https://cards-dev.twitter.com/validator) and [Facebook Debugger](https://developers.facebook.com/tools/debug/)
- [ ] Check for broken links again once the post is live
- [ ] Share on social media (or make sure someone else does) only when you're sure everything is okay
#### At 13:50 UTC
- [ ] Check if there aren't any conflicts. If there are any, pull `master` again and fix them.
Once the release manager confirmed that the packages are publicly available:
- [ ] Unlock [`features.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml) just before merging.
- [ ] Merge the MR at 14:10-14:20 UTC.
- [ ] Wait for the pipeline. It should take ~40min to complete.
- [ ] Check the look on social media with [Twitter Card Validator](https://cards-dev.twitter.com/validator) and [Facebook Debugger](https://developers.facebook.com/tools/debug/).
- [ ] Check for broken links again once the post is live.
- [ ] Share on social media (or make sure someone else does) only when you're sure everything is okay.
- [ ] Share the links to the post and to the tweet on the `#release-posts` and
`#general` on Slack.
#### Important notes
- The post is to be live on the **22nd** at 15:00 UTC. It should be merged and as soon as
GitLab.com is up and running on the new release version (or the latest RC that has the same features as the release), and once all packages
are publicly available. Not before. Ideally, merge it around 14:20 UTC as the pipeline takes about
40 min to run.
- The post is to be live on the **22nd** at **15:00 UTC**. It should be merged and
as soon as GitLab.com is up and running on the new release version (or the latest
RC that has the same features as the release), and once all packages are publicly
available. Not before. Ideally, merge it around 14:20 UTC as the pipeline takes
about 40 min to run.
- The usual release time is **15:00 UTC** but it varies according to
the deployment. If something comes up and delays the release, the release post
will be delayed with the release.
......@@ -231,6 +249,9 @@ will be delayed with the release.
keep you in the loop. Ideally, the packages should be published around
13:30-13:40, so they will be publicly available around 14:10 and you'll
be able to merge the post at 14:20ish.
- Once the post is live, wait a few minutes to see if no one spot an error (usually posted in #general),
then share on Twitter, Facebook, and LinkedIn, or make sure someone (Emily vH, JJ, Marcia) does. Coordinate the social sharing with them **beforehand**.
- Keep an eye on Slack and in the blog post comments for a few hours to make sure no one found anything that should be fixed
- Once the post is live, wait a few minutes to see if no one spot an error
(usually posted in #general), then share on Twitter, Facebook, and LinkedIn,
or make sure someone (Emily vH, JJ, Marcia) does. Coordinate the social sharing
with them **beforehand**.
- Keep an eye on Slack and in the blog post comments for a few hours to make sure
no one found anything that should be fixed.
......@@ -1563,7 +1563,10 @@ features:
ca_agile_central: false
redmine: true
- title: "Create merge request from email"
description: "Create a merge request from email by sending in the merge request title, description, and source branch name."
description: |
Create a merge request from email by sending in the merge request title,
description, and source branch name. Alternatively use patch files to
create a merge request without first pushing a branch.
link_description: "Create merge request from email"
link: https://docs.gitlab.com/ee/user/project/merge_requests/index.html#create-new-merge-requests-by-email
category:
......@@ -2209,7 +2212,10 @@ features:
hours_per_incident: 0.08
incidents_per_year: 75
- title: "Remote repository push mirroring"
description: "Mirror a repository from your local server to elsewhere."
description: |
Mirror a repository from your local server to elsewhere. Push mirroring
is supported via HTTP and SSH using password authentication, and using
public-key authentication with SSH.
link_description: "Learn more about repository push mirroring"
link: https://docs.gitlab.com/ee/workflow/repository_mirroring.html
category:
......@@ -2345,6 +2351,18 @@ features:
shorthand: "export_issues"
hours_per_incident: 0.25
incidents_per_year: 100
- title: "Issue Analytics"
description: "See issue analytics at the group level."
link_description: "Learn more about Issue Analytics"
link: 'https://docs.gitlab.com/ee/user/group/#issues-analytics-premium'
screenshot_url: 'images/feature_page/screenshots/issue-analytics.png'
category:
- project_management
gitlab_core: false
gitlab_starter: false
gitlab_premium: true
gitlab_ultimate: true
gitlab_com: true
- title: "Admin Control"
description: "GitLab Enterprise Edition gives your administrator the ability to automatically sync groups and manage SSH-keys, permissions, and authentication, so you can focus on building your product, not configuring your tools."
link_description: "View the administration documentation"
......@@ -2748,7 +2766,13 @@ features:
gitlab_ultimate: true
azure_devops: false
- title: "Inline commenting and discussion resolution"
description: "Code or text review is faster and more effective with inline comments in merge requests. Leave comments and resolve discussions on specific lines of code. In GitLab, Merge Request inline comments are interpreted as a discussion. You can configure your project to only accept merge requests when all discussions are resolved."
description: |
Code or text review is faster and more effective with inline comments in
merge requests. Leave comments and resolve discussions on specific lines
of code. In GitLab, Merge Request inline comments are interpreted as a
discussion and can be left on any line, changed or unchanged. You can
configure your project to only accept merge requests when all discussions
are resolved.
link: https://docs.gitlab.com/ee/user/discussions/#resolvable-discussions
link_description: "Learn more about resolving discussions"
category:
......@@ -4510,15 +4534,15 @@ features:
description: |
Use a noreply email address for your commits instead of your personal
email address private.
link_description: "See the GitLab issue to implement this"
link: https://gitlab.com/gitlab-org/gitlab-ce/issues/43521
link_description: "Learn more about private commit email addresses"
link: 'https://docs.gitlab.com/ee/user/profile/#private-commit-email'
category:
- source_code_management
gitlab_core: false
gitlab_starter: false
gitlab_premium: false
gitlab_ultimate: false
gitlab_com: false
gitlab_core: true
gitlab_starter: true
gitlab_premium: true
gitlab_ultimate: true
gitlab_com: true
github: true
- title: "Kubernetes Cluster Monitoring"
description: |
......@@ -4978,11 +5002,11 @@ features:
gitlab_ultimate: true
gitlab_com: true
github: false
- title: "Custom file templates"
- title: "Instance file templates"
description: |
Define custom `LICENSE`, `.gitignore`, `Dockerfile` and `.gitlab-ci.yml`
templates to make consistency easier.
link_description: "Learn more about custom file templates"
templates for your GitLab instance to make consistency easier.
link_description: "Learn more about custom instance file templates"
link: "https://docs.gitlab.com/ee/user/admin_area/settings/instance_template_repository.html"
category:
- source_code_management
......@@ -4993,11 +5017,26 @@ features:
gitlab_ultimate: true
gitlab_com: false
github: false
- title: "Group file templates"
description: |
Define custom `LICENSE`, `.gitignore`, `Dockerfile` and `.gitlab-ci.yml`
templates for a Group to make consistency easier.
link_description: "Learn more about custom group file templates"
link: "https://docs.gitlab.com/ee/user/group/#group-file-templates-premium"
category:
- source_code_management
- continuous_integration
gitlab_core: false
gitlab_starter: false
gitlab_premium: true
gitlab_ultimate: true
gitlab_com: true
github: false
- title: "Code Owners"
description: |
Assign Code Owners to files to indicate the team members responsible for
code in your project using a `CODEOWNERS` file. Code owners are suggested
as merge request approvers, and shown when viewing files.
code in your project using a `CODEOWNERS` file. Code owners are assigned
automatically as merge request approvers, and shown when viewing files.
link_description: "Learn more about Code Owners"
link: "https://docs.gitlab.com/ee/user/project/code_owners.html"
category:
......@@ -5110,9 +5149,10 @@ features:
tfs_vsts: false
- title: "Merge request reviews"
description: |
Write multiple saved draft comments in a merge request code review, before
submitting them together all at once. This allows you to review code in
consistent, and self-contained sessions, instead of as individual comments.
Draft multiple comments in a merge request code review, before reviewing
and submitting them together all at once. This allows you to review code
in consistent, and self-contained sessions, instead of as individual
comments.
link_description: "Learn more about batch comments in merge requests"
link: 'https://docs.gitlab.com/ee/user/discussions/index.html#merge-request-reviews-premium'
screenshot_url: 'images/feature_page/screenshots/batch-comments.png'
......@@ -5256,3 +5296,15 @@ features:
gitlab_ultimate: false
gitlab_com: false
gerrit: true
- title: "Easily view traces in Jaeger"
description: "Users can easily open the Jaeger UI and view traces, from GitLab."
solution: monitor
category:
- tracing
link_description: "Read more on the issue"
link: https://gitlab.com/gitlab-org/gitlab-ee/issues/4753
gitlab_core: false
gitlab_starter: false
gitlab_premium: false
gitlab_ultimate: true
gitlab_com: true
- version: 11.5
name: "Tuomo Ala-Vannesluoma"
gitlab: tuomoa
date: "November 22, 2018"
- version: 11.4
name: "Luke Picciau"
gitlab: Qwertie
......
This diff is collapsed.
......@@ -9,6 +9,7 @@ description: "GitLab X.Y released with Feature A, Feature B, Feature C, Feature
twitter_image: '/images/tweets/gitlab-X-Y-released.png' # social sharing image - not required but recommended
categories: releases # required
layout: release # required
featured: yes
# header_layout_dark: true #uncomment if the cover image is dark
# release_number_dark: true #uncomment if you want a dark release number
---
......@@ -24,25 +25,32 @@ Read through the Release Posts Handbook for more information:
https://about.gitlab.com/handbook/marketing/blog/release-posts/
-->
Introductory paragraph.
Introduction.
<!--
Suggestion (to help you to get started): in one paragraph, summarize what are
he most important _achievements_ of this release. Focus on the most impactful
things. E.g., improvements to performance, collaboration, quality assurance,
high availability, security, etc.
-->
[Markdown](/handbook/product/technical-writing/markdown-guide/) supported.
<!-- more -->
Apply the class `{: .intro-header}` for `h2` headings and `{:.intro-header-h3}` for `h3`:
Introduction.
```md
## `h2` Heading
{: .intro-header}
[Markdown](/handbook/product/technical-writing/markdown-guide/) supported.
### `h3` Heading
{:.intro-header-h3}
```
Which will render:
## Heading
{: .intro-header}
### `h3` Heading
{:.intro-header-h3}
<!--
Suggestion: describe each feature briefly in just a few words, using
anchors to link to their headers. The intro is supposed to be eyes-catching,
so "be happy" about it, describe them enthusiastically. Focus on what are the
advantages on having each of them. For some guidance, look at the intros of
past release posts.
anchors to link to their headings (use the relative path). The intro is supposed
to be eyes-catching, so "be happy" about it, describe them enthusiastically.
Focus on what are the advantages on having each of them. For some guidance,
look at the intros of past release posts.
-->
.hello-bar-wrapper
%a.hello-bar.animated.hello-bar-dark{ href: '/2018/09/22/gitlab-11-3-released/' }
%a.hello-bar.animated.hello-bar-dark{ href: '/2018/11/22/gitlab-11-5-released/' }
.hello-bar-content
-# = image_tag "/images/home/gcp-logo.png", srcset: "/images/home/gcp-logo@2x.png 2x"
%p
GitLab 11.3 released with Maven intergration, protected environments, code owners, and much more!
GitLab 11.5 released with Serverless, access control for Pages and much more!
%section.ten-oh-announcement
.ten-oh-label
%span 11.4
%span 11.5
.ten-oh-description
.container
.row
......@@ -8,7 +8,8 @@
.ten-oh-description-body.text-center
%h2.main-heading New features every month
%p.u-margin-bottom-xs
This month’s release of GitLab 11.4 includes Merge Request Reviews, Feature Flags, Git protocol v2, and much more!
This month’s release of GitLab 11.5 includes the Group Security Dashboard, Operations Dashboard, Access Control for Pages and much more!
.btn-group
%a.btn.cta-btn.btn-white.margin-top20.hero-cta.hero-release-link{href: "/2018/10/22/gitlab-11-4-released/"}
%a.btn.cta-btn.btn-white.margin-top20.hero-cta.hero-release-link{href: "/2018/11/22/gitlab-11-5-released/"}
See what’s new
---
release_number: "11.5"
title: "GitLab 11.5 released with Group Security and Operations Dashboards, and Access Control for Pages"
author: Fabio Busatto
author_gitlab: bikebilly
image_title: '/images/11_5/11_5-cover-image.jpg'
description: "GitLab 11.5 released with Security Dashboard, Operations Dashboard, Access Control for Pages and much more!"
twitter_image: '/images/tweets/gitlab-11-5-released.png'
categories: releases
layout: release
header_layout_dark: true
featured: yes
---
## Group dashboard for security teams
{: .intro-header}
For a long time, developers have used GitLab as a tool to secure their code. But now,
GitLab is making security teams first-class citizens so they can use GitLab to effect better application security and ensure compliance. With 11.5, the
[Group Security Dashboard](#group-security-dashboard) pulls together all of the information security personnel need into one place, so folks like CISOs,
CIOs, and application security leaders get a specific view designed for them.
The group dashboard has a redesigned look and new visualizations, bringing together
security information across multiple projects and providing a high-level view while
also enabling the ability to drill down into specific reports. With 11.5, we're
starting with SAST reports, and we'll be adding more to the group dashboard in
the future. Our goal is to build a single tool that security teams can use
instead of needing to switch back and forth between multiple tools.
## New dashboard for operations teams
{: .intro-header}
In the same way that the Group Security Dashboard makes security teams first-class citizens, the [Operations Dashboard](#operations-dashboard) provides a
tailored experience for operations professionals. This instance-wide dashboard
provides a single view across projects to get a summary of each project’s
operational health, including pipeline and alert status.
## Control access to GitLab Pages
{: .intro-header}
[GitLab Pages](/product/pages/) is an easy way to
serve static content on the web, making it perfect for use cases such as
documentation for your project. But what about private projects where
documentation and other static artifacts should only be accessed by project
members? In the past, you'd either have to make your assets public to take
advantage of Pages, or you would not be able to use the feature at all.
Now, in GitLab 11.5, the same access control permissions that apply to your
issues and code can also be applied to static webpages served by GitLab Pages.
Unauthenticated users will get a 404 when visiting the link. As of today,
[access controls for GitLab pages](#access-control-for-pages) is available for self-managed GitLab,
with GitLab.com support coming soon.
This is a unique feature that we're particularly proud of because it comes
from our open source community. Access control for Pages has been one of our
[most requested features](https://gitlab.com/gitlab-org/gitlab-ce/issues/33422)
and [the code has been community contributed](https://gitlab.com/gitlab-org/gitlab-pages/merge_requests/94) as well!
## Knative for Kubernetes
{: .intro-header}
“Serverless” is a popular, yet often misunderstood industry term. Some folks equate
serverless with "Function as a Service," or FaaS, but this [isn't quite accurate](https://martinfowler.com/articles/serverless.html). In a nutshell, serverless enables a programming paradigm where you are able
to focus on writing business logic without having to understand or even
worry about the underlying infrastructure where your software is deployed.
As such, both functions and applications can be serverless.
[Knative](https://cloud.google.com/knative/) is a Kubernetes-based platform
to build, deploy, and manage modern serverless workloads, and GitLab 11.5
comes with the ability to [easily deploy and integrate Knative with GitLab](#easily-deploy-and-integrate-knative-with-gitlab). You can now install Knative to your [connected Kubernetes cluster](/solutions/kubernetes/) with a single click. With GitLab 11.5, you'll be able to use Knative for your serverless applications, with
[serverless functions coming in 11.6](https://gitlab.com/gitlab-org/gitlab-ce/issues/43959).
Today, Knative is still in alpha, but there are some compelling reasons to deploy applications using Knative as it comes with some powerful functionality out-of-the-box. In particular, Knative manages pod scaling for you so you can automatically scale up, or even scale down to zero without additional configuration. Additionally, Knative comes with eventing built in so using it to deploy microservices makes it easier to manage inter-process communication between your producer and consumer services.
## And so much more!
{: .intro-header}
With so many great features in this release, we couldn't pack them all into
the intro. Be sure to read up on other exciting new features like
[the parallel attribute for faster pipelines](#parallel-attribute-for-faster-pipelines),
[redesigned Issue Board cards](#issue-board-cards-redesigned), and an initial
[Jaeger integration](#open-jaeger-from-gitlab).
We’ve made big improvements in this release to make code review easier and more useful, including the ability to
[comment on unchanged lines in merge requests](#comment-on-unchanged-lines-in-merge-request),
[preview merge request reviews before submitting](#preview-merge-request-review-before-submitting-it), and
[assign approvers based on Code Owners](#assign-approvers-based-on-code-owners) along with
[Review App direct links](#review-app-direct-link).
Keep reading to see all of the features that are part of this release.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment