GitLab 8.15.3 released

2017-01-06T00:00:00+00:00

Today we are releasing version 8.15.3 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p>

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

This version includes a migration which will rename projects</strong> that became inaccessible in version 8.15 due to reserved names. We would have preferred to do this in the monthly release rather than a patch release, but weighed against inaccessible projects we believe it's a reasonable tradeoff.</p>

CE/EE:</strong> Rename projects with reserved path names (!8234</a>)</li>
CE/EE:</strong> Whitelist next project names: assets, profile, public (!8470</a>)</li>
CE/EE:</strong> Fix 500 error when visit group from admin area if group name contains dot (!8342</a>)</li>
CE/EE:</strong> Fix GFM dropdown not showing at beginning of new lines (!8338</a>)</li>
CE/EE:</strong> Fix error 500 renaming group. (!8201</a>)</li>
CE/EE:</strong> Pipeline stylesheets changes (!8224</a>)</li>
CE/EE:</strong> Fix cross-project references copy to include the project reference (!8232</a>)</li>
CE/EE:</strong> Revert MattermostNotificationService and SlackNotificationService (!8240</a>)</li>
CE/EE:</strong> Use stable icon for Mattermost integration (!8252</a>)</li>
CE/EE:</strong> Resolve "Labels are not consistent on all pages" (!8256</a>)</li>
CE/EE:</strong> Fix 500 errors when creating a user with identity via API (!8442</a>)</li>
CE/EE:</strong> Remove bottom border from Issuable titles (!8278</a>)</li>
CE/EE:</strong> Fix project hooks params (!8425</a>)</li>
CE/EE:</strong> Gitlab::LDAP::Person uses LDAP attributes configuration (!8418</a>)</li>
CE/EE:</strong> LDAP attributes needs default values (!8465</a>)</li>
CE/EE:</strong> Removes invalid HTML and unneeded CSS to prevent shaking in the pipelines tab (!8411</a>)</li>
CE/EE:</strong> API: extern_uid is a string (!8404</a>)</li>
CE/EE:</strong> Increases pipeline graph drowdown width in order to prevent strange position (!8399</a>)</li>
CE/EE:</strong> Copy, don't move uploaded avatar files (!8396</a>)</li>
CE/EE:</strong> Add API route slack slash commands (!8362</a>)</li>
CE/EE:</strong> Fixed regression of note-headline-light where it was always placed on 2 lines (!8348</a>)</li>
CE/EE:</strong> Fix left border in session tabs (!8346</a>)</li>
CE/EE:</strong> Fix unclear closing issue behaviour on Merge Request show page (!8345</a>)</li>
CE/EE:</strong> Fix grammar error in text about mentioned issues (!8337</a>)</li>
CE/EE:</strong> Only limit container width on issues & MRs within fixed-width container (!8330</a>)</li>
CE/EE:</strong> Cache project authorizations even when user has access to zero projects (!8327</a>)</li>
EE:</strong> Only fetch repo once on secondary after push (!1015</a>)</li>
EE:</strong> Disable LDAP permission override in project members edit list (!1018</a>)</li> </ul>
Upgrade barometer</h2>
This version includes a post-deploy migration and should not require any downtime.</p>
We recommend clearing the GitLab cache (gitlab-rake cache:clear</code>) after upgrading to 8.15.3 due to the renamed projects.</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>

Prometheus and GitLab

2017-01-05T00:00:00+00:00

A little while ago, we presented a first draft of our vision for monitoring within GitLab. We value transparency</a>, so see below for the recorded video and transcript of the presentation, or view the slides</a> directly. Please do give us your feedback on any of the linked issues!</p>

</iframe> </figure>

GitLab Monitoring Vision 0.1</h2>
Thanks everyone for joining. Just to level set: This call is to go over a first draft of our vision for monitoring within GitLab. A version 0.1 of the vision, if you will. I’m presenting it so Sid and others can ask questions and critique it, and to share more broadly. If you’re looking for a polished presentation about a well-defined product, this is the wrong place. :)</p>
I’ll start by talking about a potential minimum viable product (MVP), and then discuss future directions, and finally open it up to Q&A.</p>
And if you want to play along at home, here’s a link to your personalized buzzword bingo card</a> for the presentation.</p>

Minimum Viable Product (MVP)</h2>
Use Prometheus to Monitor GitLab Installation</h3>
So the first step is to add Prometheus</a> to monitor GitLab installations themselves. I won’t go into details here; and I believe Pablo will be giving a talk about how we’re using it</a>. But in short, Prometheus is an open source monitoring solution. We’ve been using it internally here, and we’re going to bundle it up with GitLab CE so you can use it to monitor your own instances of GitLab.</p>
Meta issue: gitlab-com/infrastructure/issues/589</a></p>
Related issues:</p>

Expose service metrics via Prometheus</a></li>
Monitor CI end to end with prometheus</a></li>
Build public monitoring infrastructure</a></li>
Bundle Prometheus with GitLab CE</a></li>
Build High Available (Federated) prometheus monitoring solution</a></li> </ol>
Here’s a couple screenshots I cribbed from some of those issues. Again, I’m not going to go into detail here. These are fairly traditional, if not ugly, dashboards using Prometheus and Grafana.</p>
</p>
</p>
MVP+3</h2>
Web Application Monitoring</h3>
I kind of tongue-in-cheek called this MVP+3, but after some number of iterations, the next major</strong> step is to use Prometheus to monitor end-user applications</a>. Ideally, providing a New Relic</a>-like experience. Maybe it’s more accurate to say Heroku-like monitoring</a> experience. New Relic does TONS of things we won’t touch for a long time, if ever. I believe there’s always a place for dedicated monitoring solutions that go deep. Our unique value won’t be in the deepness of the monitoring, it’ll be in the integration of monitoring into the rest of the experience. That may not be apparent in the initial release, but will show up later.</p>
MVP focuses on:</p>

Limit to applications on Kubernetes</li>
Response: Throughput, latency, errors</li>
Resource: CPU, Memory, I/O</li> </ul>
Initially we’ll focus on Kubernetes because that’s where we’re placing a few bets and installing Prometheus into every permutation of hardware is just too much to tackle. So to keep scope smaller, we’ll focus on Kubernetes.</p>
We’ll start by measuring throughput, latency (or response time), and error rates. I’m calling this response monitoring, and it’s the highest value we can deliver that works for monitoring any web stack.</p>
But measuring resources such as CPU, memory, and I/O might be easier for an MVP, so I’m keeping that open. Kubernetes may make some parts of that easier, but others harder. I don’t believe we should do all of this for an MVP, so my preference would be the web response side of things. The thinking goes: if one of the resources are constrained, say memory is entering swap too much, then that will show up as latency in the system. So I’d rather observe the material impact to the user directly. Unfortunately that means you don’t see anything until it’s already an impact. And knowing that latency is bad or error rates are up doesn’t help you debug the situation. That’s where resource monitoring can be useful. But still, as a first step, I want to know how my users are impacted and THEN find a way to debug it, at which point I may very well fire up New Relic to do more powerful analysis.</p>
Monitoring Alert on Merge Request</h3>
So to show how we’re thinking of integrating monitoring, here’s a merge request, that has already been merged and deployed to production. Because we’ve got monitoring, GitLab noticed that memory usage increased right after the deploy, so we get a message right on the merge request.</p>
</p>
Let’s zoom in a little more. We see the alert, plus some summary information, telling you the memory usage increased from 114MB to 127MB, and a little spark line so you can see it graphically. Maybe we’d add a percent increase to make it more concrete. Of course, we’d also send an email notification of this alert, to the author of the actual changes about the impact. That way, this isn’t just an ops problem, the person or people most likely to be be able to deal with it know as soon as possible. Now let’s click through and see more details.</p>
Monitoring Dashboard</h3>
So now we see something a little more traditional. This is an early mockup of how a monitoring dashboard could appear. Note even in this early stage, we’ve got lines showing when deploys happened, to help identify code changes that impacted performance. Maybe hovering over them would show a list of merge requests that were included in that deploy.</p>
</p>
This dashboard would be available for all of your environments: production, staging, and review apps. Or maybe you’d only want to install it for production environments. I’m not sure yet. The point is that monitoring is an essential part of environments, deployments, and MRs.</p>
Deployment History</h3>
This is a screenshot cribbed from New Relic, but I could imagine some of this information show up on our deployment history pages.</p>
</p>
Future</h2>
Monitoring++</h3>

Response monitoring (throughput, latency, errors)</li>
Resource monitoring (CPU, memory, IO)</li>
Status monitoring</a> (e.g. Pingdom, up/down/uptime, bad MR)</li>
Application performance monitoring (APM) (stack-aware, endpoint-aware, code-aware, db-aware)</li>
End-user experience monitoring (measured at the browser)</li>
User metrics/analytics (e.g. clicks, flows, funnels, a/b testing)</li>
User-defined / business metrics (signups, conversions, revenue)</li>
Integrated deeply, across the developer experience</li> </ul>
So the future holds an infinite set of possibilities, but I’ll talk about a few directions I’d like to consider moving into.</p>
First, there’s more to flesh out in response and resource monitoring, covering whatever we don’t ship in the MVP, and going beyond.</p>
Then there’s status monitoring. Think Pingdom</a>, which tracks whether your app is responding to a certain HTTP request to know if it’s “up” or “down”, and then alerting on that, and reporting uptime. The linked issue describes an MVP that just checks a URL after each deploy to see if your merge request borked the server or not. I have no idea yet what role Prometheus may play here.</p>
Then there’s the broader application performance monitoring, which really is a superset of these other pieces, but I’m breaking it out to differentiate monitoring that usually requires your code to be instrumented with a client library installed in your application; like a Gem file or an npm module. Generally, it’s language, framework, and stack aware, can analyze code paths, and even profile database SQL queries.</p>
The next level most APM companies go to is end-user experience monitoring; measuring latency at the browser so it includes the entire trip over the interwebs, and including the time to finish asynchronously loading all Javascript and actually rendering the web page. This gives a truer, and often much scarier, view of the performance of your app.</p>
Then there’s user metrics/analytics. Clicks, flows, and funnels.</p>
Lastly, we’ve got user-defined or business metrics like signups, conversions, revenue, or really any action that you determine is important for your business success, or just fun to watch.</p>
Now, I’ve pretty much just defined the entirety of several monitoring industries. Obviously we’re unlikely to be best-of-breed in all of these. At least not in the next release or two. So again, the focus really is how we can provide the biggest bang-for-buck, the 20% effort that delivers 80% of the value, and really leverage our unique value, and that’s in our deep integration; making everything easier to use because it’s already there, and more impactful because it’s integrated across the experience. Anyone can show a graph of performance, where you can see that deploy 123 of merge request XYZ caused a problem, but alerting right on the merge request itself, right after deploying it, and emailing the authors of the actual changes about their impact, well, that’s just the tip of the iceberg of how monitoring could permeate the developer experience.</p>
Deploy Monitoring</h3>

Track status of deploy from start to finish</li>
Finer state detail (ready, preparing, waiting, deploying, finished, failed)</li>
Aware of rollout across multiple containers/servers</li>
Ability to abort a deploy</li> </ul>
Now let’s go in a different direction and talk about something I’m calling deploy monitoring</a>. Deploys aren’t just binary pass/fail, and they’re not instantaneous, but we currently kinda treat them as if they’re both. Deploys can take significant time, going through many different states, and across many containers or servers. Being able to track and debug that complexity is pretty important, especially for larger organizations.</p>
Deployboard</h3>
So here’s an early mockup of how we could integrate this information into our environment view.</p>
</p>
On staging, you see that the last deployment finished, but production has a deployment that is ongoing. Each square represents a container, managed by Kubernetes. Hovering over each one shows the server name and it’s current status. Clicking through might show more details about that container. Since this is the environment list, we also see our review apps, but we’ve hidden the deploy status by default since it’s less important for review apps. For any of these environments, you can click through to the monitoring dashboard I already showed.</p>
Deploy Monitoring++</h3>

Notify authors of MRs that their changes are now live or in staging</li> </ul>
Now deploy monitoring is a rich area with lots of opportunities for growth. Here’s an image from someone else’s Deployboard that shows a Slack notification of a staging deploy, and @ mentioning everyone with code in that change.</p>
</p>
Here are some other ideas I want to explore:</p>

Incremental rollouts (deploy to 10 containers at a time)</li>
Canary deploys (deploy 10 containers, then wait for stats or manual tests)</li>
Blue/green deploys</li> </ul>
First is incremental rollouts where you deploy new code in batches. Say if you’ve got 100 containers to roll, you’d deploy 10 containers at a time, in 10 batches, until all 100 are done.</p>
Closely related to that is a canary deploy, where you deploy to a few containers, and then stop while you wait some period of time for performance statistics to prove that there are no problems. Maybe even do some manual tests on those containers, although really that should have been done in staging.</p>
And then there’s blue/green deploy, which has a few definitions, but the one I’m using here is where you have all your traffic going to one fleet of containers or servers, call that the blue fleet. Then you start deploying new code to a green fleet, but don’t send any traffic to it. When the green fleet is up and ready, then you cut over the router to suddenly send all traffic to the green fleet and the blue fleet goes idle. You could leave that blue fleet running in case you need to immediately revert. It’s much faster to switch a router over rather than wait for all servers to deploy again. If you’re using physical servers, these fleets may be permanent, meaning you’ve got to have twice the computing capacity at any time. If they’re containers, you can bring down the idle fleet after some time and then just spin it up again when you do the next deploy.</p>
But again, these are standard deploy strategies that companies already use. Of course we want to support these best practices, but our challenge will be to integrate these closely into GitLab to deliver even more value from the integrated whole. Integrating deploy strategies with monitoring and our knowledge of the codebase, merge requests, and issues. Maybe an alert of a performance problem automatically generates a new issue labeled appropriately and assigned to the right person so it shows up in their todos.</p>
Feature Flags</h3>

Decouple deployment from delivery</li>
In-code flag to execute one path or another based on externally controllable settings</li>
Binary switch</li>
Incremental (%) rollout</li>
Named group (internal, beta)</li> </ul>
I’m going to go off on a tangent for a moment and talk about Feature Flags</a>. Feature flags allow developers to decouple deployment from delivery while reducing risk. It’s usually an in-code mechanism, like an if statement, to conditionally execute one path or another based on externally controllable settings such as a simple all-or-nothing binary switch, or a more complex incremental rollout based on percentages, like turning it on for 10% of your users, or involving named groups like company internal, or a "beta” group. With feature flags, code can be deployed into production while the feature is still turned off.</p>
My ideal rollout is something like:</p>

Dev team that created it -></li>
internal alpha (all employees minus those giving customer-facing demos) -></li>
select beta (~200 people that signed up for this specific feature) -></li>
private beta (~1000 people that signed up for general beta) -></li>
public beta -></li>
10% rollout -></li>
GA</li> </ul>
Features can then be rolled out to internal users, beta users, a percentage of production users, and then to everyone in ever-increases spheres. This help facilitate healthy real-world testing, restricting risk to affect only beta customers rather than everyone, for example, so that you get feedback earlier in the development cycle. Validate your ideas quickly. It also helps stay true to the premise of continuous integration which is that everything is checked into master often and deployed right away. This reduces deployment risk.</p>

Feature Flags as first-class citizens</li>
Compare flag states across environments (e.g. staging has X, which is not yet enabled on production)</li> </ul>
I'd like to see us work feature flags into GitLab</a> in a first-class way. To be honest, I really don’t know how to do that. But I know I’d like to visually see, at a glance, which features are in private beta, for example. If a product manager tries to turn a feature on for general availability, they’ll be subtly reminded that they should consider going through private beta first. Companies should be able to set a rollout policy of what percentages things should go through at each stage. If done right, it’ll encourage a good rollout process, and make it trivially easy for users to follow the flow, every time.</p>
</p>
Feature Monitoring</h3>
Now to bring this back to monitoring, feature flags are another rollout mechanism, similar to some of the deployment strategies. So we should be able to monitor these</a>, showing some analysis/graphing on them. Perhaps it’s a simple list of features and summary statistics about them indicating if they're performing as expected. Like:</p>

Feature X, rolled out to beta, decreased response time by 5%</li>
Feature Y, rolled out to 10%, increased conversion by 25%</li> </ul>
The good thing is that since feature flags often run in parallel, so you’ve got some users with the flag and some users without, you can more accurately determine the performance or other impact. You don’t have to rely on point-in-time changes, like looking at memory before and after a deploy.</p>
And it’s quite possible to have multiple flags at the same time, all at different rollout stages. With a deploy, which ships everything in master at once, if there’s a problem with one merge request 25 commits ago, you’ve got to rollback the entire stack until that change is gone. But feature flags are decoupled so if there’s a problem in an individual feature, you can just scale it down to zero without affecting any other feature, and without requiring a lengthy deploy process.</p>
Another side note, since deployment strategies and feature flags are somewhat advanced topics that currently take quite a commitment to implement, most companies only focus on one of these strategies. If you work on feature flags, you’re not likely to bother with canary deploys, for example. But each tool has their sweet spot of value. Memory problems aren’t likely to show up using feature flags since memory is a system resource that’s really hard to pin down to a specific user. But error rates or conversion metrics are great for this. If we do a great job here, maybe people won’t have to be so stingy on their choice of tools.</p>
Q&A</h3>
And with that, I’d like to thank you all for listening, and open it up to questions.</p>

P.S. I really love being able to work out in the open like this, publicly sharing our vision long before it's a reality. If you love the same, please check out or jobs page</a>. We're looking for more Prometheus Engineers</a> (and many other positions)! Tweet us @GitLab</a>, add your questions below, and add suggestions to our issue tracker</a>!</em></p>

GitLab 8.15.1 released

2016-12-23T00:00:00+00:00

Today we are releasing version 8.15.1 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p>

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

Please read on for more details.</p>

GitLab 8.15 Released with Auto Deploy and Web Terminal

2016-12-22T00:00:00+00:00

With this last release of the year, we're not only completing our Master Plan</a>, but we want to show you something cool we've been working on:</p>

</iframe> </figure>

</p>

With GitLab 8.15, we're introducing Auto Deploy (shown in the video at 1:42</a>), which automates setting up deploys and review apps. For a Ruby on Rails project, this brings setup time to under a minute.</p>

Plus, to make accessing your environments easier and faster, you can now access them directly through a terminal in GitLab (shown in the video at 5:18</a>).</p>

We want to give the power of containers, continuous integration and deployment, review apps and container schedulers to everyone. With GitLab 8.15, we take away all the hard work without hiding anything. In the demonstration we setup and deploy a Ruby application with review apps, multiple environments, chatops to a Kubernetes cluster in about 12 minutes. This typically takes days, if not weeks to setup and use without GitLab.</p>

For many people, December is a month of celebration and gift giving. This month, GitLab was again so lucky to receive many great contributions.</p>

The MVP of this month is Michael Munch</a> for bringing beautifully-typeset math (LaTeX) to GitLab. Michael worked over a period of 6 months in merge requests with in total more than three hundred comments to bring this to GitLab.</p>

We'd also like to thank Warren Postma</a> for his contributions on the issue trackers, and the community forum</a> and generally being a great advocate of the product and the company</a>. And lastly, we want to thank Elan Ruusamäe</a> and Dirk Hörner</a> for their contributions in technical design and implementation that have given super powers to Git Hooks.</p>

Thanks Warren, Michael, Elan, and Dirk!</p>

Auto Deploy</h2>
We want everyone to quickly get a fully functioning CI/CD pipeline that deploys to a container scheduler. It shouldn't require any effort to get started, but should also be scalable and not hide any of the magic.</p>
Auto Deploy does this. Auto Deploy adds a single button to your project, that when clicked, will create a merge request with a template that will automatically deploy your application using Docker to your container scheduler. The cool thing about this is that this immediately leverages Review Apps, meaning you can see it working before even merging the merge request!</p>
</p>
This is as close as you can get to one-click deploys, while exposing what is happening and having all this version-controlled, ready to collaborate and iterate on.</p>
See 1:42</a> in the video for a quick demo of Auto Deploy, as it is available in GitLab 8.15.</p>
For this first iteration, we ship Auto Deploy with a template for deploying to an external OpenShift cluster. We use Herokuish</a> and Heroku Buildpacks to package your application into a Docker Image that then is deployed to Kubernetes on Openshift. We want to add support for more container schedulers and cloud platforms later (vanilla Kubernetes cluster, Mesos, Docker Swarm). Contributions are very welcome in our template repository</a>.</p>

See the Autodeploy documentation</a> for more information.</p> </blockquote>
Web Terminal</h2>
Working together with your container scheduler, GitLab happily spins up several (dynamic) environments on request for your projects. Be that for review apps or a staging or production environment. Traditionally, getting direct access to these environments has been a little painful. And that's a shame: it's very useful to quickly try something in a live environment to debug a problem, or just to experiment.</p>
With the web terminal, this has become extremely easy. Just visit the environments page in your project and click on the terminal button. GitLab will SSH into the instance for you and allow you to do anything you would be able to do from your local instance.</p>
</p>
In the demonstration at 5:18</a> we show you give you a quick peek at the web terminal. We can't wait to see how you'll use it to speed up your workflow.</p>

See the administrator</a> and environments</a> documentation on the web terminal</p> </blockquote>
Improved Bitbucket Importer</h2>
Importing from Bitbucket has become even more powerful. With GitLab 8.15 we'll also import all pull requests as individual merge requests plus pull request comments, milestones and the wiki from Bitbucket. That makes the things we import from any Bitbucket project:</p>

Repository description</li>
Git repository</li>
Issues and their comments</li>
Pull Requests and their comments</li>
Milestones</li>
Wiki</li> </ul>
When importing a project all references to pull requests and issues are preserved and so is the access level (public/private).</p>
Read the docs on the Bitbucket importer</a></p>
Global Git Hooks</h2>
If you want to enforce rules and triggers based on Git pushes and their contents, you have been able to use custom Git hooks in GitLab. But if you want to standardize on these rules, you'd have to copy and paste them to every new project.</p>
With Global Git Hooks you can now create Git hooks that will be run for each project on the GitLab instance. This should make it much easier to set up rules that you want all incoming code to comply with.</p>
Create the hooks in `hooks/<hook_name>.d/</code> directory or tell GitLab Shell where the directories are.</p>`
`See the documentation on Custom Hooks</a></p>`
Chained Custom Git Hooks</h2> If you have set up custom Git hooks, the order might matter: when an initial hook fails, there is no point in moving forward. With Chained Custom Hooks hooks will execute in lexical order, failing on the first failing script.</p> This means you can create hooks 1-hook.sh</code> and 2-hook.sh</code> and you'll know that 1</code> will execute before 2</code>.</p> This gives a lot of power to your hooks and allows endless customization of what happens when a commit is about to land in your GitLab project.</p> For more information, see the custom git hooks documentation</a>.</p> Thanks to both Elan Ruusamäe and Dirk Hörner for both helping to define Global Git Hooks and this feature, and providing the implementation!</p> LDAP Group membership overrides (EE)</h2> In GitLab EE, you can sync any LDAP group with any GitLab group and give everyone automatically a certain permission. For instance, you can give everyone in the LDAP group developers</code> the Developer</code> permission level. New developers just have to be added to the LDAP group and GitLab will take care of giving them access automatically.</p> With GitLab 8.15, this has become even more powerful. In addition to the automatically synced permissions, you can now override this permission per user. This should make it easier to manage complex permissions across groups and projects.</p> </p> Slack Chatops</h2> After bringing Chatops to GitLab with our Mattermost integration</a>, we're now doing the same for everyone using Slack! This means you can create, show and search for issues straight from Slack. Super convenient to bridge that gap from a casual conversation to an actual issue.</p> In addition, you can actually deploy from and to any environment. For instance, you can do</p> /awesome-website deploy from staging to production </code></pre> And GitLab will deploy the latest commit from staging onto master.</p> </p> Configure Chatops for Slack in your project services. As always, we're looking forward to see contributions to help expand the power of chat integration with GitLab!</p> One-click Mattermost configuration</h2> Setting up the awesome Mattermost integration</a> with GitLab has been made much easier. It's a matter of a single click now, as you can see in the video at 3:16</a>.</p> </p> The Mattermost and Slack integrations allow you to do the same things: create, show and search for issues and deploy to any environment.</p> Read the docs on the Mattermost Chatops integration</a></p> </blockquote> Diff in Notification Emails</h2> When you get a notification email from a comment on a diff, GitLab will now send along a bit of the diff, so you have the correct context immediately available.</p> </p> Interface improvements</h2> Our amazing usability team has been working hard on making GitLab easier to use, enhancing GitLab's personality and improving readability. This release contains various changes that will make using GitLab more enjoyable!</p> Fresh typefaces!</h3> To improve readability and cross-OS/browser support in GitLab, we have changed to using system fonts. These fonts are optimized for your platform and should therefore provide a better experience, independent of where you're viewing GitLab from.</p> If you want to get a feel of GitLab across platforms, check out the original merge request</a>.</p> Slimmed down widths</h3> We've reduced the max-width for issues and merge requests container in order to provide a more readable line length. This is the first step for us to correct the huge line lengths you see throughout GitLab. Follow our meta issue</a> as we continue to improve GitLab's line length.</p> Unique Labels</h3> We've given labels a unique look in order to differentiate them from buttons. We are continuing work on this to make our labels</a> and status badges</a> even more consistent in further iterations.</p> </p> Improved Build Scrolling and Loading</h3> Build scrolling and loading works and looks quite a bit better now:</p> </p> Smaller page size</h3> Between system fonts and improvements to autocomplete, we've reduced the average page size of any page in GitLab significantly. A given merge request in the GitLab CE project went from 1800kb to now 718kb!</p> Improved empty states</h3> In order to improve our experience for users who are just getting started with GitLab, we've added informative and fun empty states to many of our pages across the application! View our meta issue</a> to see where we've placed new empty states and feel free to suggest new ones!</p> </p> Other changes and tweaks</h3> Improved accessibility by adding a focus state to dropdown options</li> Added hover states to our primary navigation and tabs throughout the site.</li> Improved hover, focus, and active states for buttons !7797</a></li> Added hover states to collapsed items with the issues/mr's sidebar !7777</a></li> </ul> Mathematics support for Markdown and AsciiDoc, using KaTeX</h2> Comments and repository files can now contain beautifully-typeset mathematics, using the KaTeX</a> library from Khan Academy.</p> To render inline mathematics, use dollar signs around inline code: $`a^2+b^2=c^2`$</code></p> To render multiline mathematics, use the math</code> language for the code block:</p> ```math a^2+b^2=c^2 ``` </code></pre> In addition to working for Markdown, this is also available for AsciiDoc documents. Read the documentation on mathematics support.</a></p> </p> Thanks to Michael Munch for this feature!</p> Cleaner merge commit messages</h2> Previously, merge commit messages included the title and description of the merge request, and a reference to the merge request. This didn't read well when using git log</code> and similar tools, because merge request descriptions often contain requests for review, screenshots, and other details incidental to the code change.</p> Now, the default merge commit message is in the following format:</p> Merge branch '$SOURCE_BRANCH' into '$TARGET_BRANCH' $TITLE Closes $CLOSING_ISSUE_REFERENCES # only present if the MR closes issues See merge request $MERGE_REQUEST_REFERENCE </code></pre> The previous default message is available as an option when customizing the merge commit message.</p> Thanks to Gabriel Gizotti!</p> Shorthand cross-project references in GitLab Flavored Markdown</h2> Previously, a reference to something in another project always included the namespace, even if the project was in the same namespace.</p> Now, shorthand references are available. So from within the gitlab-org/gitlab-ce</code> project, you can refer to issue #1 in GitLab Workhorse by writing gitlab-workhorse#1</code> instead of gitlab-org/gitlab-workhorse#1</code>, saving precious keystrokes!</p> For more information, see the special GitLab references</a> section of our Markdown documentation.</p> Thanks to Oswaldo Ferreira!</p> Create an issue with unresolved discussion from a merge request</h2> In 8.14, we added the ability to block a merge when there are unresolved discussions</a>.</p> Now, we have added an option to create a new issue from the unresolved discussions in a merge request</a>, and resolve those discussions at the same time! This is perfect for those cases where you need to merge something now, but don't want to forget about the code review comments.</p> Thanks to Bob van Landuyt!</p> Manual Actions from the Pipeline Graph</h2> Manual actions allow you to require manual interaction before moving forward with a particular job in CI. Your entire pipeline can run automatically, but the actual deploy to production will require a click.</p> You can do this straight from the pipeline graph. Just click on the play button to execute that particular job.</p> </p> User Activities API</h2> To quickly get an idea of when a user last interacted with GitLab, we've added a special admin-only API to GitLab that allows you to get the last activity timestamp of every user on the instance.</p> Find the details in the docs</a></p> Sort Project and Group members</h2> You can now find people in projects and groups more easily by sorting them by name, access level and date of joining.</p> </p> API Changes</h2> Every month we make many additions to our API. Here are the highlights for GitLab 8.15:</p> Allow some Project API GET endpoints to be requested anonymously</li> Allow Repositories & Files API GET endpoints to be requested anonymously</li> Allow some Tag API GET endpoints to be requested anonymously</li> Add scopes for personal access tokens and OAuth tokens</li> Add ability to cherry pick a commit (community contribution)</li> Add ability to unshare a project from a group (community contribution)</li> Add ability to set should_remove_source_branch</code> on merge requests (community contribution)</li> Add simple representation of group's projects (community contribution)</li> Expose committer details for commits (community contribution)</li> Expose merge status for branch API (community contribution)</li> Expose personal snippets as /snippets (community contribution)</li> Expose pipeline coverage</li> </ul> Omnibus GitLab package changes</h2> PostgreSQL version upgrade</h3> Starting last month with GitLab 8.14 omnibus-gitlab package, we are providing a way to upgrade the PostgreSQL database version.</p> The current version of PostgreSQL we are packaging (9.2.18) is slowly approaching its EOL. Due to the PostgreSQL versioning policy</a>, upgrades between major releases require downtime and the use of the pg_upgrade</code> tool.</p> For this purpose, we are packaging the newest available PostgreSQL version (9.6.1). We are also introducing gitlab-ctl pg-upgrade</code> tool which should make this transition as painless as possible. When upgrading to GitLab 8.15, this action will not be run automatically</em>. This will allow you to plan the database upgrade downtime.</p> After version 9.0 is released, we plan on setting the PostgreSQL version 9.6 as default so please make sure that you plan your upgrade before that release. We're expecting to ship GitLab 9.0 on or after February 22nd.</p> Read more about database upgrade in our docs</a></p> </blockquote> Ran into issues? Create an issue at the omnibus-gitlab issue tracker</a>, and reference it in the upgrade problems meta issue.</a></p> </blockquote> Performance Improvements</h2> GitLab CE:</p> Retrieving commit counts has been improved for certain cases: !7668</a></li> Polling intervals have been adjusted to reduce system load: !7762</a></li> Refreshing authorized projects is done in a smarter way to reduce database load: !7956</a></li> The most recent commit ID for a path is now cached: !8098</a></li> </ul> GitLab EE:</p> GitLab EE now ships with a command called sidekiq-cluster</code>. This command can be used to start extra Sidekiq workers that process only a limited number of queues. This feature can be used to process queues that receive a lot of jobs, without it affecting other parts of Sidekiq. This was added in 922</a>.</p> This command is not yet used by Omnibus, our goal is to add this in 8.16.</p> GitLab Runner 1.9</h2> We are also releasing GitLab Runner 1.9 today. Some highlights:</p> Add a retry mechanism to prevent failed clones in builds !399</a></li> Add Kubernete Node Selector !328</a></li> Push prebuilt images to dockerhub !420</a></li> Use prebuilt containers with Kubernetes executor !425</a></li> Add path and share cache settings for S3 cache !423</a></li> Split prepare stage to be: prepare, git_clone, restore_cache, download_artifacts !406</a></li> Introduce docker.Client timeouts !411</a></li> Allow network-sourced variables to specify that they should be files !413</a></li> Fix docker hanging for docker-engine 1.12.4 !415</a></li> Add pprof HTTP endpoints to metrics server !398</a></li> Add a multiple prometheus metrics: !401</a></li> </ul> To see the full list of all changes please read the Runner's CHANGELOG file</a>.</p> GitLab Mattermost 3.5.1</h2> GitLab 8.15 includes Mattermost 3.5.1</a>, an open source Slack-alternative providing workplace messaging for web, PC and phone with archiving and search. Improvements this month include new Xen Orchestra and Homebrew integrations, plus upgraded Desktop Apps for Windows, Mac and Linux</a>.</p> This version includes security updates</a> and upgrade from earlier versions is recommended.</p> Mattermost 3.5.1 was included in GitLab 8.14.1, so anyone on GitLab 8.14.1 or later should have the patch already.</p> Other changes</h2> This release has more improvements. Please check out the changelog</a> to see all the named changes.</p> Upgrade barometer</h2> To upgrade to GitLab 8.15, downtime is required. Larger instances (>1000 users) should expect about 15 minutes of downtime.</p> The specific migrations requiring downtime are described below.</p> Columns with default values are added, this process may take some time depending on the number of rows in these tables</li> Some indexes are added concurrently, which does not require downtime but may take some time to complete</li> The environments table is cleaned up, and a new column is added with a generated default value (this could take some time depending on the number of environments)</li> </ul> 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>

How to Keep Remote (Volunteer) Teams Engaged

2016-12-21T00:00:00+00:00

We love hearing when people outside of GitLab read our Handbook</a> – it's totally public, after all, and it's pretty comprehensive (or a behemoth, depending on your frame of mind). It was even more exciting to hear from James Telfer, of UK Students for the Exploration and Development of Space</a> (UKSEDS) that he read the handbook and had further questions that we'd left unanswered. In particular – what to do when you have neither carrot nor stick when managing remote volunteers?</p>

UKSEDS, a student-run charity that operates around the UK, offering career advice and skills support to students interested in the space industry, borrowed a lot from our handbook when making their constitution.</p>

The internal engagement problem grew after UKSEDS experienced a growth surge and a structural change earlier this year. Specifically, James said:</p>

Project teams are interacting okay with their direct managers but interaction with the wider organization is little to none. While this doesn't directly impact work, we're concerned about the longer-term impact on volunteer enjoyment and retention, both of which are really important to us.</em></p> </blockquote>
Eliran Mesika, our Director of Strategic Partnerships, agreed to jump on the phone with James to learn more about UKSEDS' particular case and the challenges they faced.</p>
Here are some highlights:</p>

Having individual responsibilities somewhere public (even internally) is a useful accountability tool, and helps direct team members to the correct person when they have a question.</li>
Functional group updates presented to the whole company make teams talk more, which results in more organic collaboration.</li>
Keeping communication on a specific topic within the right issue is essential for keeping everyone on the same page – especially when working asynchronously.</li> </ul>
Read on for Eliran's tips.</p>
James:</strong> Our work involves hosting skills workshops and conducting outreach, which means traveling to schools and science fairs to tell kids that space is great and they should get involved. We recently restructured by creating a small executive group that meets every week, and allowing volunteer teams to grow larger and meet less frequently. We found that destroyed our ability to connect with the teams and we've started losing people; we've got quite a high attrition rate, which is normal for a charity. But I wondered how you approached this problem? Some of those things like the random Hangouts and the 1:1 chats work great as long as you can pay people for their work time. But with volunteers it's a different problem entirely.</p>
Eliran:</strong> I'm actually working with Drupal, and I think your problem is more similar to an open source project, or an open source community behind a project. There is a major difference between volunteers and people who are being paid. Once you're paying someone, you have their attention. Perhaps learning what open source projects do to engage their contributors may be helpful in your case. For now, I can share a bit about what we're doing to keep people engaged and connected to the mission.</p>
We're an open core product, and since its inception the whole behavior and culture of the company has also been open. This extends to everything the company does: from the very technical details of a new feature that is being repaired or created, all the way to our high priorities and strategy, and the actual procedures the company follows, is documented and publicly shared. It is shared within the whole company, and is available all the time.</p>
James:</strong> How does that culture extend to individual responsibilities?</p>
Eliran:</strong> Expectations and responsibilities are also public. I handle strategic partnerships, and it's pretty much just me doing this, but I can look at what anyone on our whole team is working on, without even having to ask them directly. On our team page, we have everyone's job description linked, along with any specific responsibilities. So if you have frontend developers, maybe one is responsible for the website, and others are responsible for a particular set of features of the community edition, for example. You can understand at a glance who the right person is for what you're interested in, and you can go into any repo and see what they're working on. For the most part when we're talking about procedures, we have the Handbook which describes everything about the administration and culture of the company. It goes into detail even about how to write a shared document that you work on. It also talks about what we do on a regular basis.</p>
James:</strong> Can you elaborate a bit on those routine things, like the daily calls?</p>
Eliran:</strong> Our daily calls have worked really well for us. They're optional, but we usually get maybe two-thirds of the company joining each day. We have functional updates, where we've divided teams into the various days of the week, and they give an update on what they've completed over the past few weeks, which gives the whole company insight into what the marketing team is doing, what the CI team is doing, and what they're working on next. It really connects you with the whole scope, rather than just seeing your team's goals and your individual goals in a vacuum.</p>
James:</strong> So that's using what other people are doing to remind an individual person or team that the greater company exists – it's not so much that they'd be interested in the technical details, but it reminds them they're part of something bigger? Is that the key there?</p>
Eliran:</strong> Yeah I think it's very important to give people insight into what other teams are doing, because it's remote. That's really key. Otherwise, it seems like when people are working remotely it's very easy to feel isolated. Having those functional updates forces you out of isolation and connects you with the bigger goal. And on a personal level, it connects you with other people's work. As you said, even if you're not a technical person, you'll still get a high-level understanding of the product or what the objective was. That's great for creating a more cohesive environment, and it's remained the same since I joined.</p>

It's very important to give people insight into what other teams are doing – having funtional updates forces you out of isolation and connects you with the bigger goal</p> </blockquote>
We also have a second part of the call where people share what they did last weekend. So once a week you have an opportunity to talk about your personal life, we rotate so everyone shares their experiences. I think that's a very powerful tool to connect on a social level, even if you're not talking with people on a regular basis. Typically you're working with a team of 5-10 people, and you'll be part of a group that's maybe 30 people. So at best you'll know 30 people, and you won't talk to them on a regular basis. You know the regular few people that you talk to, and I think that's very narrow if you're part of a bigger group. But the way that we do these individual stories helps make everyone feel closer.</p>
James</strong>: I can see one definite scope for improvement for us, because we haven't been very good at pulling the teams together. They're sort of sandboxed at the moment.</p>
Eliran;</strong> I think you'll notice that once teams start talking about what they're doing, obviously all teams have touch points that they've been speaking with others about, but you'll have more organic collaboration. Just by talking about what they're thinking about doing, or trying to do. That's the best case scenario. At the most basic level, you'll get people to be aware of what's going on.</p>
We also have a second type of meeting, which is an open meeting focused on a certain department or area. We have a kick-off meeting for a product, or for example we have a monthly release cycle, and anyone can come to those meetings to learn more about what's going on. Our marketing team also has those meetings for example, to talk about new efforts and past performance.</p>
James:</strong> How else do people reach out to work together?</p>
Eliran:</strong> We use Slack for communication, and I'm not sure how that would work in an environment like yours, without volunteers dedicating a certain amount of time every day. But we have channels for everything, and the whole team is distributed across channels. We have #general, which is the channel Emily used to ask "Hey is there anyone relevant who'd like to help James and talk about remote work at his organization?" We also have a #questions channel, where anyone can ask anything from the most sophisticated to the stupidest. They just throw their question to the channel and people try to help them or steer them in the right direction for who to talk to. Another channel that's really important is the #thanks channel, and I feel that's an important part to offer gratitude to someone for helping you, and also receive that when you've helped someone. Because of the remote environment it's very powerful. Because GitLab's culture is built on asynchronous work – people in different time zones – you're not on Slack all the time because others will pick up your question whenever they become available.</p>
One other thing that's working well is centralizing a process for working asynchronously. So, we try to make all the work and communication and discussion on GitLab by using issues. Someone will create an issue with a particular task or mission, and then the whole communication is available there. So people have access to information or decisions or a process on a specific area. Even if you're not involved, you can comment and say, "Hey I'd like to suggest a, b, c." So by virtue of being in different time zones, we were forced to use asynchronous methods of work, and issues work very well for that. Having the discussion tools integrated into that, and using it to keep everything in one work space dedicated to a specific topic, is great for remote teams. If you can't always set a time for everyone to sit down together, using issues is crucial to making work happen.</p>
James:</strong> We do use Slack, because, as you may recall as a student you may as well be in different time zones, waking up at 9 am one day and 1 pm the next. Are there decisions made on Slack, or do you tell people, "No this is a discussion, take it to x issue"?</p>
Eliran:</strong> We may have those specific discussions on Slack, but for the most part, maybe 95% of the decisions are happening within the issue. But we don't discourage people from talking, so there could be times when you have to talk to someone or a group of people, because there's only so much you can do over text. So you may make a decision over Hangout, but that is communicated back through the issue. Someone will go back and say "I had a discussion with Mark, and we decided the best way to move forward is x." That way everyone has the opportunity to get the takeaways from that meeting and give input. So some decisions happen away from the issues. But it's important to reinforce that we try to keep communication on a specific topic within an issue. We really push that, and it's part of the culture at GitLab. As you keep growing, the sooner you adopt changes in a working culture, the better it is for people to learn them later on.</p>
Read more about how we stay connected as a remote company</a>.</p>
Tweet us @GitLab</a> and check out our job openings</a>.</em></p>

A creative agency's GitLab wishlist

2016-12-15T00:00:00+00:00

Wouter van Kuipers</a> is an engineer at Lukkien</a>, a creative agency that produces online media, photography, film, apps, CGI, and graphic design. His team currently works on a platform aimed at parents and healthcare professionals. They've used a combination of Jenkins and GitLab, although they are switching to GitLab CI for testing. He told me his team tends to use the collaboration tools of GitLab the most. Before GitLab, they used SVN, and ultimately decided on GitLab instead of a competitor because they needed to host on-premises for security reasons. Our service engineer Lee Matos</a> sat down with Wouter to learn about how GitLab can help.</p>

Here are some items discussed below and requested by the Lukkien team:</p>

A view that will let you see changes over builds, and how builds are affected over time.</li>

Notifications around CI builds, so if there are any related tickets, those get updated as well.</li>

Versioning for Photoshop and InDesign files.</li> </ul>
Wouter:</strong> We struggle as a team and company to find a good versioning system for our (UX) designs. Right now we create separate folders and label the versions of our InDesign and Photoshop files. We want to know the latest version, but also want to have a clear visual representation of the changes between versions. Is there any planning for tooling like that in GitLab in the (near) feature?</p>
Lee:</strong> Frankly, this is on our dream feature list. I think everybody on our team wants to be able to version Photoshop and InDesign documents, but we don’t have a good solution for those files right now that's going to work smoothly. It looks like Adobe is getting into the versioning space for files like these, so there’s a silver lining here in that once Adobe solves that problem, we’ll probably do something similar quickly thereafter.</p>
Wouter:</strong> My next question is that we are hosting GitLab using a Docker setup, this works quite well but we are not sure if this will create limitations in the long run, for example if we want to use Mattermost in the future? My team has 8-10 developers, but we use the setup for all our teams, we’re all in the same GitLab instance. So that’s 100-120 developers.</p>
Lee:</strong> That's what I would call GitLab Small/Medium-sized. As it stands, we think that will be fine, there are no limitations even with Mattermost and we don’t expect there to be any problems. Obviously if there are, we’ll explore that with you and figure it out. Our product team leads aren't aware of running GitLab in Docker at a big scale (1000+) – most of those clients are running it directly in a VM or Bare Metal. We feel that obviously Docker is the future so we need to find the answer to these questions. If you run into anything, please bring it up in an issue. And the same goes for Docker in Mattermost, we don’t expect anything different.</p>
Wouter:</strong> Finally, in what way does GitLab want to position itself in the long run compared to GitHub?</p>
Lee:</strong> The best way to think about it, for me, is we are actually more like Atlassian. Our end goal is to build what Atlassian ended up with by acquiring the little pieces, by instead building those parts and making them 100 percent cohesive. So it’s more about building an end-to-end development tool that allows your team to work together and converse and go. Our buzz phrase at this point is "From idea to production", so we want to cover everything over that process, and make it faster, whatever you’re using GitLab for. That’s even our goal internally as well, so it excites me because we’re actually using GitLab to build it.</p>
I think GitHub is positioning itself as more of a core component, they see Git and code as the core thing that needs to be solved, and are leaving integrations up to the third parties. We have integrations and we see the value in them, but we want to build something that allows you to start making things work out of the box. Instead of saying "You need to go buy Drone CI, you need to use Waffle.io, and need to wire them all up and read 10 different documentations to figure it out." We want that process to be as easy as possible.</p>
Image "Lightroom Preset Balloon Release"</a> by Lenny K Photography</a> is licensed under CC BY 4.0</a>.</p>
We want you to ask us anything! If you're a user interested in sharing your story on our blog, please fill out this form</a> and we’ll get in touch!</em></p>
Tweet us @GitLab</a> and check out our job openings</a>.</em></p>

GitLab 8.14.5, 8.13.10, and 8.12.13 Released

2016-12-14T19:00:00+00:00

Today we are releasing versions 8.14.5, 8.13.10, and 8.12.13 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p>

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

Please read on for more details.</p>

Security fixes in 8.14.5, 8.13.10 and 8.12.13</h2>

CE/EE:</strong> Fix missing Note access checks in by moving Note#search to updated NoteFinder (#23867</a>)</li>
CE/EE:</strong> Filter `incoming_email_token</code> and runners_token</code> parameters (`#25687</a>)</li> </ul> Security fixes in 8.14.5 and 8.13.10</h2> CE/EE:</strong> Issue#visible_to_user moved to IssuesFinder (#24637</a>)</li> </ul> Other fixes in 8.14.5, 8.12.13 and 8.13.10</h3> CE/EE:</strong> API: Memoize the current_user so that the sudo can work properly. (!8017</a>)</li> </ul> Other fixes in 8.14.5</h3> Omnibus GitLab</strong>: Add attribute client_output_buffer_limit_slave for redis (!1147</a>)</p> </li> CE/EE:</strong> Remove 'Leave Project' and 'Leave Group' from settings dropdowns (!7600</a>)</li> CE/EE:</strong> Fix display hook error message (!7775</a>)</li> CE/EE:</strong> Shows group members in the project members list (!7899</a>)</li> CE/EE:</strong> Correct autocomplete for values with special characters (!7910</a>)</li> CE/EE:</strong> Remove wrong '.builds-feature' class from the MR settings fieldset (!7930</a>)</li> CE/EE:</strong> Avoid escaping relative links in Markdown twice (!7940</a>)</li> CE/EE:</strong> Allow branch names with dots on API endpoint (!7963</a>)</li> CE/EE:</strong> Fixed timeago re-rendering every element (!7969</a>)</li> CE/EE:</strong> Use a single query in Projects::ProjectMembersController to fetch members (!7997</a>)</li> CE/EE:</strong> Displays milestone remaining days only when it's present (!7998</a>)</li> CE/EE:</strong> Fix Crontab typo for PruneOldEventsWorker to run 4x/day instead of 60x/hour (!8051</a>)</li> CE/EE:</strong> Encode when migrating ProcessCommitWorker jobs (!8064</a>)</li> CE/EE:</strong> Updates the docs to require GitLab Shell 4.0.3 (!8050</a>)</p> </li> EE:</strong> Fix milestone total weight is missing on the milestone page (!944</a>)</li> EE:</strong> Remove wrong '.builds-feature' class from the MR settings fieldset (!947</a>)</li> EE:</strong> Group members in project members view (!958</a>)</li> </ul> Upgrade barometer</h2> These versions do include a single migration, and will require brief downtime of typically less than one minute.</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>

Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes

2016-12-14T00:00:00+00:00

Continuous Integration, Continuous Deployment and Continuous Delivery</a> are increasingly popular topics among modern development teams. Together they enable a team to build, test and deploy the code at any commit. The main benefit of these approaches is the ability to release more quality code more frequently through the means of automated pipelines. The tough part is building such pipelines. There is a myriad of tools available which we would need to choose, learn, install, integrate, and maintain.</p>

Recently, I literally fell in love with GitLab</a>! It offers a fully featured ecosystem of tools which enable us to create an automated pipeline in minutes! From source control to issue tracking and CI, we find everything under one roof, fully integrated and ready to use.</p>

In this tutorial, we will create a Spring Boot</a> application built, tested, and deployed with GitLab CI</a> on a Kubernetes</a> cluster. Spring Boot is the leading microservice chassis</a> for Java. It allows a developer to build a production-grade stand-alone application, like a typical CRUD</a> application exposing a RESTful API</a>, with minimal configuration, reducing the learning curve required for using the Spring Framework</a> drastically. Kubernetes is an open-source container orchestrator inspired by Google Borg</a> that schedules, scales and manages containerized applications.</p>

Create a GitLab project</h2>

Let's start by creating a new project</a> in GitLab named actuator-sample</code>. Then we follow the command line instructions displayed in the project's home page to clone the repository on our machine and perform the first commit.</p>

git clone git@gitlab.com:marcolenzo/actuator-sample.git
cd </span>actuator-sample
touch README.md
git add README.md
git commit -m "add README"</span>
git push -u origin master
</code></pre>
Always replace marcolenzo</code> with your own GitLab username whenever copying a snippet of code from this tutorial.</p>

Create a Spring Boot application</h2>

To bootstrap the Spring Boot application we navigate to the Spring Initializr</a> web page and generate a Maven Project</strong> with the pre-selected Spring Boot Version</strong>. Maven</a> is a project management tool commonly used in Java projects to define dependencies and the build lifecycle. We leave com.example</code> as Group</strong> and set actuator-sample</code> as the Artifact</strong> name. We select the Web</code> dependency, which supports full stack web development with Tomcat</a> and Spring MVC</a>, and the Actuator</code> dependency which implements some production-grade features useful for monitoring and managing our application like health-checks and HTTP requests traces.</p>

Finally, we generate the project and a Zip file named actuator-sample.zip</code> will be downloaded to our machine.</p>

</p>

We can now unzip the archive and launch the application immediately. Spring Initializr has already created everything for us. We just need to have a Java JDK</a> 1.7 or later installed on our machine and the JAVA_HOME</code> environment variable set accordingly. OpenJDK</a> is the preferred option for most Linux distributions since it is readily available on their repositories. You can alternatively install Oracle JDK</a> if it is a strict requirement for your team.</p>

### Installing OpenJDK 8 on Debian, Ubuntu, etc.</span>

sudo apt-get install openjdk-8-jre

### Installing OpenJDK 8 on Fedora, Oracle Linux, Red Hat Enteprise, CentOS, etc.</span>

su -c "yum install java-1.8.0-openjdk"</span>

### Setting the JAVA_HOME environment variable</span>

export </span>JAVA_HOME</span>=</span>/path/to/your/java/home # e.g. /usr/lib/jvm/java-8-openjdk-amd64/</span>

### Extracting and launching the application</span>

~/git/actuator-sample$ </span>unzip ~/Downloads/actuator-sample.zip -d ../
~/git/actuator-sample$ </span>./mvnw spring-boot:run

[</span>...]

2016-12-02 22:41:14.376  INFO 10882 --- [</span>           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(</span>s)</span>: 8080 (</span>http)</span>
2016-12-02 22:41:14.420  INFO 10882 --- [</span>           main] com.example.ActuatorSampleApplication    : Started ActuatorSampleApplication in </span>17.924 seconds (</span>JVM running for </span>87.495)</span>
</code></pre>
The application is up and running and we did not write one line of code! Spring Boot is opinionated and auto-configures the application with sane default values and beans. It also scans the classpath for known dependencies and initializes them. In our case, we immediately enjoy all the production-grade services offered by Spring Actuator</a>.</p>

~$ </span>curl http://localhost:8080/health
{</span>"status"</span>:"UP"</span>,"diskSpace"</span>:{</span>"status"</span>:"UP"</span>,"total"</span>:981190307840,"free"</span>:744776503296,"threshold"</span>:10485760}}</span>
</code></pre>
If you wish to learn Spring Boot in greater detail, have a look at their reference documentation</a> and guides</a>.</p>

It is time to commit our changes and push them to origin</code>. To simplify things a bit, we commit directly on master</code> without using feature branches</a> since collaboration is not the focus of this tutorial. Later, we will use environment branches</a> as specified in the GitLab Flow</a> to deploy to different environments selectively, e.g. staging and production. If you are not familiar with the GitLab Flow</a>, I strongly recommend you to read its documentation.</p>

git add --all
git commit -m "Creates actuator-example application"</span>
git push origin master
</code></pre>
Creating a Continuous Delivery pipeline with GitLab CI</h2>

While our code is now safe on GitLab, we still need to automate its integration and deployment. We need to verify each commit with an automated build and set of tests in order to discover issues as early as possible and, if the build is successful, deploy to a target environment. A few years ago, our only option was to install, configure and maintain a CI Server like Jenkins</a> and possibly automate our deployment with a set of bash scripts. While the number of options has grown significantly, whether hosted or on the cloud, we still need to find a way to integrate our source control system with the CI Server of our choice.</p>

Not anymore though! GitLab has fully integrated CI and CD Pipelines in its offering, allowing us to build, test and deploy</a> our code with ease.</p>

For the purpose of this tutorial we will deploy to the Google Cloud Container Engine</a> which is a cluster management and orchestration system built on the open source Kubernetes</a>. Kubernetes is supported by all main cloud providers and can be easily installed on any Linux server</a> in minutes. That said, we will be able to re-use this configuration virtually on any environment running Kubernetes.</p>

Before we can proceed to the creation of the pipeline, we need to add a couple of files to our repository to package our application as a Docker container and to describe the target deployment in Kubernetes terms.</p>

Packaging a Spring Boot application as a Docker container</h3>

Let's start by creating the Dockerfile</code> in the root directory of our project.</p>

FROM openjdk:8u111-jdk-alpine
VOLUME /tmp
ADD /target/actuator-sample-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT [</span>"java"</span>,"-Djava.security.egd=file:/dev/./urandom"</span>,"-jar"</span>,"/app.jar"</span>]</span>
</code></pre>
The FROM</code> keyword defines the base Docker image of our container. We chose OpenJDK</a> installed on Alpine Linux</a> which is a lightweight Linux distribution. The VOLUME</code> instruction creates a mount point with the specified name and marks it as holding externally mounted volumes from the native host or other containers. ADD</code> copies the executable JAR generated during the build to the container root directory. Finally ENTRYPOINT</code> defines the command to execute when the container is started. Since Spring Boot produces an executable JAR with embedded Tomcat, the command to execute is simply java -jar app.jar</code>. The additiona flag java.security.edg=file:/dev/./urandom</code> is used to speed up the application start-up and avoid possible freezes. By default, Java uses /dev/random</code> to seed its SecureRandom</code> class which is known to block if its entropy pool is empty.</p>

Time to commit.</p>

git add Dockerfile
git commit -m "Adds Dockerfile"</span>
git push origin master
</code></pre>
Define the Kubernetes Deployment</h3>

Let's create a file named deployment.yml</code> in the root directory of our project.</p>

apiVersion</span>:</span> extensions/v1beta1</span>
kind</span>:</span> Deployment</span>
metadata</span>:</span>
  name</span>:</span> actuator-sample</span>
spec</span>:</span>
  replicas</span>:</span> 2</span>
  template</span>:</span>
    metadata</span>:</span>
      labels</span>:</span>
        app</span>:</span> actuator-sample</span>
    spec</span>:</span>
      containers</span>:</span>
      -</span> name</span>:</span> actuator-sample</span>
        image</span>:</span> registry.gitlab.com/marcolenzo/actuator-sample</span>
        imagePullPolicy</span>:</span> Always</span>
        ports</span>:</span>
        -</span> containerPort</span>:</span> 8080</span>
      imagePullSecrets</span>:</span>
        -</span> name</span>:</span> registry.gitlab.com</span>
</code></pre>
This is the definition of a Kubernetes Deployment</code></a> named actuator-sample</code>. The replicas</code> element defines the target number of Pods</code></a>. Kubernetes performs automated binpacking and self-healing of the system to comply with the deployment specifications while achieving optimal utilization of compute resources. A Pod can be composed of multiple containers. In this scenario, we only include the actuator-sample</code> image stored on our private GitLab Container Registry</a>. For this reason, we need to set an entry under the imagePullSecrets</code> which is used to authenticate to the GitLab Container Registry.</p>

For a detailed explanation of Kubernetes resources and concepts refer to the official documentation</a>.</p>

Time to commit again and we are ready to define our GitLab CI pipeline.</p>

git add deployment.yml
git commit -m "Adds Kubernetes Deployment definition"</span>
git push origin master
</code></pre>
Creating the GitLab CI pipeline</h3>

In order to make use of GitLab CI</a> we need to add the .gitlab-ci.yml</code></a> configuration file to the root directory of our repository. This file is used by GitLab Runners</a> to manage our project's builds and deployments. Therein we can define an unlimited number of Jobs</a> and their role in the whole build lifecycle.</p>

image</span>:</span> docker:latest</span>
services</span>:</span>
  -</span> docker:dind</span>

variables</span>:</span>
  DOCKER_DRIVER</span>:</span> overlay</span>
  SPRING_PROFILES_ACTIVE</span>:</span> gitlab-ci</span>

stages</span>:</span>
  -</span> build</span>
  -</span> package</span>
  -</span> deploy</span>

maven-build</span>:</span>
  image</span>:</span> maven:3-jdk-8</span>
  stage</span>:</span> build</span>
  script</span>:</span> "</span>mvn</span> </span>package</span> </span>-B"</span>
  artifacts</span>:</span>
    paths</span>:</span>
      -</span> target/*.jar</span>

docker-build</span>:</span>
  stage</span>:</span> package</span>
  script</span>:</span>
  -</span> docker build -t registry.gitlab.com/marcolenzo/actuator-sample .</span>
  -</span> docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com</span>
  -</span> docker push registry.gitlab.com/marcolenzo/actuator-sample</span>

k8s-deploy</span>:</span>
  image</span>:</span> google/cloud-sdk</span>
  stage</span>:</span> deploy</span>
  script</span>:</span>
  -</span> echo "$GOOGLE_KEY" > key.json</span>
  -</span> gcloud auth activate-service-account --key-file key.json</span>
  -</span> gcloud config set compute/zone europe-west1-c</span>
  -</span> gcloud config set project actuator-sample</span>
  -</span> gcloud config set container/use_client_certificate True</span>
  -</span> gcloud container clusters get-credentials actuator-sample</span>
  -</span> kubectl delete secret registry.gitlab.com</span>
  -</span> kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com</span>
  -</span> kubectl apply -f deployment.yml</span> 
</code></pre>
Let's break the file in pieces to understand what is going on.</p>

Image and Services</h4>

image</span>:</span> docker:latest</span>
services</span>:</span>
  -</span> docker:dind</span>
</code></pre>
The GitLab Runner</a> can use Docker images</a> to support our pipelines. The image</code> element</a> defines the name of the Docker image we want to use. Valid images are those hosted in the local Docker Engine or on Docker Hub</a>. The services</code> element defines additional Docker images which are linked to the main container. In our case the main container is a plain Docker image while the linked container is enabled for running Docker in Docker.</p>

Variables</h4>

variables</span>:</span>
  DOCKER_DRIVER</span>:</span> overlay</span>
  SPRING_PROFILES_ACTIVE</span>:</span> gitlab-ci</span>
</code></pre>
This is the definition of variables</code></a> to be set on our build environment. The DOCKER_DRIVER</code> signals the Docker Engine which storage driver to use. We use overlay</code> for performance reasons</a>. The SPRING_PROFILES_ACTIVE</code> is very useful when dealing with Spring Boot applications. It activates Spring Profiles</a>, which provide a way to segregate parts of our application configuration and make it available only in certain environments. For instance, we can define different database URIs per environment, e.g. localhost</code> when running on the developer machine and mongo</code> when running within GitLab CI.</p>

Stages</h4>

stages</span>:</span>
  -</span> build</span>
  -</span> package</span>
  -</span> deploy</span>
</code></pre>
The stages</code> element</a> defines the lifecycle of our build. We associate each job</a> with one stage. All jobs within a stage are run in parallel and stages are triggered sequentially in the order we define them, i.e. the next stage is initiated only when the previous one is complete.</p>

The maven-build</code> job</h4>

maven-build</span>:</span>
  image</span>:</span> maven:3-jdk-8</span>
  stage</span>:</span> build</span>
  script</span>:</span> "</span>mvn</span> </span>package</span> </span>-B"</span>
  artifacts</span>:</span>
    paths</span>:</span>
      -</span> target/*.jar</span>
</code></pre>
This is a job definition. Jobs can have any name except keywords. Have a look at the .gitlab-ci.yml</code> documentation</a> for the complete list of keywords.</p>

The scope of this job is to perform a Maven</a> build. For this reason, we define the maven:3-jdk-8</code> as the Docker image on which this job should execute. This image comes with Maven 3 and the Java JDK 8 pre-installed for us.</p>

We then specify build</code> as the stage</code> of this job. Jobs associated with the same stage run concurrently. This is extremely useful if you need to cross-compile your application. For instance, if we wanted to compile and test our application also on Java JDK 7, we could simply create another job with a different name and use the image maven:3-jdk-7</code>.</p>

maven-test-jdk-7</span>:</span>
  image</span>:</span> maven:3-jdk-7</span>
  stage</span>:</span> build</span>
  script</span>:</span> "</span>mvn</span> </span>package</span> </span>-B"</span>
  artifacts</span>:</span>
    paths</span>:</span>
      -</span> target/*.jar</span>
</code></pre>
As previously said, the maven-test-jdk-7</code> job runs in parallel with the maven-build</code>. Hence, it does not have an impact on the pipeline execution time.</p>

The script</code></a> is a shell command to be executed by the GitLab Runner. The mvn package -B</code> triggers a non-interactive Maven build up to the package</code> phase. This phase is specific to the Maven build lifecycle</a> and it includes also the validate</code>, compile</code> and test</code> phases. That means that our Maven project will be validated, compiled and (unit) tested as well. Tests are to be included in the src/test/java</code> folder. In our specific case, Spring Initializr has already created a unit test which verifies that the application context loads without errors. We are free to add as many unit tests as we like. Finally, the package</code> phase creates the executable JAR.</p>

To persist the executable JAR and share it across jobs, we specify job artifacts</code></a>. These are files or directories that are attached to the build after success and made downloadable from the UI in the Pipelines screen.</p>

</p>

The docker-build</code> job</h4>

docker-build</span>:</span>
  stage</span>:</span> package</span>
  script</span>:</span>
  -</span> docker build -t registry.gitlab.com/marcolenzo/actuator-sample .</span>
  -</span> docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com</span>
  -</span> docker push registry.gitlab.com/marcolenzo/actuator-sample</span>
</code></pre>
The docker-build</code> job packages the application into a Docker container. We define package</code> as the build stage</code> since we need the maven-build</code> job to produce the executable JAR beforehand.</p>

The scripts are a typical sequence of docker</code> commands used to build an image, log in to a private registry and push the image to it. We will be pushing images to the GitLab Container Registry</a>.</p>

The $CI_BUILD_TOKEN</code></a> is a pre-defined variable which is injected by GitLab CI into our build environment automatically. It is used to log in to the GitLab Container Registry.</p>

For a complete list of pre-defined variables, have a look at the variables documentation</a>.</p>

The k8s-deploy</code> job</h4>

This job is responsible for deploying our application to the Google Container Engine</a>. I purposely decided to make use of the Google Cloud SDK</a> (gcloud</code>) because it gives us the possibility to programmatically create and manage Google Container Engine clusters and other products of the Google Cloud ecosystem. In this tutorial, we will simplify things a bit by creating the Google Container Engine cluster beforehand through the GUI.</p>

First, we create a Google Cloud Project named actuator-sample</code>. Take note of the Project ID</code> since it sometimes differs from the project name we specify. Then we create a Google Container Engine cluster named actuator-sample</code> as well. We can choose any machine type and any number of nodes. For the purpose of this tutorial one node and a small machine are sufficient. Let's take note of the zone</code>.</p>

</p>

Finally we need to create a service account which is necessary to perform a non-interactive login with gcloud</code>. Navigate to Google Cloud API Manager</strong> > Credentials</strong> > Create Credentials</strong> and create a JSON key for the Compute Engine default service account</code>.</p>

We can now analyze the configuration.</p>

k8s-deploy</span>:</span>
  image</span>:</span> google/cloud-sdk</span>
  stage</span>:</span> deploy</span>
  script</span>:</span>
  -</span> echo "$GOOGLE_KEY" > key.json</span> # Google Cloud service account key</span>
  -</span> gcloud auth activate-service-account --key-file key.json</span>
  -</span> gcloud config set compute/zone europe-west1-c</span>
  -</span> gcloud config set project actuator-sample</span> 
  -</span> gcloud config set container/use_client_certificate True</span>
  -</span> gcloud container clusters get-credentials actuator-example</span>
  -</span> kubectl delete secret registry.gitlab.com</span>
  -</span> kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com</span>
  -</span> kubectl apply -f deployment.yml</span> 
</code></pre>
We use the google/cloud-sdk</code> image for this process since it comes preloaded with gcloud</code> and all components and dependencies of the Google Cloud SDK including alpha and beta components. We obviously chose deploy</code> as the stage</code> since we want our application to be packaged beforehand and its container pushed to the GitLab Container Registry. Then we execute a set of scripts.</p>

The echo "$GOOGLE_KEY" > key.json</code> script injects the Google Cloud service account key in the container. $GOOGLE_KEY</code> is a Secure Variable having the content of the Google Cloud service account key as its value. Secure Variables</a> are user-defined variables that should not be shown in the .gitlab-ci.yml</code>. They are set per project by navigating to Project</strong> > Variables</strong> > Add Variable</strong> in GitLab.</p>

</p>

The gcloud auth activate-service-account --key-file key.json</code> script performs the non-interactive authentication process. The gcloud config set ...</code> scripts are selecting the target project, zone and cluster. Make sure these values correspond to those you jotted down before. The gcloud container clusters get-credentials actuator-example</code> script downloads the kubectl</code> configuration file. If we wanted to use Kubernetes on another cloud provider or custom installation, we would source the kubectl</code> configuration ~/.kube/config</code> without the need to interact with gcloud</code>.</p>

The kubectl create secret docker-registry ...</code> script creates the imagePullSecret</code> we had defined in the deployment.yml</code>. This is used by Kubernetes to authenticate with our private GitLab Container Registry and download the container images. The kubectl delete secret</code> is necessary because the Kubernetes API is lacking the replace</code> operation for docker-registry</code> secrets. In a real-world scenario, I would suggest handling Kubernetes secrets</a> that can affect multiple pipelines (such as a password for a private Docker registry) in a separate pipeline or through configuration management tools like Ansible</a>, Salt</a>, Puppet</a> or Chef</a>. The reason is that such secrets should be rotated periodically for security reasons and updated in each GitLab project using them. There is also the risk of interference between pipelines because of the kubectl delete</code> command. Note that $REGISTRY_PASSWD</code> is another Secure Variable.</p>

Time to check if everything is in order on our cluster.</p>

$ </span>kubectl get deployments
NAME              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
actuator-sample   2         2         2            2           2m
$ </span>kubectl get pods
NAME                               READY     STATUS    RESTARTS   AGE
actuator-sample-3641958612-3e5xy   1/1       Running   0          2m
actuator-sample-5542343546-fr4gh   1/1       Running   0          2m
</code></pre>
</p>

Deployed!</p>

GitLab Environments</h4>

Before concluding the tutorial, we will learn about GitLab Environments</a> which enable us to track environments and deployments.</p>

Let's refactor the k8s-deploy</code> job and split it in two. One job will target the staging environment and the other production.</p>

k8s-deploy-staging</span>:</span>
  image</span>:</span> google/cloud-sdk</span>
  stage</span>:</span> deploy</span>
  script</span>:</span>
  -</span> echo "$GOOGLE_KEY" > key.json</span>
  -</span> gcloud auth activate-service-account --key-file key.json</span>
  -</span> gcloud config set compute/zone europe-west1-c</span>
  -</span> gcloud config set project actuator-sample</span>
  -</span> gcloud config set container/use_client_certificate True</span>
  -</span> gcloud container clusters get-credentials actuator-example</span>
  -</span> kubectl delete secret registry.gitlab.com</span>
  -</span> kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com</span>
  -</span> kubectl apply -f deployment.yml --namespace=staging</span>
  environment</span>:</span>
    name</span>:</span> staging</span>
    url</span>:</span> https://example.staging.com</span>
  only</span>:</span>
  -</span> master</span>

k8s-deploy-production</span>:</span>
  image</span>:</span> google/cloud-sdk</span>
  stage</span>:</span> deploy</span>
  script</span>:</span>
  -</span> echo "$GOOGLE_KEY" > key.json</span>
  -</span> gcloud auth activate-service-account --key-file key.json</span>
  -</span> gcloud config set compute/zone europe-west1-c</span>
  -</span> gcloud config set project actuator-sample</span>
  -</span> gcloud config set container/use_client_certificate True</span>
  -</span> gcloud container clusters get-credentials actuator-example</span>
  -</span> kubectl delete secret registry.gitlab.com</span>
  -</span> kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com</span>
  -</span> kubectl apply -f deployment.yml --namespace=production</span>
  environment</span>:</span>
    name</span>:</span> production</span>
    url</span>:</span> https://example.production.com</span>
  when</span>:</span> manual</span>
  only</span>:</span>
  -</span> production</span>
</code></pre>
The environment</code> keyword associates the job with a specific environment while the url</code> element is used to generate a handy hyperlink to our application on the GitLab Environments page (found under your project's Pipelines > Environments</code>). The only</code> keyword signals to GitLab CI that the job should be executed only when the pipeline is building the listed branches. Finally, when: manual</code> is used to turn the job execution from automatic to manual. Turning the execution of this job to automatic</code> would project us in the world of Continuous Deployment</a> rather than Continuous Delivery</a>. From a Kubernetes perspective, we are making use of namespaces</code> to segregate the different environments.</p>

By committing on master</code> and production</code> we trigger a pipeline per environment</a>. As mentioned before, we are not making use of any collaboration tool because it is out of the scope of this tutorial. In real-world scenarios, we would use merge requests</a> with Review Apps</a> to move code across branches. Merge requests allow the team to review and discuss the changes before they get merged into the target branch. Review Apps</a> take that one step further by spinning up dynamic environments for our merge requests, offering the team access to a deployed instance of our application without the need of checking out the branch. This is extremely useful not only for non-technical members of the team, but also to collaborators and project managers to preview the changes without having to clone and install the app and its dependencies when evaluating a proposal.</p>

git commit -am "Showcasing Pipelines"</span>
git push origin master
git checkout -b production
git push origin production
</code></pre></p>

The Pipelines screen details all pipeline executions. We can gather information about the branch and the individual result of each stage. In the case of the production</code> pipeline the k8s-deploy-production</code> is not executed automatically as expected but can be triggered from the GUI from where we can also download the build artifacts.</p>

</p>

Environments are listed on a separate page, from which it is possible to redeploy the latest version of an environment or to roll back to a particular version of the environment by accessing the relative details page.</p>

</p>

Conclusion</h2>

In this tutorial, we were able to create a Continuous Delivery</a> pipeline with ease thanks to the suite of GitLab</a> products that supported us at every stage. Spring Boot</a> gave us agility by auto-configuring the application context and offering production-grade services out of the box. Kubernetes</a> abstracted us from the compute resources and orchestration duties allowing us to define only the desired deployment state. GitLab CI</a> was the core engine of our pipeline. Its declarative .gitlab-ci.yml</code></a> file allowed us to define, version and manage our pipelines while the GUI gave us full visibility and control.</p>

While this is a basic example, it clearly shows the immense benefits any team or company can gain by using the unified GUI of GitLab for issues, code review, CI and CD.</p>

About Guest Author</h2>

Marco Lenzo</a> is a Software Architect always up for a challenge. He has expertise in transaction processing and platform as a service (PaaS). Java, Spring, Go and Kubernetes are currently his bread and butter.</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>

MVP+3</h2>

Deployment History</h3>
This is a screenshot cribbed from New Relic, but I could imagine some of this information show up on our deployment history pages.</p>
</p>

Future</h2>

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>

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>

Interface improvements</h2>
Our amazing usability team has been working hard on making GitLab easier to use, enhancing GitLab's personality and improving readability. This release contains various changes that will make using GitLab more enjoyable!</p>

Unique Labels</h3>
We've given labels a unique look in order to differentiate them from buttons. We are continuing work on this to make our labels</a> and status badges</a> even more consistent in further iterations.</p>
</p>

Smaller page size</h3>
Between system fonts and improvements to autocomplete, we've reduced the average page size of any page in GitLab significantly. A given merge request in the GitLab CE project went from 1800kb to now 718kb!</p>

User Activities API</h2>
To quickly get an idea of when a user last interacted with GitLab, we've added a special admin-only API to GitLab that allows you to get the last activity timestamp of every user on the instance.</p>
Find the details in the docs</a></p>

Omnibus GitLab package changes</h2>

Other changes</h2>
This release has more improvements. Please check out the changelog</a> to see all the named changes.</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>
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>

`About Guest Author</h2>Marco Lenzo</a> is a Software Architect always up for a challenge. He has expertise in transaction processing and platform as a service (PaaS). Java, Spring, Go and Kubernetes are currently his bread and butter.</p>`

GitLab

GitLab 8.15.4, 8.14.6, and 8.13.11 Released

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>

Why We Use Personas in Product Development

GitLab 8.15.3 released

Prometheus and GitLab

Behind the scenes: How we built Review Apps

How to prepare for a virtual interview at GitLab

Set Expectations, Manage Better

GitLab 8.15.2 released

We’re bringing GitLab Pages to the Community Edition

GitLab 8.15.1 released

GitLab 8.15 Released with Auto Deploy and Web Terminal

How to Keep Remote (Volunteer) Teams Engaged

A creative agency's GitLab wishlist

GitLab 8.14.5, 8.13.10, and 8.12.13 Released

Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes

GitLab

GitLab 8.15.4, 8.14.6, and 8.13.11 Released

Upgrade barometer</h2> These versions have no migrations and should not require any downtime.</p>

Why We Use Personas in Product Development

MVP+3</h2>

Deployment History</h3> This is a screenshot cribbed from New Relic, but I could imagine some of this information show up on our deployment history pages.</p> </p>

Future</h2>

Monitoring++</h3> Response monitoring (throughput, latency, errors)</li> Resource monitoring (CPU, memory, IO)</li>

Deploy Monitoring</h3> Track status of deploy from start to finish</li> Finer state detail (ready, preparing, waiting, deploying, finished, failed)</li> Aware of rollout across multiple containers/servers</li>

Feature Flags</h3> Decouple deployment from delivery</li> In-code flag to execute one path or another based on externally controllable settings</li> Binary switch</li> Incremental (%) rollout</li>

Q&A</h3> And with that, I’d like to thank you all for listening, and open it up to questions.</p>

How to prepare for a virtual interview at GitLab

Set Expectations, Manage Better

Solution: Set clear expectations</h2> Reviewing work in progress both directly, and indirectly through meetings is a waste of time.</p>

GitLab 8.15.2 released

Upgrade barometer</h2> This version has no migrations and should not require any downtime.</p>

We’re bringing GitLab Pages to the Community Edition

GitLab 8.15.1 released

Upgrade barometer</h2> This version has no migrations and should not require any downtime.</p>

GitLab 8.15 Released with Auto Deploy and Web Terminal

Interface improvements</h2> Our amazing usability team has been working hard on making GitLab easier to use, enhancing GitLab's personality and improving readability. This release contains various changes that will make using GitLab more enjoyable!</p>

Fresh typefaces!</h3> To improve readability and cross-OS/browser support in GitLab, we have changed to using system fonts. These fonts are optimized for your platform and should therefore provide a better experience, independent of where you're viewing GitLab from.</p>

Smaller page size</h3> Between system fonts and improvements to autocomplete, we've reduced the average page size of any page in GitLab significantly. A given merge request in the GitLab CE project went from 1800kb to now 718kb!</p>

Other changes and tweaks</h3> Improved accessibility by adding a focus state to dropdown options</li> Added hover states to our primary navigation and tabs throughout the site.</li>

User Activities API</h2> To quickly get an idea of when a user last interacted with GitLab, we've added a special admin-only API to GitLab that allows you to get the last activity timestamp of every user on the instance.</p>

Sort Project and Group members</h2> You can now find people in projects and groups more easily by sorting them by name, access level and date of joining.</p> </p> API Changes</h2> Every month we make many additions to our API. Here are the highlights for GitLab 8.15:</p>

API Changes</h2> Every month we make many additions to our API. Here are the highlights for GitLab 8.15:</p>

Omnibus GitLab package changes</h2>

PostgreSQL version upgrade</h3> Starting last month with GitLab 8.14 omnibus-gitlab package, we are providing a way to upgrade the PostgreSQL database version.</p>

How to Keep Remote (Volunteer) Teams Engaged

A creative agency's GitLab wishlist

GitLab 8.14.5, 8.13.10, and 8.12.13 Released

Upgrade barometer</h2> These versions do include a single migration, and will require brief downtime of typically less than one minute.</p>

Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes

Deployment History</h3>
This is a screenshot cribbed from New Relic, but I could imagine some of this information show up on our deployment history pages.</p>
</p>

Interface improvements</h2>
Our amazing usability team has been working hard on making GitLab easier to use, enhancing GitLab's personality and improving readability. This release contains various changes that will make using GitLab more enjoyable!</p>

Smaller page size</h3>
Between system fonts and improvements to autocomplete, we've reduced the average page size of any page in GitLab significantly. A given merge request in the GitLab CE project went from 1800kb to now 718kb!</p>

User Activities API</h2>
To quickly get an idea of when a user last interacted with GitLab, we've added a special admin-only API to GitLab that allows you to get the last activity timestamp of every user on the instance.</p>
Find the details in the docs</a></p>