GitLab

GitLab 8.12.3, 8.11.8, 8.10.11 and 8.9.11 released

2016-09-29T00:00:00+00:00
Today we are releasing versions 8.12.3, 8.11.8, 8.10.11 and 8.9.11 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p>
Version 8.12.3 contains some security fixes for GitLab, plus fixes for minor regressions. Version 8.11.8, 8.10.11, and 8.9.11 only contain the security fixes.</p>
If you're wondering what happened to 8.12.2, good eye! That version was accidentally packaged without including some fixes for the CE version.</p>
Please read on for more details.</p>


GitLab World Tour: Amplify Your Code
2016-09-28T00:00:00+00:00
</i>  
GitLab World Tour - London, Oct 19th - Register here</a>!
  </i></p>

Even the sharpest teams face minor setbacks when their code falls flat, or their team is just not in tune. 
O-boe-y, nobody wants that. Luckily, GitLab is here to pitch you an idea to help you boost your act.</p>

We're kicking off the GitLab World Tour to help harmonize your development process because code is our forte.
At this free event, we will explore how teams are using Git and other modern software development practices
to work together and build amazing products. Software development is changing and with it, the way developers work. 
Today’s rapid pace of communication and innovation fosters creativity, collaboration, and information sharing; 
bringing ideas to life—faster. The GitLab World Tour is an interactive discussion on what's next for software development.</p>



What to Expect</h2>

From ideation and planning to committing, testing, deploying, and getting feedback, 
we are building a toolset that takes an all-inclusive approach to the development process.</p>

</p>

We introduced our Master Plan</a> and now we need feedback from our rock star community as we think about how we can
build the best toolset to help modern developers move faster from idea to production. 
On Tour, you'll hear from GitLab CEO Sid Sijbrandij</a> on the GitLab Master Plan, 
have the opportunity to ask our developers questions, give feedback about our product direction</a>, 
and share your ideas and projects.</p>

Inspiration</h3>


  Conversational Development</strong></p>
  
    Conversational Development (ConvDev)</strong> is a natural evolution of software
development that carries a conversation across functional groups throughout
the development process, enabling developers to track the full path of
development in a cohesive and intuitive way. ConvDev accelerates the
development lifecycle by fostering collaboration and knowledge sharing
from idea to production.</p>
  </div>
</div>

It's an exciting time to be a developer. There is a steady rise of new tools, languages, and practices. 
We'll take a look at some incredible community projects and share information that you can take back to your teams
including information on Conversational Development and the modern development lifecycle, Continuous Integration, and 
trends in open source.</p>

Conversation</h3>

We value our community and are eager to trade ideas with you. We've planned our sessions to be interactive so there will be
plenty of time for you to ask questions and share feedback.</p>


  GitLab Vision</strong></p>
  
    The vision of GitLab is to allow everyone to collaborate on all digital content
so people can cooperate effectively and achieve better results, faster.
We can do this by providing an integrated set of tools that allows you to go faster
from idea to production</a>.</p>
  </div>
</div>

Project #AmplifyYourCode</h4>

At GitLab, we owe our success to our community and the thousands of contributors who help make GitLab.com great. 
Thanks to you, we can ship faster to deliver the best toolset for the modern developer. Now, it's your turn to take the spotlight.</p>

Submit your best GitLab project</a> to amplify your code and to have your project showcased in front of hundreds of developers 
during the GitLab World Tour and promoted on the GitLab blog and social channels.   What are you waiting for? Make your voice heard! Who knows, it could be your greatest hit.</p>

Swag</h3>

It's not a tour without some commemorative item that says, "I was here." Every stop on this tour will have their own city-specific GitLab swag.</p>

</p>

Are you ready to amplify your code?</h2>

The World Tour will make stops in London</strong>, New York City</strong>, and Amsterdam</strong> before ending on a high note
in San Francisco</strong> at our user conference early next year. The GitLab Team will travel city to city,
working in concert with git users like yourself, gathering feedback and stories to help make your git
workflow even more seamless. We would also like to trumpet about some major developments features in GitLab.</p>

Here is a list of some of the topics we will be covering:</p>


  Modern Software Development</li>
  
Conversational Development (ConvDev)</li>
  
Continuous Integration</li>
  
Continuous Delivery & Continuous Deployment</li>
  
The Open Source Community</li>
  
Innersourcing, Microservices, and Version Control</li>
  
GitLab Direction</li>
  GitLab Community Edition, Enterprise Edition, and GitLab.com</li>
</ol>

We hope that some of those themes will strike a cord with you and your team. Come, share your ideas and amplify your code at a stop near you.</p>

Take a minute to register</a> for our opening act in 🇬🇧 London 🇬🇧 on Oct 19th. Can't wait to rock out with you!</p>






GitLab Infrastructure Update
2016-09-26T00:00:00+00:00
As Infrastructure Lead, my job is to make GitLab.com</a> fast and highly available.</p>

Lately, it's been a challenge. Why? We are hitting our threshold where scale starts to matter. For example, over 2,000 new repos
are being created during peak hours, and CI runners are requesting new builds 3,000,000 times per hour.
It's an interesting problem to have. We have to store this information somewhere and make sure that 
while we're gaining data and users, GitLab.com keeps working fine.</p>

A large part of the issue we're running into as we scale is that there is little or no documentation 
on how to tackle this kind of problem. While there are companies that have written high-level posts, almost none of them
have shared how</strong> they arrived at their solutions.</p>

One of our main issues in the past six months has been around storage. We built a CephFS cluster to tackle both the capacity and
performance issues of using NFS appliances. Another more recent issue is around PostgreSQL vacuuming and how it affects performance locking up the database
given the right kind of load.</p>

As outlined in our values</a>, we believe we have a 
responsibility to document this so other companies know what to do when they reach this point.
Last Thursday, I gave a GitLab.com infrastructure status report during our daily team call</a>. 
Watch the recording or download the slides to see how we're working through our challenges with scaling.</p>



Recording & Slides</h2>

Recording</h3>


  </iframe>
</figure>


</p>

Slides</h3>


  </iframe>
</figure>


</p>






GitLab 8.12.1 released
2016-09-23T00:00:00+00:00
Today we are releasing version 8.12.1 for GitLab Community Edition (CE) and
Enterprise Edition (EE).</p>

This version resolves a number of regressions and bugs in the recent 8.12
release</a>.</p>

Please read on for more details.</p>




  EE:</strong> Prevent secrets being pushed into repository. (!731</a>)</li>
  
EE:</strong> Fix typo in protected_branches usage data. (!758</a>)</li>
  
CE/EE:</strong> Fixed search dropdown labels not displaying.(!6277</a>)</li>
  
CE/EE:</strong> Fix a memory leak in HTML::Pipeline::SanitizationFilter::WHITELIST. (!6456</a>)</li>
  
CE/EE:</strong> Makes Cycle analytics mobile friendly. (!6482</a>)</li>
  
CE/EE:</strong> Fix Cycle Analytics landing widget state and improve state management in Vue. (!6492</a>)</li>
  
CE/EE:</strong> Add link to broadcast messages docs. (!6495</a>)</li>
  
Omnibus:</strong> Fix backslash issues in sv/gitlab-workhorse/run. (!1005</a>)</li>
</ul>

Upgrade barometer</h2>

This version has no 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>
file</a>.</p>

Updating</h2>

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

Enterprise Edition</h2>

Interested in GitLab Enterprise Edition? Check out the features exclusive to
EE</a>.</p>

Access to GitLab Enterprise Edition is included with a subscription</a>.
No time to upgrade GitLab yourself? Subscribers receive upgrade and installation
services.</p>



GitLab 8.12 Released with Cycle Analytics and Global Code Search
2016-09-22T00:00:00+00:00
Whether you're working on a small or a large project, your tools should get out of your way and give you actionable feedback. This month, we're making sure GitLab does both better than ever.</p>

GitLab 8.12 gives you feedback on how efficiently you actually work, helps you find code across the entire instance, makes your workflow much safer with a single click, and much more.</p>

This month's Most Valuable Person (MVP</a>) is
James Munnelly for contributing the
Kubernetes executor in the GitLab CI runner</a>.
This feature allows users to run CI tests in a Kubernetes cluster easily.
James created this merge request over a year ago and showed great patience
and persistence in the review process to see it to completion.
Thanks, James!</p>



Cycle Analytics</h2>

Reducing cycle time, the time it takes you to go from idea all the way to
production, is the first principle of conversational development</a>.
The shorter the cycle time, the higher the efficiency of your team.</p>

In order to make it possible to actually see what your cycle time is, we're
introducing Cycle Analytics</a> with GitLab 8.12.</p>

</p>

Cycle Analytics tells you what your cycle time is and breaks it down into
several steps, so you can quickly see where to improve and accurately predict
when you're shipping something.</p>

Find Cycle Analytics under Pipelines in all your projects.</p>


  Read more in the documentation for Cycle Analytics</a></p>
</blockquote>

Global Code Search (EE)</h2>

If you're running Elasticsearch on your GitLab Enterprise Edition instance,
you will now be able to search through all</em> code on the server!</p>

</p>

Just use the search as before and GitLab will show you matching code from each
project you have access to.</p>

Note that this change requires that you rebuild your Elasticsearch index.
See the upgrade barometer below for more information.</p>

Merge Request Versions</h2>

When you're pushing more than a single commit to a merge request,
it can be hard to view what changed between versions and the target branch.</p>

</p>

With merge request versions you can view previous states of a merge request: compare between a previous commit and the target branch or even between versions, showing you what has changed between certain commits.</p>


  Read more in the documentation for Merge request revisions</a></p>
</blockquote>

Preventing Secrets in your repositories (EE)</h2>

It's a bad idea to commit secrets (such as keys and certificates) to your repositories: they'll be cloned to the machines of anyone that has access to the repository, only one of which has to be insecure for the information to be compromised.</p>

Yet it happens quite easily. You write git commit -am 'quickfix' && git push</code> and suddenly you've committed files that were meant to stay local!</p>

GitLab now has a new push rule that will prevent commits with secrets from entering the repository. Just check the checkbox and GitLab will prevent common unsafe files such as .pem</code> and .key</code> from being committed.</p>

</p>

GitLab Enterprise Edition already had a feature that allows you to block files based on a regular expression, which you can leverage to block anything that we didn't think of. We also welcome suggestions and contributions to make this push rule even better.</p>


  Read more in the documentation on Push rules</a></p>
</blockquote>

Review Apps (Experimental)</h2>

We've made several additions to CI that, when combined, make some magic.</p>

You can now use predefined CI variables as a name for environments. In addition, you can specify a URL for the environment configuration in your .gitlab-ci.yml</code> file. Together, these features bring the first iteration of Review Apps.</p>

Review apps are automatically-created environments that run your code for each branch. That means merge requests can be reviewed in a live-running environment. This was inspired by Heroku's Review Apps</a> which itself was inspired by Fourchette</a>.</p>

These are small changes, but will make a huge impact on your development flow.
Reviewing anything from performance to interface changes becomes much easier
with a live environment.</p>

Right now, Review Apps are labelled experimental, as the environments are not automatically destroyed when no longer necessary.</p>

We're working on a blog post</a> that will have an example.</p>

SSH Authentication for LFS</h2>

If you're used to using SSH for your Git pushes, it was frustrating to
still have to enter credentials whenever using LFS.</p>

GitLab will now leverage your SSH key when using LFS, meaning that if you're
using LFS while connecting through SSH, you no longer have to manually
enter your credentials!</p>

File transfers of LFS still happen over HTTP.</p>

Toggle LFS</h2>

Git LFS (Large File Storage) is great, but as the name implies, it can have
significant impact on your disk capacity. To make you feel a bit more secure about the LFS usage on your instance, you can now toggle LFS on instance, group, and project levels.</p>

For instance, as a GitLab administrator, you can decide to turn off LFS for the entire instance, yet enable it for only a single group or project.</p>

Limit Project Size (EE)</h2>

As an alternative to restricting LFS, you might just want to prevent projects
from growing too large. You can now limit project size. This will take into account all repository data and LFS objects and stop any commits that will surpass that limit.</p>

</p>

You can set a global project limit and override that on group and project level, as an admin. This way, you can give particular projects extra space if necessary.</p>


  Read mote in the documentation about limiting the repository size</a></p>
</blockquote>

LDAP/Active Directory Improvements</h2>

This release contains several improvements to LDAP/Active Directory support
for GitLab CE and EE:</p>


  CE/EE - Request only the LDAP user/group attributes that GitLab requires (CE !6187</a> and EE !712</a>), reducing the amount of data across the wire between GitLab and the LDAP/Active Directory server. This also decreases the object memory footprint within GitLab.</li>
  
EE - Faster Active Directory nested group and ranged member (large group) retrieval (!719</a>)</li>
  
EE - Add 'Sync now' option to group membership page when LDAP group links are present (!704</a>)</li>
</ul>

Recover 2FA tokens through SSH</h2>

You can now recover your 2FA security codes using SSH. This should make it
easier to recover your account, while still maintaining a level of security.</p>


  Read more in the documentation about recovering 2FA via SSH</a>.</p>
</blockquote>

Filter Tags by Name</h2>

Want to quickly find a tag? That's much easier now with a handy little filter on top:</p>

</p>

API additions</h2>

We've expanded our API on several points with GitLab 8.12:</p>


  Allow to set request_access_enabled</code> for groups and projects using API</li>
  
Add notification_settings</code> API calls</li>
  
Add a BroadcastMessage</code> API</li>
  
You can now fork to a specific namespace through the API</li>
  
Allow to set enable/disable access request for groups and projects.</li>
  
Add web_url</code> field to issue, merge request, and snippet objects.  (community contribution)</li>
  
Expose sha</code> and merge_commit_sha</code> in merge request API.  (community contribution)</li>
  
Expose issue confidentiality flag.  (community contribution)</li>
  
Added only_allow_merge_if_build_succeeds</code> project setting.  (community contribution)</li>
  
Add endpoint to lint your .gitlab-ci.yml</code> file.  (community contribution)</li>
  Add an API to list manual actions on Environments and Deployments</li>
</ul>

Improved GitHub Importer</h2>

Our GitHub importer keeps getting better, making it easier to migrate to
GitLab. With GitLab 8.12, the importer will also copy release notes over to
GitLab and now lets you choose the namespace you want your imported projects
to go into.</p>

</p>

This should make it easier to migrate if you already have existing projects
or prefer something different than GitLab's way of importing your projects.</p>


  Read more in the documentation about importing your repositories from GitHub</a>.</p>
</blockquote>

Bulk update Merge Requests</h2>

You can now bulk update merge requests. This means you can set the status, assignee, milestone, label or subscription to multiple merge requests at once.</p>

</p>

Managing merge-request-heavy project should be a lot easier with this!</p>

!6226</a></p>

Build Grouping</h2>

If you have many similar builds, your pipeline graph becomes very long. We've made a small change to improve this: similar builds will now automatically group together.</p>

</p>

Expanded syntax highlighting</h2>

By upgrading to rouge</a> 2.0.6, we've added syntax highlighting for JSX, Prometheus, mxml, 1c, turtle/trig, vhdl, and improved highlighting for Swift 3.</p>

Sentry integration of Workhorse</h2>

GitLab-Workhorse can now report application errors to Sentry.</p>


  Read more in the GitLab-Workhorse docs</a></p>
</blockquote>

GitLab Runner 1.6</h2>

We are also releasing GitLab Runner 1.6 today. Some highlights:</p>


  Kubernetes executor (!30</a> and !277</a>), this allows Kubernetes to automatically scale the number of CI runners. All your builds will be processed immediately without having idle machines running when it's not busy.</li>
  
Autocompletion of /ci</em> in GitLab URL while registering the Runner (!289</a>)</li>
  
Configuration options for specifying scripts executed before clone/fetch is done and before build script is executed (!106</a>)</li>
  
Improvements in passing CA certificates to builds (!299</a>)</li>
  
Improvement in disabling recursive submodules fetching/cloning (!314</a>)</li>
  
Improve docker machine logging (!234</a>)</li>
  
Add possibility to specify a list of volumes to inherit from another container (!236</a>)</li>
  
Generate a BuildError</code> instead of SystemError</code> when Docker/Kubernetes image is missing (!295</a>)</li>
</ul>

To see the full list of all changes please read the Runner's CHANGELOG file</a>.</p>

GitLab Mattermost 3.4</h2>

GitLab 8.12 includes Mattermost 3.4</a>,
an open source Slack-alternative</a> whose newest
release offers 700 integrations with full Markdown support via Zapier,
simplified bot and 3rd party authentication via OAuth2, and community
integrations with Gitter, Heroku, Pivotal Tracker, Chef, Ansible and Yunohost.</p>

Performance Improvements</h2>


  Sidekiq processes now use a connection pool when using Rails' caching
mechanism: merge request</a></li>
  
The oj</code> Gem is now used for faster JSON processing: merge request</a></li>
  
The column projects.last_activity_at</code> is only updated once an hour to reduce
database load: merge request</a></li>
  
The column projects.pushes_since_gc</code> has been moved from the database to
Redis to reduce database load: merge request</a></li>
  
Protected branch checks are not performed when no branch name is known,
reducing time spent in this process: merge request</a></li>
  
Checking if one can resolve a note is only done when notes can be resolved in
the first place: merge request</a></li>
  
The ci_runners</code> table is now updated less frequently to reduce database load:
merge request</a></li>
  
The number of database queries used for the "Builds" tab for
commits/merge requests has been reduced: merge request</a></li>
  
The payload size for the contributions calendar has been reduced:
merge request</a></li>
</ul>

Build permissions changes</h2>

GitLab 8.12 brings very important changes to build permissions.</p>

We decided that build permissions should be tightly integrated with the
permissions of the user triggering a build for the following reasons:</p>


  We already have a permission system in place: group and project membership of
users.</li>
  
We already know who is triggering a build (using git push, using web,
executing triggers).</li>
  
We already know what that user is allowed to do.</li>
  
We use the user's permissions for builds that are triggered by pusher.</li>
  
It is simple and convenient that your build can access everything that you
have access to.</li>
  
We can issue a short-lived unique tokens, granting access for the duration of
the build.</li>
  
It fits very well into our philosophy of having everything integrated.</li>
  This provides a lot of possibilities to further enforce user permissions, such
as allowing only specific users to access runners, secure variables and
environments.</li>
</ul>

Now, any build that was triggered by the user is also signed with his
permissions. When a user does git push</code> or modifies files through the UI (the
pusher</strong>), we will create a new Pipeline. The Pipeline will be owned by the
pusher. So builds created in this pipeline will have the permissions of the
pusher</strong>.</p>

This allows us to make it easy to evaluate access for all dependent projects and
container images that the pusher would have access too. The permission is
granted only for the duration of the build. The access is revoked after the
build is finished.</p>

For detailed information about the build permissions and the changes it brings
please see our documentation</a>.</p>

For the history and reasoning behind this change, you can read the full
discussion in the issue</a>.</p>

Submodules in CI</h2>

Submodules were one of the reasons we redesigned the build permissions.
Now using Submodules in your CI builds is easy.</p>

To use submodules you have to use a .gitmodules</code> file, which looks something
like this:</p>

[submodule "tools"]</span>
    path</span> =</span> tools</span>
    url</span> =</span> git@gitlab.com/group/tools.git</span>
</code></pre>
To use the new build permissions for your submodules you have to convert your
URLs to be relative:</p>

[submodule "tools"]</span>
    path</span> =</span> tools</span>
    url</span> =</span> ../../group/tools.git</span>
</code></pre>
This will instruct Git to use the same credentials as it would for checking out
your project sources.</p>

The last step is to tell GitLab CI to fetch submodules:</p>

before_script</span>:</span>
  -</span> git submodule update --init --recursive</span>
</code></pre>
You can read more about support for submodules in our documentation</a>.</p>

Other changes</h2>

This release has more improvements, including security fixes. Please check out
the Changelog</a>
to see the all named changes.</p>

Upgrade barometer</h2>

This release requires downtime due to foreign keys being added, column types
being changed, and various columns being removed from some tables. The whole
migration process could take up to 30 minutes for large instances. Smaller instances should expect a downtime of about 10-15 minutes.</p>

(EE Only) Elasticsearch re-indexing</h3>

We changed the structure of Elasticsearch index for repositories, making use of Parent Child relationships. This requires a total rebuild of the ES index. Also
Elasticsearch 2.3.x contains a bug that causes to fail all queries that use highlight feature and Parent Child relationship at once, so we recommend to use the version 2.4 and newer. After upgrading to GitLab 8.12, you will need to remove the old index and rebuild new index:</p>

To remove the old index, call to Elasticsearch:</p>

curl -XDELETE 'http://localhost:9200/gitlab-production/'
</code></pre>
Then rebuild new indexes as described in Elasticsearch integration</a></p>

Ruby Update</h3>

In our last release blog post we mentioned we'd be dropping Ruby 2.1.x support in GitLab 8.13, we no longer plan to stop supporting Ruby 2.1.x in
the near future.</p>

We still recommend you upgrade to Ruby 2.3 if you're running a source
installation, as this is the same version that ships with our Omnibus package
now.</p>

Expanded usage data ping (EE)</h3>

In order to better understand the usage of GitLab by our customers,
GitLab 8.12 EE now sends additional data along with its usage ping.</p>

No information about the nature of the data, such as project names, comments or
other content is transmitted. You can view the exact data that is sent in
the admin settings, where this feature can also be disabled entirely.</p>


  See also the implementation in the merge request</a></p>
</blockquote>

GitLab-Workhorse Secret Key</h3>

GitLab-Workhorse now uses a secret key to sign certain messages sent
to the GitLab Rails application. For now this is mostly a
configuration sanity check; in future releases we want to add features
to GitLab-Workhorse that require this secret key to establish trust.</p>

If you use our Omnibus packages, or if you installed GitLab from
source with our official init.d script, then this secret key will be
generated and picked up automatically for you. If you use a custom
init.d script or if you use packages not created by GitLab Inc. then
you may have to set the -secretPath</code> option on GitLab-Workhorse.</p>

Note</h3>

We assume you are upgrading from the latest version. If not, then also consult the upgrade barometers of any intermediate versions you are skipping.
If you are upgrading from a GitLab version prior to 8.0 and</em> you have CI enabled, you have to upgrade to GitLab 8.0 first</a>.</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>
file</a>.</p>



Installation</h2>

If you are setting up a new GitLab installation please see the
download GitLab page</a>.</p>

Updating</h2>

Check out our update page</a>.</p>

Enterprise Edition</h2>

The mentioned EE only features and things like LDAP group support can be found in GitLab Enterprise Edition.
For a complete overview please have a look at the feature list of GitLab EE</a>.</p>

Access to GitLab Enterprise Edition is included with a
subscription</a>.
No time to upgrade GitLab yourself?
A subscription also entitles you to our upgrade and installation services.</p>





Feature Highlight: Cycle Analytics
2016-09-21T10:00:00+00:00
On September 22nd, we will release GitLab 8.12</a> with Cycle Analytics</a>. Cycle Analytics tells you how long
it takes your team to go from idea to production</a> on each of their projects.</p>

Few teams can answer how long
their software projects take and fewer can answer how long each stage in the process takes. Without this information,
you do your best to estimate the time or level of effort that it will take to get from an idea to customer-ready code.</p>

Unfortunately, most teams are flying blind on their estimates using past experiences and best
guesses to offer a semblance of how long it’ll take to complete a project. It’s no wonder
why estimates are often incorrect</a>.</p>

We built Cycle Analytics to stop blind estimation and instead show you
real data on your team’s velocity. You'll see how long the total process takes as well as how much time you spend in each stage.</p>



Why Cycle Analytics Recap</h2>

Last week, we wrote a "feature preview" on what Cycle Analytics is and how it can help your team</a>. The TL;DR takeaway from
that post was: reducing cycle time is a competitive advantage</strong>. Cycle Analytics helps you uncover how long it actually takes to complete your development process.
A shared view of the team's velocity is the first stage to improving it.</p>

Measuring the Modern Development Lifecycle</h2>

</p>

Cycle Analytics tracks the median</a> time it takes your team to complete every stage in the modern development process.</p>


  Cycle Analytics Stages</strong></p>
  
    - Issue</strong> (Tracker)
  - Median time from creating an issue to assigning the issue to a milestone or adding the issue to a list on your Issue Board</p>

    
- Plan</strong> (Board)
  - Median time from giving an issue a milestone or adding it to an Issue Board list to the pushing first commit</p>

    
- Code</strong> (IDE)
  - Median time from the first commit to creating the merge request</p>

    
- Test</strong> (CI)
  - Median of the time CI takes to run every build for the related merge request</p>

    
- Review</strong> (Merge Request)
  - Median time from creating the merge request to merging it</p>

    
- Staging</strong> (Continuous Deployment)
  - Median time from MR merge until deploy to production</p>

    
- Production</strong> (Total)
  - The time it takes between creating an issue and deploying the code to production</p>
  </div>
</div>

Note:</strong> This the first iteration of Cycle Analytics. As you know, we ship the smallest thing to provide initial value and then we learn from your feedback and continue to improve the feature over time. We have ideas about what we will build next for Cycle Analytics but we'd love to hear your thoughts. You can follow and contribute to the discussion on this issue</a>.</p>

Cycle Analytics Follows GitLab Flow</h2>

In recent months, we've talked a lot about our vision</a> of being an integrated set of tools for the full software development lifecycle. Cycle Analytics is another testament to the benefits of having an integrated toolset.
The reason we are able to measure cycle time is because GitLab stores all of the data around your development efforts, and the associated metrics, in one central data store. Now, we're able to surface that data through Cycle Analytics.
However, it's important to note that Cycle Analytics tracks cycle time based on the GitLab Flow</a>. Therefore, there are some noteworthy dependencies.</p>


  Cycle Analytics & GitLab Flow</strong></p>
  
    
      Cycle Analytics is a measure of how long it takes the team to complete the cycle. Therefore, we only track cycle time on issues that have been deployed to production.</strong></li>
      Cycle Analytics uses your GitLab CI configuration file to understand which environment</code> is set to production</code></a>. For Cycle Analytics to track your cycle time, you'll need to configure GitLab CI</a>.</li>
      
The Plan</strong> stage measures the time from assigning an issue to a milestone or moving it to a list on the Issue Board to pushing the first commit. For Cycle Analytics to track this time, your commit message must include the issue closing pattern</a> like Closes #xxx</code>, where xxx</code> is the issue number related to this commit.</li>
      
The Code</strong> stage measures the time between pushing the first commit and creating a merge request (MR) related to that commit. For Cycle Analytics to track this, you’ll need to add an issue closing pattern</a> like Closes #xxx</code> to the description of the MR.</li>
    </ul>
  </div>
</div>

We recognize that every team does not follow the same flow. And while GitLab is a flexible product, we are also building an opinionated product that’s aimed at helping you move faster from idea to production. Our CEO, Sid Sijbrandij, shared his thoughts on GitLab Workflow best practices</a>. We hope that they help simplify your workflow within GitLab.</p>

Getting Started</h2>

On September 22nd, Cycle Analytics</a> will be available in GitLab.com, GitLab Community Edition, and GitLab Enterprise Edition. Getting started is the same in all three products. All you have to do is navigate to your Project’s Pipelines</strong> tab and then select Cycle Analytics</strong> to see your project's dashboard.</p>

Keep in mind that if you're working in a new project and you haven't deployed anything to production then you won't see any data on your Cycle Analytics dashboard.</p>

Join Our Release Webcast</h2>

Join us on September 29th for our Cycle Analytics and GitLab 8.12</a> Release Webcast. We'll demo some exciting new features and hold a Q&A. Register here</a>.</p>
GitLab

GitLab 8.12.3, 8.11.8, 8.10.11 and 8.9.11 released

GitLab World Tour: Amplify Your Code

Recover 2FA tokens through SSH</h2> You can now recover your 2FA security codes using SSH. This should make it easier to recover your account, while still maintaining a level of security.</p>

Filter Tags by Name</h2> Want to quickly find a tag? That's much easier now with a handy little filter on top:</p> </p> API additions</h2> We've expanded our API on several points with GitLab 8.12:</p>

API additions</h2> We've expanded our API on several points with GitLab 8.12:</p>

Build permissions changes</h2> GitLab 8.12 brings very important changes to build permissions.</p> We decided that build permissions should be tightly integrated with the permissions of the user triggering a build for the following reasons:</p>

Feature Highlight: Cycle Analytics
