Debian has a security fix for openSSH. Organizations without GitLab walk into the office and see that 1000 applications need to be updated. Organizations with GitLab walk into the office and see that 999 applications were updated successfully and 1 had to be rolled back. We can do this because we have monitoring integrated into GitLab, we're not deploying into a black hole but can see if the application still meets the service level objectives.

Have a story version of the vision on the direction page.

1. Start with container scheduler.
2. Use web terminal and local editor to create something.
3. See auto deploy with automatic parallel tests and review apps.
4. Debian package used in your container has a security fix.
5. GitLab auto detects you have that dependency and creates a new build.
6. The changelog is updated automatically.
7. In the merge request you can see the metrics and SLO (service level objective) was not met and after deploying to 1% it was reverted.
8. All this happened automatically after Debian pushed to stable.
9. Luckily when you check the next day your application is not vulnerable.
10. So you use chat to close the issue that was automatically opened after the failed deploy.
11. An early user of your service also emailed GitLab service desk to ask if the Debian security update is addressed.
12. You create a blog post via the web terminal that is published with GitLab pages.

I'm not sure this should go on the direction page as it's severely overloaded already, but explaining our vision by using a story/flow is an effective tool.

/cc @sytses

Links

• [meta] VersionEye integration
• New site: shield.gitlab.com
• GitLab License finder
• VersionEye - Display in Merge requests list view
• VersionEye - Display information in the Merge request details view
• VersionEye - Display in Commits list view
• VersionEye - Add option to activate GitLab Version Service to the administration panel of a repository
• VersionEye - Settings panel for GitLab Version Service
• Prior art: https://depfu.io/