GitLab

GitLab Patch Release: 10.6.4

2018-04-09T00:00:00+00:00

Today we are releasing version 10.6.4 for GitLab Community Edition and Enterprise Edition.</p>

This version resolves a number of regressions and bugs in this month's 10.6 release</a> and prior versions.</p>

GitLab Community Edition and Enterprise Edition</h2>
Available in GitLab Core, Starter, Premium, and Ultimate:</p>

Fix listing commit branch/tags that contain special characters</a></li>
Fix certificate misses intermediates validation error</a></li>
Reference parsing conflicting with auto-linking</a></li>
Fix code quality example documentation</a></li>
Remove jump to discussion button on issues page</a></li>
Fix promoting labels and milestones copy text</a></li>
Fix background pipeline stages migration</a></li>
Free open file descriptors and `libgit2</code> buffers in UpdatePagesService</a></li>`
`Fix wrong error handling in update page service</a></li>`
`Fix 404 in group boards when moving issue between lists</a></li>`
Override Prometheus service name to fix integration with GitLab.</a></li> </ul> Available in GitLab Starter, Premium, and Ultimate:</p> Fix Scoped Boards bug filtering by No Milestone</a></li> Add Gitlab::ExclusiveLease</code> to ObjectStorage#use_file</code></a></li> </ul> Available in GitLab Premium and Ultimate:</p> Resolve "Multiple clusters: incorrect cluster details injected - environment scope is ignored"</a></li> Geo: Log JID for sync related jobs</a></li> Geo: Fix inconsistent project registry queries</a></li> Geo: Fix project rename when wiki does not exist</a></li> </ul> Upgrade barometer</h2> This version does not include any new migrations, and should not require any downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code></a> file, which is only used for updates</a>.</p> Updating</h2> To update, check out our update page</a>.</p> GitLab subscriptions</h2> Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p> Alternativelly, sign up for GitLab.com</a> to use GitLab's own infrastructure.</p>



How contributing to open source can help you land your first job
2018-04-06T00:00:00+00:00
Contributing to open source can significantly boost your chances of getting a job. And even
though this is true for all developers, regardless of their level of experience, it's especially
important for entry-level ones.</p>

Let me make this perfectly clear: contributing to open source is the most effective job-seeking
 hack you can take advantage of right now</strong>.</p>

Even better, by contributing to open source you won't only improve your chances
of getting a job, but you will also give back to the community, meet amazing and talented
people, and feel incredibly accomplished when your first contribution gets accepted.</p>

At Microverse</a>, the company I founded, we train remote software developers from all around
 the world, and we ask them to contribute to open source, starting from their first day in the program.</p>

Here are six reasons why contributing to open source will help you too.</strong></p>

Reason 1: Work as part of a (distributed) team</h2>

When looking for a job, experience counts. However, experience limited to coding and the
language syntax is not enough. You need to know how to work as part of a team,
collaborating with others to build large and complex applications.</p>

How do you get that kind of collaborative and at-scale experience if you can't get a job first?</strong>
The answer is open source.</p>

Large, open source projects are almost always built by a large team. Sometimes the people in
those teams even work for large organizations (e.g. GitLab, React/Facebook, etc.). By
becoming a contributor you get the chance to work with those exceptional teams without
having to be hired by those companies</strong>.</p>

You will sharpen your written communication skills, understand how to pick and negotiate
things to work on, perfect your Git Flow/GitLab Flow</a>, and many other things that are as
valuable as understanding the language syntax.</p>

Reason 2: Work in a complex and large application</h2>

If you join a company, you will most likely work on an existing application. And, probably, it
will be a large and complex one. As a coding student you rarely have the chance to do that,
but when you join an open source project, that's exactly the scenario that you will face.</p>

You will first need to set up your local development environment</strong> following the contributing
guidelines provided by the project. You will then start by refactoring existing code</strong> to correct
typos and fix small bugs, the same way you would at a regular job! Finally, you will start
understanding how all the pieces</strong> of a large application fit together, how it was architected</strong>,
and where the code for each functionality</strong> lives.</p>

These are not things you could experience working on small learning projects, but you need
this kind of experience if you want to land a job.</p>

Reason 3: Get a lot of good feedback</h2>

Every time you pick an open source issue to work on, you will start by forking the project
and creating a feature branch. You will write tests and code until you are happy with your
solution, and then submit a merge request to the original code.</p>

However, this is just the first step in the process. One of the main developers at the project
will review your merge request and will tell you if it's ready to be merged. Most likely it won't.
 But that's fine, because she will also provide feedback about what you need to fix before
 your code can be merged</strong>.</p>

Can you imagine getting this kind of direct feedback from a seasoned developer at GitLab or
Facebook? Think about it… they really want your help, but they also need to keep the quality
of the code at a high level. They will help you, and you will end up learning a lot in the process.</p>

Reason 4: Build an online reputation</h2>

Getting experience working as part of a team and contributing to large and complex applications
is really important, but it won't help you land a job unless companies can find you and want to interview you.</p>

Contributing to open source will help you with that too. After quickly reading your resume,
employers will want to find you online, and they will want to see your code. GitLab and
GitHub profiles are the new resumes</strong>.</p>

If employers can see that you are an active member of large open source projects, that will
tell them something else that is very important: software is not just what you do for a living,
but it's also your passion and hence what you do in your free time.</p>

What do employers currently find when they search your name on Google? Open source will
make you look great!</p>

Reason 5: Network with the community</h2>

Open source projects often have large organizations behind them who are constantly hiring
new developers. Wouldn't it be great for those organizations if they could hire people who
love their product? What if their new hires knew the product so well already that they could
be productive contributors from the moment they join the company?</p>

Well, that's exactly the value you offer as an active member of an open source community.
You know the product, you know the code, and the people behind the project know you.
Chances are that you will eventually be offered to work for them</strong>. In fact, almost
a third of the first 40 engineers that GitLab hired were contributors to its codebase first.</p>

Reason 6: Stay motivated</h2>

Last, but not least, we all know the single and most important advice to be successful at anything
is perseverance. However, staying motivated and focused while learning to code and applying
for jobs is not easy. There are a lot of things to learn, a lot of different paths to take, and many
rejections on the path to landing your first job.</p>

Joining an open source project will give you the real-world encouragement and a community
 to support you throughout the journey.</p>

Are you convinced that contributing to open source is the best thing you can do right now to
help you on your way to landing your first job? I'm pretty sure you are. Go ahead and start now</a>!</p>

About the guest author</h3>

Ariel Camus</a> is the founder of Microverse</a>,
a company finding the world's untapped talent and training it to become remote software developers. Ariel was previously the co-founder and CEO
of TouristEye, a travel startup that he grew to a million users and sold to Lonely Planet in 2013.</p>

Cover photo by Maik Jonietz</a> on Unsplash</a></p>



GitLab + Google Cloud Platform = simplified, scalable deployment
2018-04-05T00:00:00+00:00
Get super-simple deployment for your app with GitLab and Google Cloud Platform (GCP): thanks to our integration with Google Kubernetes Engine (GKE), you can now get CI/CD and Kubernetes deployment set up with just a few clicks, and $500 credit</a> to get you started.</p>

Now everyone can get automatic code quality, security testing, and no-configuration deployment</h2>

With increasing adoption of cloud native</a> practices, the use of microservices and containers has become critical to modern software development. Kubernetes has emerged as the first choice for container orchestration, allowing apps to scale elastically from a couple of users to millions. It's been possible to deploy to Kubernetes from GitLab for quite a while, but the process of setting up and managing everything was manual and time intensive.</p>

Today, we’re happy to announce we've been collaborating with Google to make Kubernetes easy to set up on GitLab. Now, with our native Google Kubernetes Engine integration</a>, you can automatically spin up a cluster to deploy applications, with just a few clicks. Simply connect your Google account, enter a few details, and you're good to go! GitLab will create the clusters for you. The clusters are fully managed by Google and run on Google Cloud Platform's best-in-class infrastructure.</p>

This also means you can easily take advantage of GitLab Auto DevOps</a>. This feature does all the hard work for you, by automatically configuring CI/CD pipelines to build, test, and deploy your application. To make use of Auto DevOps, it used to be necessary to have an in-depth understanding of Kubernetes, and you had to manage your own clusters. Not any more!</p>

With the integration between GitLab and GKE, we’ve made it simple to set up a managed deployment environment on Google Cloud Platform and access our robust DevOps capabilities. That’s all the benefits of fully automated code quality, security testing, and deployment, with none of the headache of managing and updating your clusters (Google does that all for you!). More than half of developers and 78 percent of managers in our 2018 Global Developer Report</a> agreed that automating more of the software development lifecycle is a top priority for their organization. We hope that this integration gives you a head start, by offering automation out of the box with Kubernetes and Auto DevOps.</p>

What’s next for GitLab?</h2>

We’re not just excited about offering this integration for you to use, we’re excited to use it ourselves! We’re already in the process of migrating GitLab.com to Google Cloud Platform. For us, the primary reason to migrate was because it has the most mature Kubernetes platform. By moving, we get access to security functionality like default encrypted data at rest, a broad, ever-expanding list of localities served globally, and tight integration with our existing CDN for faster caching. Be on the lookout for more information on our migration as it progresses.</p>

Get seamless integration with GKE and $500 credit for your project</h2>

Every new Google Cloud Platform account receives $300 in credit upon signup</a>. In partnership with Google, GitLab is able to offer an additional $200 for both new and existing GCP accounts to get started with GitLab’s GKE integration. Here's a link to apply for your $200 credit</a>.</p>

Join Google and GitLab for a live demo</h2>

On April 26th, join Google’s William Denniss</a> and GitLab’s William Chia</a> for a walkthrough of the new GKE integration. You’ll learn how easy it is to set up a Kubernetes cluster, how to deploy your app using GitLab CI/CD, and how GKE enables you to deploy, update, and manage containerized applications at scale.</p>

Register today</a>!</p>



GitLab Security Release: 10.6.3, 10.5.7, and 10.4.7
2018-04-04T00:00:00+00:00
Today we are releasing versions 10.6.3, 10.5.7, and 10.4.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p>

These versions contain a number of important security fixes, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately.</p>



The vulnerability details will be made public on our issue tracker in approximately 30 days.</p>

Please read on for more information regarding this release.</p>

Confidential issue comments in Slack, Mattermost, and webhook integrations</h2>

Comments on confidential issues were previously sent to webhooks and integrations when notifications were configured to send notes or comments. This applied to custom webhooks, Slack, and Mattermost notifications.</p>

We've introduced a new option to control the sending of confidential notes as well as an option for specifying a different channel for Slack and Mattermost.</p>

Versions Affected</h3>

Affects GitLab CE/EE 8.6 and up.</p>

Remediation</h3>

We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Persistent XSS in milestones data-milestone-id</h2>

The milestone dropdown feature contained a persistent XSS issue that is now resolved in the latest release. This issue has been assigned CVE-2018-9244</a>.</p>

Thanks to fransrosen</a> for responsibly reporting this vulnerability to us.</p>

Versions Affected</h3>

Affects GitLab CE/EE 9.2 and up.</p>

Remediation</h3>

We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Persistent XSS in filename of merge request</h2>

Filenames in the changes tab contained a persistent XSS issue that is now resolved in the latest release. This issue has been assigned CVE-2018-9243</a>.</p>

Thanks to fransrosen</a> for responsibly reporting this vulnerability to us.</p>

Versions Affected</h3>

Affects GitLab CE/EE 8.4 and up.</p>

Remediation</h3>

We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Upgrade barometer</h2>

This release includes one database migration, which can be run without downtime. This migration adds a column to the
services</code> table. Another background migration is launched to populate this value.</p>

Updating</h2>

To update, check out our update page</a>.</p>



Polishing GitLab’s UI: A new color system
2018-03-29T00:00:00+00:00
We receive a lot of feedback from our users and the broader community. After
hearing that there is a perceived lack of consistency and quality in GitLab’s
UI, we decided to take a look at our color palette</em>.</p>



Aesthetic aspects like this are a fundamental part of the UI. If we don’t get
these right, everything else in the UI won’t feel, look, or behave correctly.
Like a house, these aesthetics are the foundation upon which everything else is
built.</p>

Our color palette had various issues, so we started by:</p>


  building a better palette</a> that aligned with our goals,</li>
  
and defining a color priority system</a> that helped us move forward.</li>
</ul>

Why start with colors?</h2>

There are many aesthetic aspects to a UI. So why tackle colors first? Well…</p>


  Colors are easy to change</strong>: it’s just a matter of changing simple values in
our variables.scss</code></a>
file.</li>
  
Color changes don’t affect layout</strong>: we weren’t reinventing the wheel, so
these changes wouldn’t influence the layout and spacing between elements like
typography can.</li>
</ul>

And, more subjectively, colors have a huge impact on the perception of a UI.
It’s said that 90 percent of information entering the brain is visual and color
is an attention-grabbing device.</p>

Issues with the previous color palette</h2>

</p>

It didn’t extend the brand colors</h3>

They weren’t in line with our brand colors</a>,
with the most obvious example being the pinkish-red normally associated with
negative aspects like errors or irreversible actions. We already have a red from
our brand, so why use a different one?</p>

There were too many similar colors</h3>

With so many colors, it wasn’t easy to tell them apart. They were so similar
that they no longer brought value to the table, just more guesswork and
maintenance.</p>

There wasn’t enough contrast</h3>

Many of our color combinations did not meet the contrast ratios defined in the
Web Content Accessibility Guidelines (WCAG)</a>.</p>

Note that some of these issues were also applicable to grayscale colors (also
called “achromatic”).</p>

Building a better palette</h2>

At GitLab, we’ve done a lot of things while standing on the shoulders of giants,
aligning with our company value of boring solutions</a>.
As such, one of our initial thoughts was to use an existing color palette,
something that could save us time and maybe serve as the basis for our work.</p>

We soon found Open color</a>, an open source
color scheme optimized for UI. It has 13 hues, each with 10 levels of
brightness, totaling 130 different colors. All of the values are there, it would
be easy for our Frontend team to get started by importing it as a dependency.
This was starting to look very promising and we were getting excited about this
quick start.</p>

However, the more we thought about our current needs and goals, the more we
realized that this approach wasn’t going to work for us. Existing color palettes
usually had too many colors for our needs and the ones we did need, would have
to be tweaked to align with our brand colors. All of the upsides of using an
existing color palette were now irrelevant.</p>

We went back to the drawing board, starting with defining the goals we wanted
our new color palette to achieve:</p>


  Align with and extend our brand colors</li>
  
Have only the hues that we need, the colors that have meaning in the UI</li>
  Be accessible by passing the WCAG</li>
</ul>

1. Extending the brand</h3>

The first step in creating our new color palette was inspired by “Add Colors To Your Palette With Color Mixing</a>,”
where we used ColorSchemer Studio</a>
to generate this color wheel from the three brand colors</a>
and the primary purple used on this site</a>:</p>

</p>

Initial colors were separated by even intervals of hue and manually tweaked. In
the image above, the matching brand colors are next to the wheel for reference.</p>

2. Cutting the rainbow</h3>

Then, we generated tints and shades for some of the hues in that color wheel:
green, blue, purple, red and orange.</p>

</p>

These were first obtained from the Material Design Palette Generator</a>
and then tweaked manually using Colorizer</a> and Eric
Meyer’s Color Blender</a>. The dark
orange colors are a good example of manual tweaking as they initially looked
very “muddy.”</p>

It’s important to consider the number of tints and shades that you need, as that
affects the flexibility when applying those colors. Our guiding principle here
was to provide clear and visible contrast between each step of the scale. If we
had steps that were too similar, the difference wouldn’t be noticeable, which
meant that there was no value in having those colors.</p>

We didn’t want all of the colors of the rainbow, just the ones that carry
meaning effectively</em>. We want to be able to communicate states and actions by
applying colors to elements in the UI (e.g. informational elements are
associated with blue). If you have too many similar colors in a UI, like green
and lime, you’re expecting too much not only of your users but also of your
team. On the one hand, most of your users won’t notice the difference between
colors when placed in a complex UI, so they also won’t pick up the different
meanings. On the other hand, your team will have more work learning, working
with, and maintaining unnecessary colors.</p>

Additionally, we shouldn’t rely on color alone to communicate something, so
that’s also another point for not having too many similar colors. This is
actually one of the success criteria of the WCAG about the use of color</a>:</p>


  Color is not used as the only visual means of conveying information,
indicating an action, prompting a response, or distinguishing a visual
element.</p>
</blockquote>

3. Colors for everyone</h3>

Using a small set of colors which allows for better memorization and recognition
is already a good step towards a more usable product, but it’s not enough.</p>

Evaluating, testing, and prioritizing accessibility problems</a>
is one of our main initiatives here at GitLab. Establishing contrast between
text and background is one of the key aspects of accessibility and, as we saw
before, our previous color palette didn’t meet the WCAG contrast
ratios</a>. So, as we were defining our new color palette, we
continually tested the colors using the WebAIM Color Contrast Checker</a>.</p>

Along the way, we hit a problem: combinations of white</em> text over green</em> or
orange</em> backgrounds did not pass WCAG level AA for small text</strong>. This was an
issue because we wanted to keep a uniform “vibrancy” and “pop” throughout all
colors. While the colors looked uniform to our human eye, the WCAG test didn’t
“see” them as we did. Would we be forced to “break” this visual consistency and
use darker shades for those colors? Not only that, but this would render them too
dark to carry meaning effectively</em>. In the following example, the “success”
meaning of green or the “warning” meaning of orange become less immediate as
their contrast increases.</p>

</p>

We found an interesting take on this at the Google Design</a>
website, which intentionally uses colors that at least pass AA for large
text</strong>:</p>


  Due to this site’s purpose being a source for visual design reference
and inspiration, we felt it was acceptable not to target a stronger color
contrast level. — Behind the Code — Google Slash Design Accessibility</a></p>
</blockquote>

Considering our audience and user base, should we be rigid and enforce AA
level for small text</strong>? As a first step towards better color contrasts, we
decided to set our minimum at AA for large text</strong>, even for small text</em>. For
grays, we tested and tweaked their contrast against light gray backgrounds</a>,
as that is a common color used to differentiate regions in the UI.</p>

</p>

Color priorities</h2>

So, after all this work, we introduced a wide range of color tints and shades
with the new color palette. The problem was that there was no guidance for using
them. Some color decisions are fairly quick and intuitive, but we wanted to
standardize and make the color selection process as objective as possible for
everyone, even developers. We want to give people the chance to make a decision
without imposing approval or reviews by the UX team. We want to be lean, efficient, and focus on results</a>.</p>

Some questions that we should be able to answer:</p>


  “I need to use one blue, which shade should I pick?”</li>
  “This UI component needs three contrasting shades of green. Can I pick
whichever I want?”</li>
</ul>

The Material Design colors</a>
have been a great source of inspiration for us. They follow the numeric naming
conventions used by the CSS font-weight</code> property</a>,
where a higher value equals a higher degree of blackness. So, we’ve named our
colors from the lightest (50</strong>) to the darkest (950</strong>).</p>

On top of this naming scheme, we’ve defined a system of color priorities. This
is similar to how different font weights are used to create contrasting
typography that communicates hierarchy.</p>

We can apply this same logic to colors, as seen in the image below, by tagging
them according to their priority: from 1</strong> to 4</strong>. If you need guidance, the
priorities can help you make better choices. When choosing how to apply color to
a UI component:</p>


  You start at priority 1</strong>, which is the medium weight 500</strong>. There’s only
one shade with priority 1 per color (the “default” shade).</li>
  For more shades of the same color, you could then choose from the next
priority level, number 2</strong>, which can either be 300</strong> (lighter) or 700</strong>
(darker). And so forth for even lighter or darker shades.</li>
</ul>

</p>

What’s next</h2>

Along the way, we’ve learned that mixing colors and defining color palettes</a>
is not only science, nor only art, it’s a subjective balance on the human mind.
Color harmony depends on many factors, like culture, age, social status, or even
the designer’s intent</a>.</p>

We’ll have to see how people use the 11 tints and shades and how they’re applied
in our Design System</a>. This is a constant evolution, and we’re always
iterating (as we should be).</p>

Next, we’re going to review our color meaning guidelines</a>
and be more active in their usage, not only in the product but also in our
Design System</a> and pattern library</a>.</p>

A new color palette and a color priority system are seemingly small steps
towards a better user experience throughout GitLab, but they do make a big
difference, for our users, our team, and every contributor. This is the first
initiative to polish our UI styles, next we’re implementing our new type scale</a>
– which will deserve a dedicated blog post.</p>

If you have any questions, feel free to post a comment below</a>,
tweet at us</a>, or join the discussion on the
following issues:</p>


  Change chromatic/full colors to a more harmonious palette</a></li>
  
Define color priorities</a></li>
  
Define a pure gray color scale</a></li>
</ul>



Cover image</a> by David Clode on Unsplash</a>.</p>




GitLab Patch Release: 10.6.2
2018-03-29T00:00:00+00:00
Today we are releasing version 10.6.2 for GitLab Community Edition and Enterprise Edition.</p>

This version resolves one regression in
this month's 10.6 release</a> and
prior versions.</p>



GitLab Community Edition and Enterprise Edition</h2>

Available in GitLab Core, Starter, Premium, and Ultimate:</p>


  Cloning a repository over HTTPS with LDAP credentials causes a HTTP 401 Access denied</a></li>
  
Don't capture trailing punctuation when autolinking</a>
    
      Note: This was released in GitLab Premium and Ultimate in 10.6.1</a> by mistake. We are now including it in GitLab Core.</li>
    </ul>
  </li>
</ul>

Upgrade barometer</h2>

This version does not include any new migrations, and should not require any
downtime.</p>

Please be aware that by default the Omnibus packages will stop, run migrations,
and start again, no matter how “big” or “small” the upgrade is. This behavior
can be changed by adding a /etc/gitlab/skip-auto-migrations</code></a> file,
which is only used for updates</a>.</p>

Updating</h2>

To update, check out our update page</a>.</p>

GitLab subscriptions</h2>

Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p>

Alternativelly, sign up for GitLab.com</a>
to use GitLab's own infrastructure.</p>



GitLab Patch Release: 10.6.1
2018-03-28T00:00:00+00:00
Today we are releasing version 10.6.1 for GitLab Community Edition and Enterprise Edition.</p>

This version resolves a number of regressions and bugs in
this month's 10.6 release</a> and
prior versions.</p>



GitLab Community Edition and Enterprise Edition</h2>

Available in GitLab Core, Starter, Premium, and Ultimate:</p>


  Prevent auto-retry AccessDenied</code> error from stopping transition to failed</a></li>
  
Fix 500 error when trying to resolve non-ASCII conflicts in the editor</a></li>
  
Add indexes for user activity queries</a></li>
  
Add documentation for Runner IP address</a></li>
  
Don't capture trailing punctuation when autolinking</a></li>
</ul>

Available in GitLab Premium and Ultimate:</p>


  Fix LDAP group sync permission override UI</a></li>
  
Hard failing a mirror no longer fails for a blocked user's personal project</a></li>
  
Define a chat responder for the Slack app</a></li>
  
Geo: Avoid rescheduling the same project again in a backfill condition</a></li>
  
Geo: Mark disabled wikis as fully synced.</a></li>
  
Geo: Fix excessive updates to file_registry when wiki is disabled.</a></li>
  
Geo: Recovery from temporary directory doesn't work if the namespace directory doesn't exist</a></li>
  
Geo: Resolve "undefined method 'log_transfer_error'"</a></li>
  
Geo: Log Geo Prometheus metrics from the primary</a></li>
</ul>

Omnibus GitLab</h2>

  Pages: if logformat</code> set to json</code>, do not append timestamps with svlogd</code>.</a></li>
  
Downgrade jemalloc</code> to 4.2.1 to avoid segfaults in Ruby</a></li>
</ul>

Upgrade barometer</h2>

This version does not include any new migrations, and should not require any
downtime.</p>

Please be aware that by default the Omnibus packages will stop, run migrations,
and start again, no matter how “big” or “small” the upgrade is. This behavior
can be changed by adding a /etc/gitlab/skip-auto-migrations</code></a> file,
which is only used for updates</a>.</p>

Updating</h2>

To update, check out our update page</a>.</p>

GitLab subscriptions</h2>

Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p>

Alternativelly, sign up for GitLab.com</a>
to use GitLab's own infrastructure.</p>



High-efficiency innovation: 3 lessons to learn from GitLab's culture of rapid execution
2018-03-27T00:00:00+00:00
All companies have different ways of creating new products and services. Despite that, there are a few patterns that show up consistently. At Jump</a>, we like to call those patterns the different "cultures" of innovation. One such pattern has to do with execution. Great executors (like GE and FedEx) are masters of sharp focus and efficient machine-making.</p>

Many of the Fortune 500 companies that we work with do their best innovation this way. They've built infrastructure that excels at launching products globally, coordinating thousands of employees and operating at massive scale. These companies often ask us what they can learn from what's going on in Silicon Valley. There's much to learn, of course, from the startups and entrepreneurial ecosystem here.</p>

The important question is not "How do they do things in Silicon Valley?" Instead, it's "What can I learn that would work well in my organization?" It's always exciting to come across a startup that's doing what these big companies do best – execute at scale – and doing it in a completely different way.</p>

GitLab is one such company. They're an open source software company powering many of the world's largest corporations. They've developed a surprising – and strong – culture of innovation. They're a remote-only company. There's no physical headquarters or office space for their 200+ employees located worldwide. They proudly admit that they value "boring solutions." Their entire business strategy is available</a> for the public and their competitors to see. They're respected for their product</a>, their culture</a>, and their results</a>.</p>

Many companies pride themselves on their ability to iterate quickly and answer yes/no decisions rapidly. Even they might be surprised at the scope and scale of GitLab's efficiency. GitLab drives high-efficiency innovation through a culture of rapid execution. They weave speed directly into the fabric of who they are and what they do. Do you want to learn how they do it? I recently shadowed GitLab's CEO, Sid Sijbrandij</a>, and his team for a day.</p>

Here's how they make it happen.</p>

When the answer is clear, build for speed. Speed wins.</h2>

Why build a culture of rapid execution?</em></p>

With such a unique team culture and set of business practices, the first thing I wanted to learn from Sid was why GitLab operates the way it does. What became clear was that it's all very intentional.</p>

A few key beliefs are central to the decisions they've made:</p>

Belief 1: The solution required to win is already super clear to everyone.</h3>

They're operating in a market called DevOps, which is about creating platforms and tools for software developers to use in their work. It's a market where both the unmet customer need and the ideal solution are clear to everyone.</p>

They were newer to the game than some brand name and legacy competitors, so they chose to prioritize speed over invention to get to the finish line first.</p>

Belief 2: If you don't do anything new, you can do things faster, bigger and better.</h3>

The folks at GitLab believe that it's better to be boring. They value "boring solutions." It's not because boring is better in and of itself. It's because boring is efficient. It's faster. And faster can become bigger. And when you add in collaboration with a global open source community, bigger can become better.</p>

If there's a market standard, they don't try to create something different. They get on board. As Sid says, "It's about convention over conviction. We make sure everyone [in the open source community] is enticed to participate. If the rest of the world is doing it in some way, we should be doing it in that way."</p>

Belief 3: It's OK not to make everyone happy.</h3>

It's hard for most companies – and most people – to change to what made them successful in the first place. For GitLab, making those kinds of changes is critical to achieving the growth they seek. So on a daily basis, they choose to act quickly, make mistakes quickly, and learn from those mistakes quickly.</p>

That can lead to decisions – big and small – that might not make everyone happy.</p>

When they launch a completely new version of GitLab (they're on version 10.6</a> right now), they always add some things that will frustrate some existing customers, and they often take away things that other customers love.</p>

"There's way more people not using GitLab than that are. So we should always optimize for those future customers, not your current ones. That's why companies slow down. They start listening. Engineers want to fix the current bugs. Sales wants to keep the old deck that works for them. You start listening to your customers and what they need you to maintain or fix. The natural motion of any company is to slow down. So as CEO you need to get the company beyond that."</p>

So what does high-efficiency innovation and rapid execution look like at GitLab?</p>

Here are a few examples of the pace at which they operate:</p>


  They release a new version of GitLab every single month.</li>
  
Everything is in draft and subject to change. It's always under construction.</li>
  They don't repeat themselves. GitLab documents how it does things in a handbook</a>. It's 1,000 pages long. If it's in the handbook, don't repeat it.</li>
  
Every conference call starts on time. No wasted minutes. Sid checks 15-30 action items off the list in each of his 25-minute 1-on-1 meetings.</li>
  
They trust their team to multi-task appropriately. If you want to check email during a meeting, it's probably more important than the meeting is to you.</li>
</ol>

There's a final, often-overlooked value of speed: it's exciting. Workplaces that manage to pair speed with evident progress allow their teams to feel accomplished, motivated, and on the edge of their seats. It's an easy hack for maintaining employee engagement.</p>

Don't sacrifice long-term vision for short-term speed. Be accountable for both.</h2>

What is GitLab is rapidly executing on?</em></p>

Many companies who prize execution do a great job at sustaining and growing their existing products. They're often quite efficient – though they could learn something from the speed at which GitLab operates. But they're more likely to struggle with thinking far out into the future.</p>

To paraphrase Stephen Covey, there's a big difference between efficiency and effectiveness. A jet flying 1,000 miles per hour is efficient; a jet flying 1,000 miles per hour in the right direction is effective.</p>

So if GitLab as an organization is a jet built for speed – where is it going?</h4>

Sid wants GitLab to help multiply the potential for progress that humanity can drive into the world. "Our mission is 'Everyone can contribute.' That's a long-term vision. That's 10 years. It means changing all of our culture to read-write. Think Wikipedia. They allow everyone to contribute. Imagine if we can do that. You release a lot of progress. You 10x the progress. [Multipliers like that are] thrown around so easily in Silicon Valley that you have to be cautious. But if you look at 100,000 companies using GitLab, and really being able to get their out software faster. I'm willing to stand behind that."</p>

That means that not only is GitLab thinking about efficiency and effectiveness, but it's also thinking about impact. Impact on the scale of human progress and global culture.</p>

That's pretty big and pretty far out. So how do they make sure the pilots keep looking way out there on the horizon while flying at supersonic speeds and maneuvring around today's obstacles?</p>

First, you set the mission and vision. Everything starts with that mission in mind. Everyone knows it, and Sid talks about it every chance he gets</a>.</p>

Next, you draw that vision back into today's actions with cascading plans. Create a three-to-five-year strategy about how to get there. Craft a yearly plan and product vision</a> – one that's concrete enough that you could show screenshots of what it will look like a year from now. Define quarterly goals (GitLab's OKRs</a> are public), monthly targets, and smaller sprints to get you there.</p>

Third, you make each of these regular goals highly ambitious, close-in, unambiguous, and concrete. "Setting high goals pushes people beyond their comfort zone," Sid told me. At Y Combinator, he says they taught GitLab that "20 percent is the new 10 percent." That's 20 percent growth, every single week. It's a high number, and it forces them to make completely different types of decisions.</p>

Finally, because the short-term goals are incredibly high, you focus on iteration. Iteration</a> is one of GitLab's core values. They define it clearly: "We do the smallest possible thing and get it out as quickly as possible." And they don't just ask developers and designers to work this way. "We put the whole company on that diet. It made sense for the product. But for marketing, sales, etc., we've gotten them there. If you say 'Grow XYZ in the next two weeks,' you do completely different things. I don't know why that is, but you do."</p>

Encode culture and values to keep the company moving faster.</h3>

How does GitLab do what they do?</em></p>

It was GitLab's strong culture and values orientation that first drew me to them as an organization. I'm often on the lookout for how leaders drive values through their organizations – from Jon Stewart on "The Daily Show" to the frontline teams at Starbucks and Zappos.</p>

The best values-oriented organizations draw explicit links between their values, their competitive advantages, and their daily activities.</p>

Here's where GitLab stands out.</p>

In just one day of shadowing GitLab's staff, the team talked about values during a product meeting, two interviews with prospective employees, an analyst call and a 1-on-1 with a teammate. The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).</p>


  The whole team is drawing causal links between what it does (its business activities) and how it does them (the values they live by).</p>
</blockquote>

So how does that work? It requires leaders choosing to identify not just the values that matter, but also how to organize around them. Sid told us "I didn't do a very good job coding GitLab [when he and his co-founders all started back in 2011]. But I think I'm doing a good job coding GitLab the company."</p>

As a remote-only company, "coding the company" means (1) writing things down, (2) referencing back to what's been written and (3) reinforcing it through rewards.</p>

All of this "GitLab the company" code is captured in its handbook. The handbook is referenced in almost every conversation. The handbook consists of over 1,000 pages of text. It's a tool that GitLab uses to capture and detail out decisions that have already been made about all of its core business practices – marketing, sales, product, team operations, finance, and more. It's a constant practice for Sid and the team to reference the handbook in meetings, and to send people to look there first before continuing the conversation.</p>

The values take a prime place in the handbook. There, values are defined, not just described. Words can mean different things in different contexts – and these values indicate a particular thing at GitLab. The definitions are brought to life with 5-15 concrete actions that employees often take for each of the six values. As Sid says, "The culture got stronger because it is written down. And because it improves and is edited over time." And then they're reinforced every day through hiring, coaching, performance reviews and casual conversations.</p>

It's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work. What GitLab has unlocked with its values orientation is not just good and meaningful work. It has also opened the most important competitive advantage in its business model – speed.</p>


  It's rare that companies think about linking their values with their competitive advantage. It's rarer still that a company brings its values to life through the day-to-day work.</p>
</blockquote>

It says it right there in the 'Why have values' section of the handbook: "Values are a framework for distributed decision-making; they allow you to determine what to do without asking your manager." By encoding values deep into everyday activities of the company, everyone on GitLab's team can make decisions faster.</p>

In DevOps, winning is about getting there first. GitLab coded values right into its organizational design to make sure it could always be the fastest to market.</p>

Parting thoughts: Will high-efficiency innovation work for you?</h2>

Although they weren't thinking about large corporations, the oracles of Delphi were right. The most important maxim is to "know thyself." The GitLab prescription isn't right for every company. What's most important is to build a culture of innovation that reflects your strengths and your values.</p>

GitLab is a company of executors, of coders and of people who aren't afraid to work out in the open and make mistakes. They see clear problems. Then they attack. GitLab built a method of innovation that works well for them, but it's not a one-size-fits-all approach. It won't work for everyone, but it might work for you.</p>

Here are the questions you should ask:</h4>


  Is the problem you're facing clear to you and your competitors?</li>
  
Would the people on your team prioritize efficiency over novelty if it'll get you there first?</li>
  Do you know how to make trade-offs between what works for your existing customers and what might work better for future customers?</li>
</ol>

If you answered yes, pay close attention to what GitLab is doing. Their unrelentingly quick iterative process might be just what the doctor ordered to scale your innovation.</p>

If not, the GitLab system isn't the right fit for you. You'll want to organize your innovation in a different way.</p>

As one example, we built Jump to handle an entirely different type of highly ambiguous problems</a>. So it makes sense that some of Jump's values (Passion, Curiosity, Enthusiasm, Intention, Acuity, Initiative and Play) look very much the opposite of GitLab's values (Collaboration, Results, Efficiency, Diversity, Iteration and Transparency).</p>

Jump and GitLab are both deeply values-oriented companies with rich and collaborative cultures focused on innovation. And yet we value different things, have different org structures, hire different types of people and work on very different types of problems.</p>

So what if you're like me and your company's approach or market situation is quite different than GitLab's? Take this as an opportunity to learn from seeing your mirror image.</p>

First, test parts of their approach. See what works for you and your team. Then, consider the polar opposites. Find the points where you value distinctly different things, and ask why. Learn why their method works for them, and why it wouldn't work for you. Then flip the script – what's an approach to innovation that GitLab would never do that would be a difference maker for you if you did it?</p>

Either way, take note of what GitLab is doing and how they're doing it. It's amazing, effective, growing like crazy and a great place to work. And ask yourself – should my team be innovating like that?</p>

About the guest author</h2>

Jay Newman is Director of Strategy at Jump Associates, a leading strategy and innovation firm. Learn more at jumpassociates.com</a> and connect directly with Jay on LinkedIn</a>.</p>

Photo by Karsten Würth</a> on Unsplash</a></p>



Summary of limited GitLab credentials exposed in an internal logging system
2018-03-26T00:00:00+00:00
Summary</h2>

From February 19, 2018 to March 19, 2018, some GitLab.com personal access tokens and third-party credentials were inadvertently exposed publicly via an unprotected logging dashboard. The affected users represent approximately 0.5 percent of our GitLab.com user base. While the dashboard was originally protected from unauthorized access, a recent configuration change made this internal system publically accessible.</p>



Upon further review, we discovered a limited number of tokens and third-party credentials were incorrectly stored in this system. We’ve already mitigated all issues that led to this exposure. Our audit logs only cover a portion of the time the dashboard was exposed, but only one login resulted in a deep query that resulted in a personal access token being exposed. This activity was positively linked to the user that immediately disclosed the issue to us. As such, we have no evidence that any of the affected credentials were used in a malicious manner.</p>

We have notified the affected users via email to update their credentials and are implementing a series of security enhancements to prevent such issues from happening again. Note that self-hosted GitLab customers are entirely unaffected, as their credentials are stored in their own database and this logging functionality is off by default in self-hosted instances.</p>

Credentials written to logs</h2>

On February 28, 2018 we discovered internally that GitLab’s Gitaly service was, in certain circumstances, mishandling the sanitization of private third-party credentials for push-mirrored and imported repositories. These unscrubbed credentials were then sent to our logging system (ELK) and our exception management system (Sentry).</p>

During the investigation, we realized that some other credentials were also leaking into our HAProxy load balancers logs. These were personal access tokens used for GitLab API access when passed via query parameters in an HTTP request. Additionally, credentials that allow access to some third-party Git repositories were leaked into the logs. These have been fixed in the following:</p>


  Sanitize URLs before logging them</a></li>
  
Sanitize private_token field in HA Proxy logs</a></li>
  
Reconfigure OAuth mechanism, removing ‘*’ email domain access</a></li>
</ul>

Exposure of logs</h2>

On March 19, 2018, GitLab user Ryan Hefner discovered an authentication misconfiguration on our internal logging dashboard. A configuration change was made incorrectly on February 19, 2018, which resulted in potential public read-only access to the centralized, internal logging server for GitLab. This misconfiguration was resolved immediately upon notification.</p>

GitLab uses an OAuth proxy service to authenticate all access to our internal logging infrastructure. Previously, this proxy service had been correctly configured to only allow access to authorized GitLab engineers. However, in the course of migrating this proxy service to our new cloud infrastructure, we inadvertently introduced a misconfiguration that allowed anyone with a valid Google account read-only access to our internal logging server, instead of the intended behavior of allowing only authorized GitLab engineering accounts.</p>

Impact</h2>

There is no evidence of user credential abuse. However, the audit logs for the dashboard only cover seven of the 30 days in question. The only audit log activity accessing sensitive information was from the user that immediately reported the issue to GitLab. We found no evidence of abuse against the API itself. Regardless, we are taking every precaution, and strongly recommending all affected Gitlab.com users rotate their personal access tokens. Affected users have received further instructions via email notifications, accordingly.</p>

Although there is no evidence to suggest it happened, in the worst case an attacker could have gained access and obtained personal access tokens used in API calls between February 19, 2018 and March 19, 2018.</p>

Mitigations</h2>

Since the discovery, we have worked to investigate and mitigate all of these related security issues. We are continually improving our security processes and logging mechanisms to ensure that similar incidents will not occur again. These improvements are:</p>


  Increase logging retention periods</li>
  
Fine-grain access controls to all logging infrastructure</li>
  
Regular, periodic audits of all our logs</li>
  
Adding mandatory review of any security-relevant changes by a GitLab Application Security engineer</li>
  
Document this process in our runbooks to ensure repeatability</li>
  An additional measure we won't disclose because informing adversaries could render it less effective</li>
</ul>

If your project or account is affected by this security issue, you will receive an email notification listing affected projects with steps to rotate your personal access tokens. To proactively change them visit this page: https://gitlab.com/profile/personal_access_tokens</a>.</p>

We apologize for the impact this issue has caused our users. GitLab takes your information and your data extremely seriously. We have quadrupled the size of our internal security team in the last six months and have further plans to grow. We will learn from this incident and use it to improve upon our security even further.</p>

In keeping with our company value of transparency we also believe in communicating about such incidents clearly and promptly. If you have any questions, please contact security@gitlab.com</a>.</p>



GitLab’s Global Compensation Calculator: The next iteration
2018-03-23T00:00:00+00:00
We know many of you have thoughts about our Compensation Calculator</a>! We see your comments on Hacker News; we are listening and continually working on improving it. In line with our value of iteration</a>, we have made additional changes to our Compensation Calculator. In January 2018, we released a new version to align the calculator closer to market rates, and adjust all current team members’ pay to be in line with the outputs of the iterated version. Here’s how it works.</p>

</p>

What is our new formula?</h2>

Your compensation = SF benchmark</a> x (0.7 x (max (0.2, Rent Index</a> + Hot Market Adjustment</a>) / 1.26) + 0.30) x Level Factor</a> x Experience Factor</a> x Contract Type Factor</a> x Country Factor</a></p>

SF benchmark</h3>

This is the employee salary at the 50th percentile for the role in San Francisco (SF), which we determine using various sources of market data including Comptryx</a>.</p>

Rent Index</h3>

This is taken from Numbeo</a>, which expresses the ratio of cost of rent in many metro areas. Since we are using San Francisco benchmarks, we divide by 1.26 to normalize the rent index to San Francisco. A minimum Rent Index of 0.2 is applied so no one is paid less than 41 percent of San Francisco's market.</p>

We multiply the Rent Index by 0.7 and then add 0.3, so the sum would equal 1 (i.e. we pay San Francisco rates in San Francisco).</p>

Hot Market Adjustment</h3>

This is an adjustment to any US-based metro area where the geographical area Rent Index is less than the Hot Market Adjustment plus the Numbeo Rent Index, to recognize that "hot markets" tend to have a Rent Index that is trailing (i.e. lower than) what one would expect based on compensation rates in the area.</p>

Level Factor</h3>

This is currently defined as junior (0.8), intermediate (1.0), senior (1.2), staff (1.4), or manager (1.4), and will be defined as II (.8), III (1.0), Senior (1.2), Staff (1.4), or manager (1.4).</p>

Experience Factor</h3>

This falls between 0.8 - 1.2 based on our Experience Factor Guidelines</a>:</p>


  0.8: New to the position requirements</li>
  
0.9: Learning the position requirements</li>
  
1: Comfortable with the requirements</li>
  
1.1: Thriving with the requirements</li>
  1.2: Expert in the requirements</li>
</ul>

Country Factor</h3>

This is a ratio of the calculator to market data. We determine this ratio</a> by looking at how our calculator aligns to market in the region. If the calculator comes in higher than market, a factor lower than 1 is applied. If the calculator is in line with market, the factor stays at 1.</p>

Contract Type Factor</h3>

This distinguishes between employee (1) or contractor (1.17). A contractor may carry the costs of their own health insurance, social security taxes, etc, leading to a 17 percent higher compensation for the contractor to account for the extra expenses to these GitLabbers.</p>

The calculator can be found on each position description. For example, take a look at our Compensation Calculator for Developers</a>.</p>

Using San Francisco Market Data</h2>

The first step in this iteration was to gather market data and incorporate it as the benchmarks for each role. After obtaining a global data set to map to our positions, we needed to decide if New York was still the right city to pivot the benchmarks around. After some analysis, we determined that San Francisco was a better source of data, so we adjusted the formula. We also analyzed and adjusted the parameters around rent index to ensure in San Francisco you make San Francisco's benchmark.</p>

Instituting a Minimum Rent Index</h2>

Earlier in 2017, we instituted a Geographical Areas iteration to the compensation calculator to ensure that there are not large pay differences in regions that have a similar job market. We looked at the rent indexes by region</a>, determined any outliers on the high or low end of the rent index, and set the regional rent index at the highest of the remaining data set. With the January iteration of the compensation calculator, we also set a Minimum Rent Index so no one would be paid less than 41 percent of San Francisco’s market.</p>

Adjusting our team’s pay</h2>

With this iteration of the compensation calculator, we wanted to align our team’s salaries according to market. We first looked at how experienced the team member is in their role by having the manager conduct an Experience Factor Review</a>. This review verified we are paying our team in line with their experience, and not determining their experience to fit compensation. This review generates an output which is applied in the compensation calculator, but is also a great way to start the conversation around growth within each role. Managers and direct reports were able to review the experience factors and have constructive conversations around experience. Once we had all of the calculator inputs, including the up-to-date Experience Factor, our People Ops team reviewed all salaries to match the new compensation calculator. At the same time as the calculator was released, the increases to pay were also communicated.</p>

What’s next, and why we think the compensation calculator is a powerful tool</h2>

We’ll continue to add more countries to our Country Factors list, review adding an additional factor for specialization within Development roles, review how the levels overlap when it comes to promotions, and review the Rent Indexes for countries with many data points (like the United States and United Kingdom).</p>

We want to continue to make the calculator as reflective of market in as many locations as we can, given possible data constraints. This will go some way towards eliminating pay inequality among underrepresented groups, promote salary transparency on what each team member and candidate’s market value is, and save valuable recruiting time.</p>

We also want to hear from you on where this calculator can continue to improve! Please let us know what you think in the comments.</p>

Cover image</a> by Antoine Dautry on Unsplash</a></p>



GitLab 10.6 released with CI/CD for GitHub and deeper Kubernetes integration
2018-03-22T00:00:00+00:00
Continuous integration, continuous delivery, and continuous deployment form the backbone of modern DevOps. GitLab features built-in CI/CD that has received a lot of positive attention from developers</a>, enterprises</a>, and analysts</a> alike.</p>

But one thing that was missing was that you couldn't use GitLab CI/CD with GitHub.  Well today, we’ve fixed that.</p>



Introducing GitLab CI/CD for GitHub</h2>

While GitLab works best when you use it all end-to-end</a>, we also seek to play well with others</a>. In this spirit, we’ve added CI/CD integration with GitHub</a>, and more generally the ability
to integrate CI/CD with other external repos</a> like BitBucket as well. We see four primary audiences that this functionality is designed for. </p>

Open source projects</h3>

If you have a public, open source project on GitHub you can now take advantage of free CI/CD on GitLab.com. As part of our commitment to open source, we offer all public projects our highest tier features (Gold) for free. While other CI/CD vendors limit you to running a handful of concurrent jobs, GitLab.com</a> gives open source projects hundreds of concurrent jobs with 50,000 free CI pipeline minutes per month.</p>

Large Enterprises</h3>

When we talk to our largest customers they tell us that they often have many teams using many different tools. They want to standardize on GitLab for CI/CD but code is stored in GitLab, GitHub, and other repos. This feature now allows enterprises to use common CI/CD pipelines across all of their different repos. This is a key audience and why we’ve made CI/CD for GitHub part of our self-hosted Premium plan.</p>

Anyone using GitHub.com</h3>

While GitLab is designed to use SCM & CI/CD in the same application, we understand the appeal of using GitLab CI/CD with GitHub version control. So, for the next year we are making the GitLab CI/CD for GitHub feature a part of our GitLab.com</a> Free tier. That means anyone using GitHub from personal projects and startups to SMBs can use GitLab CI/CD for free. Starting at 2000 free CI pipeline minutes per month, folks can also add their own Runners</a> or upgrade plans to get more.</p>

Gemnasium customers</h3>

We recently acquired Gemnasium</a>. While we are super excited about having such a great team join our ranks, we also want to take care of folks that were using Gemnasium and provide them a migration path. We’ve already shipped Gemnasium features</a> as part of our built-in security scanning. Now, GitLab CI/CD for GitHub allows Gemnasium customers that were using GitHub + Gemnasium to begin using GitLab CI/CD for their security needs without needing to migrate their code.</p>

Kubernetes on GitLab keeps getting better</h2>

GitLab continues to invest in integrating with containerization. In 10.4 we release Kubernetes Cluster Integration and GKE Integration to General Availability</a>. With this release, we make it even easier for users to use Kubernetes with GitLab. You can now deploy a GitLab Runner to your connected Kubernetes cluster with a single click</a>. You can also monitor your connected Kubernetes cluster from within GitLab</a> itself. And you can now also see the IP address of an Ingress controller connected to your Kubernetes cluster</a>, again, right inside GitLab!</p>

Remediation</h3>
We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Remediation</h3>
We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Upgrade barometer</h2>
This release includes one database migration, which can be run without downtime. This migration adds a column to the `services</code> table. Another background migration is launched to populate this value.</p>`
`Updating</h2>To update, check out our update page</a>.</p>`

`Updating</h2>To update, check out our update page</a>.</p>`

Issues with the previous color palette</h2>
</p>

It didn’t extend the brand colors</h3>
They weren’t in line with our brand colors</a>, with the most obvious example being the pinkish-red normally associated with negative aspects like errors or irreversible actions. We already have a red from our brand, so why use a different one?</p>

There wasn’t enough contrast</h3>
Many of our color combinations did not meet the contrast ratios defined in the Web Content Accessibility Guidelines (WCAG)</a>.</p>
Note that some of these issues were also applicable to grayscale colors (also called “achromatic”).</p>

`Updating</h2> To update, check out our update page</a>.</p> GitLab subscriptions</h2> Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p> Alternativelly, sign up for GitLab.com</a> to use GitLab's own infrastructure.</p>`

GitLab subscriptions</h2>
Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p>
Alternativelly, sign up for GitLab.com</a> to use GitLab's own infrastructure.</p>

`Updating</h2> To update, check out our update page</a>.</p> GitLab subscriptions</h2> Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p> Alternativelly, sign up for GitLab.com</a> to use GitLab's own infrastructure.</p>`

GitLab subscriptions</h2>
Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p>
Alternativelly, sign up for GitLab.com</a> to use GitLab's own infrastructure.</p>

About the guest author</h2>
Jay Newman is Director of Strategy at Jump Associates, a leading strategy and innovation firm. Learn more at jumpassociates.com</a> and connect directly with Jay on LinkedIn</a>.</p>
Photo by Karsten Würth</a> on Unsplash</a></p>

What is our new formula?</h2>
Your compensation = SF benchmark</a> x (0.7 x (max (0.2, Rent Index</a> + Hot Market Adjustment</a>) / 1.26) + 0.30) x Level Factor</a> x Experience Factor</a> x Contract Type Factor</a> x Country Factor</a></p>

SF benchmark</h3>
This is the employee salary at the 50th percentile for the role in San Francisco (SF), which we determine using various sources of market data including Comptryx</a>.</p>

Level Factor</h3>
This is currently defined as junior (0.8), intermediate (1.0), senior (1.2), staff (1.4), or manager (1.4), and will be defined as II (.8), III (1.0), Senior (1.2), Staff (1.4), or manager (1.4).</p>

GitLab

GitLab Patch Release: 10.6.4

`Updating</h2> To update, check out our update page</a>.</p> GitLab subscriptions</h2> Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p> Alternativelly, sign up for GitLab.com</a> to use GitLab's own infrastructure.</p>`

GitLab subscriptions</h2>
Access to GitLab Starter, Premium, and Ultimate features is granted by a paid subscription</a>.</p>
Alternativelly, sign up for GitLab.com</a> to use GitLab's own infrastructure.</p>

How contributing to open source can help you land your first job

GitLab + Google Cloud Platform = simplified, scalable deployment

GitLab Security Release: 10.6.3, 10.5.7, and 10.4.7

Versions Affected</h3>
Affects GitLab CE/EE 8.6 and up.</p>

Remediation</h3>
We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Polishing GitLab’s UI: A new color system

GitLab Patch Release: 10.6.2

GitLab Patch Release: 10.6.1

High-efficiency innovation: 3 lessons to learn from GitLab's culture of rapid execution

Summary of limited GitLab credentials exposed in an internal logging system

GitLab’s Global Compensation Calculator: The next iteration

GitLab 10.6 released with CI/CD for GitHub and deeper Kubernetes integration

GitLab

GitLab Patch Release: 10.6.4

Upgrade barometer</h2> This version does not include any new migrations, and should not require any downtime.</p>

How contributing to open source can help you land your first job

GitLab + Google Cloud Platform = simplified, scalable deployment

GitLab Security Release: 10.6.3, 10.5.7, and 10.4.7

Versions Affected</h3> Affects GitLab CE/EE 8.6 and up.</p>

Remediation</h3> We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Remediation</h3> We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Remediation</h3> We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Polishing GitLab’s UI: A new color system

Why start with colors?</h2> There are many aesthetic aspects to a UI. So why tackle colors first? Well…</p>

Issues with the previous color palette</h2> </p>

3. Colors for everyone</h3> Using a small set of colors which allows for better memorization and recognition is already a good step towards a more usable product, but it’s not enough.</p>

GitLab Patch Release: 10.6.2

Upgrade barometer</h2> This version does not include any new migrations, and should not require any downtime.</p>

GitLab Patch Release: 10.6.1

Upgrade barometer</h2> This version does not include any new migrations, and should not require any downtime.</p>

High-efficiency innovation: 3 lessons to learn from GitLab's culture of rapid execution

Here are the questions you should ask:</h4> Is the problem you're facing clear to you and your competitors?</li> Would the people on your team prioritize efficiency over novelty if it'll get you there first?</li>

Summary of limited GitLab credentials exposed in an internal logging system

Mitigations</h2> Since the discovery, we have worked to investigate and mitigate all of these related security issues. We are continually improving our security processes and logging mechanisms to ensure that similar incidents will not occur again. These improvements are:</p>

GitLab’s Global Compensation Calculator: The next iteration

Level Factor</h3> This is currently defined as junior (0.8), intermediate (1.0), senior (1.2), staff (1.4), or manager (1.4), and will be defined as II (.8), III (1.0), Senior (1.2), Staff (1.4), or manager (1.4).</p>

GitLab 10.6 released with CI/CD for GitHub and deeper Kubernetes integration

Versions Affected</h3>
Affects GitLab CE/EE 8.6 and up.</p>

Remediation</h3>
We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Remediation</h3>
We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Remediation</h3>
We strongly recommend</strong> that all installations running an affected version above to be upgraded to the latest version as soon as possible.</p>

Issues with the previous color palette</h2>
</p>

Level Factor</h3>
This is currently defined as junior (0.8), intermediate (1.0), senior (1.2), staff (1.4), or manager (1.4), and will be defined as II (.8), III (1.0), Senior (1.2), Staff (1.4), or manager (1.4).</p>