Commit 1439cc16 authored by Rebecca Dodd's avatar Rebecca Dodd

Update categories

parent de1f148a
Pipeline #19573747 passed with stages
in 13 minutes and 56 seconds
......@@ -2,7 +2,7 @@
title: "GitLab 8.12.7 released"
author: Rémy Coutable
author_twitter: rymai
categories: release
categories: Releases
---
Today we are releasing version 8.12.7 for GitLab Community Edition (CE) and
......
......@@ -2,7 +2,7 @@
title: Why We Chose GitLab CI for our CI/CD Solution
author: James Dang
author_twitter: JamesDangry
categories: GitLab CI
categories: GitLab news
image_title: '/images/blogimages/gitlab-ci-oohlala-cover.png'
description: "Find out why we choose GitLab CI and what we've found through our experience using it."
twitter_image: '/images/tweets/gitlab-ci-oohlala.png'
......@@ -10,59 +10,59 @@ date: 2016-10-17 03:35
---
At [OOHLALA Mobile][oohlala], our testing and deployment of code is done
through Fabric, essentially a set of Python scripts (called “fabfiles”) that
are executed on various servers. Recently, we started looking for a [CI/CD solution][ci-cd]
that help manage our fabfile deployment system, which is growing
more complex each day. In the end, we went with [GitLab CI][gitlab-ci], and here’s what we
At [OOHLALA Mobile][oohlala], our testing and deployment of code is done
through Fabric, essentially a set of Python scripts (called “fabfiles”) that
are executed on various servers. Recently, we started looking for a [CI/CD solution][ci-cd]
that help manage our fabfile deployment system, which is growing
more complex each day. In the end, we went with [GitLab CI][gitlab-ci], and here’s what we
found through our experience.
## Simple to Use
Since the bulk of the work is done in Fabric, the CI/CD solution can be very simple,
as it only needs to be able to execute fabfiles. GitLab CI’s shell executor is perfect
Since the bulk of the work is done in Fabric, the CI/CD solution can be very simple,
as it only needs to be able to execute fabfiles. GitLab CI’s shell executor is perfect
for this. The complexities of other solutions (e.g. Jenkins) are unnecessary for us.
## Fast
We will be using the system for all code deploys, including development and QA environments,
so the CI/CD system needs to be fast, to keep up with the fast-paced changes required for
development. Primarily Docker based solutions, such as CircleCI, took considerably longer
to run due to the dependency set up stage. With GitLab CI, we can set up our own runner
We will be using the system for all code deploys, including development and QA environments,
so the CI/CD system needs to be fast, to keep up with the fast-paced changes required for
development. Primarily Docker based solutions, such as CircleCI, took considerably longer
to run due to the dependency set up stage. With GitLab CI, we can set up our own runner
with all dependencies pre-installed, and **jobs are executed really fast**.
We would like to have a solution that can be installed on arbitrary hardware, specifically
our own dedicated macOS and Windows machines that perform our mobile app CI/CD for iOS and
Android respectively. The reasoning is that in the future we may use the same CI/CD service
for our mobile teams as well. GitLab CI can do this for free, as we can simply install GitLab
runners on our dedicated machines. Other CI solutions (e.g. Travis CI, CircleCI etc.)
do offer mobile CI/CD solutions, but will not meet our requirements since we need our in-house
We would like to have a solution that can be installed on arbitrary hardware, specifically
our own dedicated macOS and Windows machines that perform our mobile app CI/CD for iOS and
Android respectively. The reasoning is that in the future we may use the same CI/CD service
for our mobile teams as well. GitLab CI can do this for free, as we can simply install GitLab
runners on our dedicated machines. Other CI solutions (e.g. Travis CI, CircleCI etc.)
do offer mobile CI/CD solutions, but will not meet our requirements since we need our in-house
build and deploy scripts on dedicated hardware to effectively manage the hundreds of mobile apps that we maintain.
## Economical and Secure
## Economical and Secure
The solution should be relatively economical, especially since our development team
is still relatively small. Most CI solutions are relatively expensive (e.g. Travis
CI starts at $129/month minimum), and the ones that have free tiers are very
limited in capacity (e.g. CircleCI and Shippable both allow only 1 concurrent
job on their free tier). GitLab CI only costs as much as the machine used to run it,
is still relatively small. Most CI solutions are relatively expensive (e.g. Travis
CI starts at $129/month minimum), and the ones that have free tiers are very
limited in capacity (e.g. CircleCI and Shippable both allow only 1 concurrent
job on their free tier). GitLab CI only costs as much as the machine used to run it,
which is very flexible (a $40/month DO instance can run many concurrent jobs without issue).
Ideally (i.e. not a hard requirement), we would like to keep all SSH private keys
within our own infrastructure for better security. With most other CI solutions,
we would have to hand them the private keys for all the servers we need to deploy to.
With GitLab CI, the keys are stored on the CI runner instance, which is hosted by us
Ideally (i.e. not a hard requirement), we would like to keep all SSH private keys
within our own infrastructure for better security. With most other CI solutions,
we would have to hand them the private keys for all the servers we need to deploy to.
With GitLab CI, the keys are stored on the CI runner instance, which is hosted by us
and fully under our control.
In the end, we actually chose to host our code on [GitLab.com][gitlab-com], because of the seamless
integration with GitLab CI. There weren’t any major differences in features
(at least ones that we wanted) in the repository hosting solutions we looked at
In the end, we actually chose to host our code on [GitLab.com][gitlab-com], because of the seamless
integration with GitLab CI. There weren’t any major differences in features
(at least ones that we wanted) in the repository hosting solutions we looked at
(GitHub, Gogs, and GitLab mostly), and the CI solution made the choice easier.
## About the author
James Dang is the co-founder the CTO of [OOHLALA Mobile][oohlala], an education technology
company building the mobile platform for universities and colleges to connect and
engage with their students.
James Dang is the co-founder the CTO of [OOHLALA Mobile][oohlala], an education technology
company building the mobile platform for universities and colleges to connect and
engage with their students.
<!-- identifiers -->
......
---
title: "GitLab UX Update"
title: "GitLab UX update"
author: Allison Whilden
author_twitter: awhildy
categories: gitlab
categories: GitLab news
image_title: "/images/blogimages/ux-update-2016-10/gitlabdesign-cover-image.jpg"
description: "Inside GitLab: Sneak peek of what the UX Team is working on"
twitter_image: '/images/tweets/gitlab-ux-update.png'
......@@ -16,7 +16,7 @@ The UX Team at GitLab has been hard at work, and I'm delighted to share a sneak
### Better Empty States
Empty states are easy to forget about. However, they can be great moments to celebrate an accomplishment (you finished all of your [Todos][todo-empty-state]!) or explain a concept (when to use a [group][group-empty-state]).
Empty states are easy to forget about. However, they can be great moments to celebrate an accomplishment (you finished all of your [Todos][todo-empty-state]!) or explain a concept (when to use a [group][group-empty-state]).
![Better Empty States](/images/blogimages/ux-update-2016-10/empty-states.png)
......@@ -40,13 +40,13 @@ With the next iteration of [Cycle Analytics][cycle-analytics], we are helping br
### Refining the Review Apps Experience
We are continuing to polish our Review Apps experience, allowing you to [stop apps][stop-review-apps], and [group environments][group-environments].
We are continuing to polish our Review Apps experience, allowing you to [stop apps][stop-review-apps], and [group environments][group-environments].
![Review App experience refinements](/images/blogimages/ux-update-2016-10/review-apps.png)
## What's Next?
We are already jumping into more work, from [standardizing and cleaning up our many settings pages][settings], to adding such useful visuals as [burndown charts][burndown]. We are also digging into large open question such as refining the [personality][personality] of GitLab.
We are already jumping into more work, from [standardizing and cleaning up our many settings pages][settings], to adding such useful visuals as [burndown charts][burndown]. We are also digging into large open question such as refining the [personality][personality] of GitLab.
We love getting feedback! Please share your thoughts on the designs by commenting below, joining the discussions in any of the issues linked above, or opening a [new issue][new-issue] to let us know what else we should consider. Thanks!
......@@ -57,7 +57,7 @@ The design work on this page was created by [Hazel Yang][hazel], [Chris Peressin
<!-- identifiers -->
<!-- identifiers -->
[burndown]: https://gitlab.com/gitlab-org/gitlab-ee/issues/91
[chris]: https://twitter.com/ChrisPeressini
[cycle-analytics]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22458
......@@ -73,4 +73,4 @@ The design work on this page was created by [Hazel Yang][hazel], [Chris Peressin
[stop-review-apps]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22191
[taurie]: https://twitter.com/tauried
[time-tracking]: https://gitlab.com/gitlab-org/gitlab-ee/issues/985
[todo-empty-state]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20833
\ No newline at end of file
[todo-empty-state]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20833
---
title: 'Why We Chose Vue.js'
title: 'Why we chose Vue.js'
author: Jacob Schatz
author_twitter: jakecodes
categories: gitlab
categories: GitLab news
image_title: '/images/default-blog-image.png'
description: 'Why GitLab went with Vue.js'
twitter_image: '/images/tweets/why-choose-vuejs.png'
......@@ -100,6 +100,6 @@ learn, a supporting cast of libraries and plugins to help users solve the hard p
and short feedback loops based on user feedback to keep the framework relevant. Vue.js is all
of that, *plus* great code. That's why we're using it. What about you?
## Watch the Why We Chose Vue.js webcast
## Watch the Why We Chose Vue.js webcast
<iframe width="560" height="315" src="https://www.youtube.com/embed/ioogrvs2Ejc" frameborder="0" allowfullscreen></iframe>
---
title: "GitLab 8.13 Released with Multiple Issue Boards and Merge Conflict Editor"
categories: release
categories: Releases
author: Job van der Voort
author_twitter: Jobvo
image_title: /images/8_13/header.jpg
......
---
title: 'My first weeks at GitLab - How we ship so quickly'
title: 'My first weeks at GitLab: How we ship so quickly'
author: Sean Packham
author_twitter: SeanPackham
categories: inside GitLab
categories: GitLab news
image_title: '/images/default-blog-image.png'
description: 'How we move so quickly and create so much at GitLab'
---
About 2 months ago I joined GitLab and in that time I have seen 2 new releases,
About two months ago I joined GitLab and in that time I have seen two new releases,
had the quickest and smoothest team onboarding I have ever had,
pushed dozens of changes and
have gotten to know almost everyone in GitLab.
......@@ -17,16 +17,16 @@ So how do we move and ship so quickly at GitLab?
## 1. Communication
At GitLab we are a [remote only](http://remoteonly.org/) company which means communication is essential.
At GitLab we are a [remote-only](http://remoteonly.org/) company which means communication is essential.
### The GitLab Handbook
We have to diligently record and document knowledge to be efficient.
The result is if you ask any GitLab team member an organizational question
the answer is always "It's in the handbook".
the answer is always "It's in the handbook."
Our [handbook](https://about.gitlab.com/handbook/) is public, copy it, adapt it and make it your own.
> "It's in the handbook" - Everyone who's been at GitLab for more than 2 weeks
> "It's in the handbook" - Everyone who's been at GitLab for more than two weeks
### Reporting
......
......@@ -2,7 +2,7 @@
title: "GitLab 8.13.1 released"
author: Rémy Coutable
author_twitter: rymai
categories: release
categories: Releases
---
Today we are releasing version 8.13.1 for GitLab Community Edition (CE) and
......
......@@ -2,7 +2,7 @@
title: "GitLab Workflow: An Overview"
author: Marcia Ramos
author_twitter: XMDRamos
categories: GitLab workflow
categories: Tutorials
image_title: '/images/blogimages/git_workflow.jpg'
description: "The software development lifecycle in one single interface!"
---
......
......@@ -2,7 +2,7 @@
title: "GitLab 8.13.2 released"
author: Rémy Coutable
author_twitter: rymai
categories: release
categories: Releases
---
Today we are releasing version 8.13.2 for GitLab Community Edition (CE) and
......
......@@ -3,7 +3,7 @@ title: "GitLab Major Security Update for CVE-2016-9086"
date: 2016-10-31
author: Brian Neel
author_twitter: b0bby_tables
categories: Security
categories: Releases
tags: security, gitlab
---
......
......@@ -3,15 +3,15 @@ title: "GitLab 8.13.3, 8.12.8, 8.11.10, and 8.10.13 Released"
date: 2016-11-02 23:50
author: GitLab
author_twitter: gitlab
categories: Security
categories: Releases
tags: security, gitlab
---
Today we are releasing versions 8.13.3, 8.12.8, 8.11.10, and 8.10.13 for GitLab
Today we are releasing versions 8.13.3, 8.12.8, 8.11.10, and 8.10.13 for GitLab
Community Edition (CE) and Enterprise Edition (EE).
These versions contain an important security fix for a critical directory
traversal vulnerability, and we **strongly recommend** that all GitLab
These versions contain an important security fix for a critical directory
traversal vulnerability, and we **strongly recommend** that all GitLab
installations be upgraded to one of these versions **immediately**.
Please read on for more details.
......@@ -20,16 +20,16 @@ Please read on for more details.
## Directory traversal via "import/export" feature: `CVE-2016-9086`
[Jobert Abma] from [HackerOne] disclosed a critical security flaw in the "import/export
project" feature of GitLab. Added in GitLab 8.9, this feature allows a user to
[Jobert Abma] from [HackerOne] disclosed a critical security flaw in the "import/export
project" feature of GitLab. Added in GitLab 8.9, this feature allows a user to
export and then re-import their projects as tape archive files (tar). All
GitLab versions prior to 8.13.0 restricted this feature to administrators only.
Starting with version 8.13.0 this feature was made available to all users.
This feature did not properly check for symbolic links in user-provided archives
and therefore it was possible for an authenticated user to retrieve the contents
of any file accessible to the GitLab service account. This included sensitive
files such as those that contain secret tokens used by the GitLab service to
of any file accessible to the GitLab service account. This included sensitive
files such as those that contain secret tokens used by the GitLab service to
authenticate users. Please see [the issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/23822) for more details.
This issue has been assigned [CVE-2016-9086][CVE].
......@@ -54,7 +54,7 @@ below.
### Workarounds
If you're unable to upgrade right away, you can secure your GitLab installation
against this vulnerability using the workaround outlined below until you have
against this vulnerability using the workaround outlined below until you have
time to upgrade.
#### Disable Project Import/Export via Tape Archive
......
---
title: Global Developer Survey Reveals Need for More Collaborative Workflows
title: Global Developer Survey reveals need for more collaborative workflows
author: Erica Lindberg
author_twitter: EricaLindberg_
categories: press
categories: DevOps
image_title: '/images/blogimages/ee-survey-2016-cover-3.png'
description: "New survey examines how modern developers prefer to work."
description: "New survey examines how modern developers prefer to work."
twitter_image: '/images/tweets/enterprise-survey-2016.png'
---
......@@ -15,29 +15,29 @@ twitter_image: '/images/tweets/enterprise-survey-2016.png'
&nbsp;&nbsp;<i class="fa fa-gitlab" style="color:rgb(107,79,187); font-size:.85em" aria-hidden="true"></i>
{: .alert .alert-webcast}
Technology trends move fast. In the time it takes to build a new program or
feature, the very problem you're trying to solve can become obsolete. It's not
just competitors you're worried about but the rapid pace of advancement in
technology that can pit products within a single company against each other.
Keep your head down too long on one project, and the rest of the development
world has not only moved onto something new, they're using a brand new
Technology trends move fast. In the time it takes to build a new program or
feature, the very problem you're trying to solve can become obsolete. It's not
just competitors you're worried about but the rapid pace of advancement in
technology that can pit products within a single company against each other.
Keep your head down too long on one project, and the rest of the development
world has not only moved onto something new, they're using a brand new
set of tools you've never heard of to build it.
<!-- more -->
<!-- more -->
Rapid acceleration in the technology
industry is nothing new. Moore's law predicted this phenomenon as early as 1965
Rapid acceleration in the technology
industry is nothing new. Moore's law predicted this phenomenon as early as 1965
and over the last 35 years, we've all experienced the overwhelming takeover of
technology, software, and digital devices. What's surprising is there are massive development teams attempting to do revolutionary work at a
revolutionary pace, while still using outdated systems and methods of software development.
technology, software, and digital devices. What's surprising is there are massive development teams attempting to do revolutionary work at a
revolutionary pace, while still using outdated systems and methods of software development.
In an era where speed and time to market matter most, these technology companies
are sabotaging their bottom line. In fact, a business analyst at Forrester
went so far as to say "['Evolve or Crumble' is one of the most important things
In an era where speed and time to market matter most, these technology companies
are sabotaging their bottom line. In fact, a business analyst at Forrester
went so far as to say "['Evolve or Crumble' is one of the most important things
you will read this year.][forrester-blog-odonnell]"
While businesses struggle to keep up with cutting edge systems, processes, and
technologies, developers are demanding the latest development tools and
While businesses struggle to keep up with cutting edge systems, processes, and
technologies, developers are demanding the latest development tools and
more collaborative ways of working in order to ship code faster. Managers take note:
![infographic](/images/blogimages/enterprise-survey-2016-infographic.png){: .shadow}
......@@ -45,33 +45,33 @@ more collaborative ways of working in order to ship code faster. Managers take n
Our survey reveals that the vast majority of developers work with open source tools. A distributed version control system, and more specifically, Git, is the
most important tool used in everyday work. Developers have a strong desire to work
with the latest tools and methods, yet nearly half say their team doesn't have
a good handle on the latest dev best practices.
a good handle on the latest dev best practices.
## Give Developers What They Want
## Give Developers What They Want
Developers are feeling the pressure to move faster from idea to production.
Unfortunately, unclear direction and outdated tools and techniques are slowing
down the process. Luckily for DevOps and IT managers, there is a strong correlation
between what devs want and what businesses need, but leadership must be willing to
embrace the changes required to get there.
Developers are feeling the pressure to move faster from idea to production.
Unfortunately, unclear direction and outdated tools and techniques are slowing
down the process. Luckily for DevOps and IT managers, there is a strong correlation
between what devs want and what businesses need, but leadership must be willing to
embrace the changes required to get there.
At the core of what devs want and what businesses need is a more iterative and
collaborative process for software development. Eighty-one percent of developers say that
chat and collaboration tools (such as Slack, HipChat, etc.) are very or extremely
At the core of what devs want and what businesses need is a more iterative and
collaborative process for software development. Eighty-one percent of developers say that
chat and collaboration tools (such as Slack, HipChat, etc.) are very or extremely
important to their everyday work. In the brave new world of software development,
rigid processes are replaced with more natural ways of communicating, which in turn
improve the efficiency and speed of a team.
improve the efficiency and speed of a team.
### Conversational Development is the new Agile.
Software development methodologies have come a long way over the last few decades:
Software development methodologies have come a long way over the last few decades:
Scrum replaced the inflexible Waterfall Method, and Agile improved the time-consuming
method of Scrum. Now, as more development teams are distributed globally and the market
method of Scrum. Now, as more development teams are distributed globally and the market
demands speed and innovation, a more flexible process is needed.
In our more networked society, communication is instanenous and constant. With more
In our more networked society, communication is instanenous and constant. With more
conversations happening in multiple places during the software development lifecycle,
a process that puts conversation at the center is needed.
a process that puts conversation at the center is needed.
{::options parse_block_html="false" /}
......@@ -79,22 +79,22 @@ a process that puts conversation at the center is needed.
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
Conversational Development (ConvDev) is a natural process of accelerating the
development lifecycle that threads a conversation through every step of the
development lifecycle that threads a conversation through every step of the
development process. With ConvDev, gatekeepers become a part of the conversation
and can monitor the entire process - starting with an idea all the way to production. Cycle time
is reduced by threading all conversations through every stage of the development lifecycle.
is reduced by threading all conversations through every stage of the development lifecycle.
As developers continue to gain control over the tools they use at work, there will be an
even greater push to choose open source and Git, and to adopt workflows that are
As developers continue to gain control over the tools they use at work, there will be an
even greater push to choose open source and Git, and to adopt workflows that are
naturally collaborative. Teams that can ship quicker, smaller changes are poised
to dominate the market.
to dominate the market.
<i class="fa fa-gitlab" style="color:rgb(107,79,187); font-size:.85em" aria-hidden="true"></i>&nbsp;&nbsp;
[Get the complete 2016 Enterprise Survey Report here][report-lp].
&nbsp;&nbsp;<i class="fa fa-gitlab" style="color:rgb(107,79,187); font-size:.85em" aria-hidden="true"></i>
{: .alert .alert-webcast}
<!-- identifiers -->
<!-- identifiers -->
[forrester-blog-odonnell]: http://blogs.forrester.com/glenn_odonnell/16-09-13-tech_vendors_must_evolve_or_crumble_the_report_you_must_read
[report-lp]: https://page.gitlab.com/2016-Developer-Survey_2016-Developer-Survey.html
\ No newline at end of file
[report-lp]: https://page.gitlab.com/2016-Developer-Survey_2016-Developer-Survey.html
---
title: '3 Things I Learned in My First Month at GitLab'
title: '3 things I learned in my first month at GitLab'
author: Emily von Hoffmann
author_twitter: emvonhoffmann
categories: inside GitLab
categories: GitLab news
image_title: '/images/blogimages/three-things-i-learned-in-my-first-month-at-gitlab.jpg'
description: 'Adapting to life at GitLab--marketing edition!'
date: 2016-11-02 15:35
date: 2016-11-02 15:35
---
I rang in my first month at GitLab in spectacular fashion, by meeting up with team members for our NYC [World Tour](https://about.gitlab.com/2016/09/28/world-tour-amplify-your-code/) stop. The only real surprise in meeting team members in person — after weeks of daily Hangouts — is height (hopefully by force of my personality, several people remarked they thought I’d be taller.) Here are some other big takeaways from my time here so far.
I rang in my first month at GitLab in spectacular fashion, by meeting up with team members for our NYC [World Tour](https://about.gitlab.com/2016/09/28/world-tour-amplify-your-code/) stop. The only real surprise in meeting team members in person — after weeks of daily Hangouts — is height (hopefully by force of my personality, several people remarked they thought I’d be taller.) Here are some other big takeaways from my time here so far.
<!-- more -->
## MVC Applies Even to Marketers
## MVC applies even to marketers
The product team at GitLab lives and breathes the principle of [“Minimum Viable Change”](https://about.gitlab.com/handbook/product/#product-core-values) (MVC). This meant nothing to me in my day-to-day as a writer and marketer, until I joined GitLab and got an engineer as my team lead. We don’t apply the exact same language and principles to our content projects, but I believe that the spirit of MVC still informs our work. For example, our team lead Sean [explained](https://about.gitlab.com/2016/10/24/how-we-ship-so-quickly/) his simple test for reviewing our merge requests — he asks himself, “is this better than what was here before?” If the answer is ‘yes’, it gets approved. We now operate with the attitude that it’s better to jump in and do the work, than ask for approval, which not only makes us faster but increases our sense of agency over projects. We don’t need to establish consensus among innumerable team members before making a documentation or handbook update live on the site; if someone thinks of an improvement, they create a subsequent merge request, and the same rule applies. This feels like a radical way for a team of writers to work, but so far it’s all upside.
The product team at GitLab lives and breathes the principle of [“Minimum Viable Change”](https://about.gitlab.com/handbook/product/#product-core-values) (MVC). This meant nothing to me in my day-to-day as a writer and marketer, until I joined GitLab and got an engineer as my team lead. We don’t apply the exact same language and principles to our content projects, but I believe that the spirit of MVC still informs our work. For example, our team lead Sean [explained](https://about.gitlab.com/2016/10/24/how-we-ship-so-quickly/) his simple test for reviewing our merge requests — he asks himself, “is this better than what was here before?” If the answer is ‘yes’, it gets approved. We now operate with the attitude that it’s better to jump in and do the work, than ask for approval, which not only makes us faster but increases our sense of agency over projects. We don’t need to establish consensus among innumerable team members before making a documentation or handbook update live on the site; if someone thinks of an improvement, they create a subsequent merge request, and the same rule applies. This feels like a radical way for a team of writers to work, but so far it’s all upside.
## Feedback Flows Thick & Fast
## Feedback flows thick and fast
Because we work remotely and with relentless transparency, it occasionally happens that an issue thought to be uncontroversial develops an accordion-like comment section. We have team members in [34 countries](https://about.gitlab.com/team/), with a vast range of first languages, professional backgrounds, and experience levels, but the same intense drive to make GitLab better every day. I quickly learned to never read into perceived “tone” online, because nearly 100 percent of the time, questions are asked in earnest by team members and users who want to be sure they understand. By the time I experienced this, Sytse our CEO had armed me with a mantra for just such an occasion, and I repeat it to myself with abandon: *“If you’re getting feedback you’re doing it right...if you’re getting feedback you’re doing it right...if you’re getting feedback you’re doing it right.”* As a new employee, this also empowers me to chime in with my own questions, and I trust that my team members will always let me know how I’m doing.
## Intimidation is Your Only Enemy
## Intimidation is your only enemy
The first (open) secret I learned during my time here is that learning git basics is pretty easy. Checking out a new branch, tracking a file, committing changes, pulling from & pushing to the origin - these are the only functions I needed to master to do routine marketing tasks, and they became no problem after a day or two. Every non-technical person at GitLab could likely write a similar story about trepidation and triumph, because we have to successfully apply these commands to complete our [onboarding](https://about.gitlab.com/handbook/general-onboarding/) process. I haven’t since experienced the level of apprehension I felt when I opened up the terminal on my first day; the same applies to when I created my first issue and puzzled through the norms of our [workflow](https://docs.gitlab.com/ee/workflow/gitlab_flow.html). It’s also really true that gamifying anything is an awesome way to learn (my favorite right now is [ShortcutFoo](https://www.shortcutfoo.com/app/dojos/git).) This is not to disrespect the amazing work the developers on our team do; myself and another team member are starting to learn Ruby, and I’m sure I’ll have complicated feelings to report on that later.
The first (open) secret I learned during my time here is that learning Git basics is pretty easy. Checking out a new branch, tracking a file, committing changes, pulling from and pushing to the origin – these are the only functions I needed to master to do routine marketing tasks, and they became no problem after a day or two. Every non-technical person at GitLab could likely write a similar story about trepidation and triumph, because we have to successfully apply these commands to complete our [onboarding](https://about.gitlab.com/handbook/general-onboarding/) process. I haven’t since experienced the level of apprehension I felt when I opened up the terminal on my first day; the same applies to when I created my first issue and puzzled through the norms of our [workflow](https://docs.gitlab.com/ee/workflow/gitlab_flow.html). It’s also really true that gamifying anything is an awesome way to learn (my favorite right now is [ShortcutFoo](https://www.shortcutfoo.com/app/dojos/git).) This is not to disrespect the amazing work the developers on our team do; myself and another team member are starting to learn Ruby, and I’m sure I’ll have complicated feelings to report on that later.
Until then, git at us on [Twitter](https://twitter.com/gitlab?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor), check out our [job openings](https://about.gitlab.com/jobs/), or add to our [issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues).
---
title: "Publish Code Coverage Report with GitLab Pages"
title: "Publish code coverage report with GitLab Pages"
author: Grzegorz Bizon
author_twitter: GrzegorzBizon
categories: tutorial
categories: Tutorials
image_title: '/images/blogimages/publish-code-coverage-report-with-gitlab-pages/code-coverage-report-stats.png'
description: "Publish code coverage report with GitLab Pages"
twitter_image: '/images/tweets/publish-code-coverage.png'
......
......@@ -2,7 +2,7 @@
title: "Track your time in the same tool you do your work"
author: Regis Freyd
author_twitter: djaiss
categories: GitLab EE
categories: Tutorials
image_title: '/images/blogimages/track-your-time-in-the-same-tool-you-do-your-work.jpg'
description: "Announcing Time Tracking in GitLab"
---
......
......@@ -2,7 +2,7 @@
title: 'Working at GitLab - 30 days later'
author: Clement Ho
author_twitter: ClemMakesApps
categories: inside GitLab
categories: GitLab news
image_title: '/images/default-blog-image.png'
description: 'Working at GitLab - 30 days later'
---
......
......@@ -4,6 +4,7 @@ title: "GitLab 8.13.5, 8.12.9, and 8.11.11 Released"
date: 2016-11-09 10:30