GitLab

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 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 is a charity run by students that operates around the UK offering career advice and skills support to students interested in the space industry and borrowed a lot from our handbook when making their constitution.</p>

The internal engagement problem was exacerbated 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 it 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> For some background, 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. Because everyone is volunteering, and there is a major difference to be taken into account between volunteers and people who are being paid. Once you're paying someone, you have their attention. You still have to think about keeping them productive, but you already have their time which is the most important asset. 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 that the company does. Everything 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 that's doing this, but I can look at what anyone on our whole team is working on, without even having to ask them directly, which would be the usual scenario I think. 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. So 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 in detail 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, you don't have to join, but we usually get maybe two-thirds of the company joining each day. You also have to take into account the fact that, because it's a set time maybe some people can't come because it's night for them or too early, but for the most part people join. Those calls are two-fold. One thing, which I think relates to what you're trying to achieve, is that we have functional updates. 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. So that 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. That helps I think to orient everyone to what the company is doing as a whole, and how it's moving forward.</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. When I joined there were about 70 employees, and it's still the same culture and process. We also have a second part of the call where people shared 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 social tool to also connect on a social level, even if you're not talking with people on a regular basis.</p>

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 like 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 start noticing 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>

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 safely build, test and deploy the code virtually at any commit. The main benefit of these approaches is the ability to release more frequently quality code through 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 drastically the learning curve required for using the Spring Framework</a>. 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 enjoy immediately 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 selectively deploy to different environments, 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> to 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, login 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 in our build environment automatically. It is used to login 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 is sufficient one node and a small machine. 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 that our application is packaged beforehand and its container and 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 as value the content of the Google Cloud service account key. 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> scripts 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 of interacting 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 to handle Kubernetes secrets</a> that can affect multiple pipelines, like the 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 previously said, 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 in a separate page, from which it is possible to redeploy the latest version of an environment or to rollback 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 shows clearly 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>

GitLab

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

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>