GitLab

“Pick Your Brain” Interview with CEO Sid Sijbrandij

2017-06-02T00:00:00+00:00

I sat down for a “pick your brain</a>” meeting with GitLab’s CEO and Co-founder, Sid Sijbrandij</a>, to learn about his approach towards different aspects of building a successful startup. Here are some highlights of the conversation.</p>

Brandon: When you were an earlier company around your seed stage, what were your most effective growth strategies?</strong></p>

Sid:</strong> GitLab got started as a Show HN of GitLab.com</a>. We’ve always tried to see where our users were and talk with them there.</p>

When you find people who have a need for your product, you start by trying to bring it to their attention. Then you enter a phase where they care about your product, and they start asking you for more — that’s easy, that’s the honeymoon phase. Now we’re getting to the phase where people think of GitLab as a given, and that it should be perfect, so they tell you the things that could be better.</p>

Brandon: How do you think about product strategy with respect to building new features versus improving or increasing adoption of existing features?</strong></p>

Sid:</strong> It’s kind of a pendulum that swings back and forth. We focused a lot on new features for a while to accomplish our idea to production vision</a>, and now this quarter we’re focusing</a> on increasing adoption of existing features. Mostly this is necessary for newer features, but that’s not the same as increasing the features’ scope, it’s more a question of how we can increase adoption for the features we already have, and seeing which functions are missing. When we release features and have the suspicion few people are using them, we evaluate to make sure those features are things that people can really use. Most recently in 9.2</a> we added the framework to translate GitLab into any language, and allowed users to specify multiple assignees to better track shared ownership of an issue. In 2017</a>, we’ll continue to ship features tailored for enterprise development teams, and make it easier to build, deploy, and monitor applications within GitLab.</p>

</iframe> </figure>
Brandon: How do you balance building visionary features that people aren’t necessarily asking for vs. building in direct response to customer requests?</strong></p>
Sid:</strong> We do both. We started off doing just version control and code review, and now GitLab delivers the entire DevOps pipeline, everything from chatting about an idea and planning it, to getting it out in production and monitoring. We envision enabling everyone to collaborate on digital content, so they can work together and achieve better results. No one asked for that — it’s something we did, it’s the future of the company now. We’d have been in a bad spot if we hadn’t done that.</p>
At the same time, don’t lose track of what your customers are asking for. Balancing that is the hard part. The natural result is too little visionary stuff; if you build the right company, then everyone will be listening to your customers and screaming, “Let’s build the things customers want!” So the leadership’s task is focusing on what we need to do in order to be a better company in five years.</p>
Brandon: Since you bootstrapped for some time, how did you decide when it was the right time to raise institutional funding?</strong></p>
Sid:</strong> One big reason is the talent we wanted to attract. While we were in YC, we tried to hire a good sales leader, but everyone we approached wanted stock in the company. We hadn’t raised any outside money so stock was all mine and my co-founder Dmitriy’s</a> — he started GitLab and I started GitLab.com.</p>
This made clear that if we were unable to give out stock, we were not going to hire the best people; if we’re not getting the best people, we’re going to lose in the marketplace. If you give people stock while not taking outside money, you’ll still grow but very slowly, which is not the kind of deal these executives were expecting. They expect that after 6-7 years the stock is worth something and they can get liquid. The only way to get there is to attract external capital.</p>
Brandon: Is there anything that you would change in retrospect that you think might improve the outcome of where GitLab is today?</strong></p>
Sid:</strong> In hindsight, I’d rather have started GitLab.com a bit later. We’ve grown so fast since then that we’ve been behind in making a great experience for our users.</p>
I would focus on people running GitLab self-hosted, and start GitLab.com when we were ready for it. I’d rather have people not use our product than using the product and not being absolutely happy about it. It’s not about users, it’s about happy users.</p>
If not 100% of the users are happy, we’re not doing a good enough job.</p>
About the Guest Author</h2> Brandon Foo is the Co-founder and CEO of Polymail</a>, an email productivity platform designed for modern teams and companies.</p>

GitLab's Functional Group Updates - May 16th - May 26th

2017-05-31T00:00:00+00:00

Every day from Monday to Thursday, right before our GitLab Team call</a>, a different Functional Group gives an update</a> to our team.</p>
The format of these calls is simple and short where they can either give a presentation or quickly walk the team through their agenda.</p>
Recordings</h2>
All of the updates are recorded using Zoom</a> at the time of the call. All the recordings will be uploaded to our YouTube account and made public, with the exception of the Sales and Finance updates.</p>

Product Team</h3>
Presentation slides</a></p>
</iframe> </figure>

Backend Team</h3>
Presentation slides</a></p>
</iframe> </figure>

General Team</h3>
Presentation slides</a></p>
</iframe> </figure>

People Ops Team</h3>
Presentation slides</a></p>
</iframe> </figure>

Questions? Leave a comment below or tweet @GitLab</a>! Would you like to join us? Check out our job openings</a>!</p>

GitLab Patch Release: 9.2.2

2017-05-25T00:00:00+00:00

Today we're releasing version 9.2.2 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p>
This version resolves a number of regressions and bugs in this month's 9.2 release</a>.</p>
Please read on for more details.</p>

CE/EE:</strong> Improve merge request widget state calculation (!11668</a>)</li>
CE/EE:</strong> Fix right-sidebar gap on mobile (!11625</a>)</li>
CE/EE:</strong> Fix pipeline ETag (!11615</a>)</li>
CE/EE:</strong> Prevent errors from non-functional notify_post_receive endpoint (!11509</a>)</li>
CE/EE:</strong> Read HEAD commit and use it as sentry "releases" value (!11565</a>)</li>
CE/EE:</strong> Use refresh icon for retried jobs (!11667</a>)</li>
CE/EE:</strong> Make all notes use equal padding (!11616</a>)</li>
CE/EE:</strong> Fix ambiguous routing issues by teaching router about reserved words (!11570</a>)</li>
CE/EE:</strong> Show loading indicator while waiting for assignees first fetch (!11434</a>)</li>
EE:</strong> Fix return value when Geo nodes are not in sync (!1969</a>)</li>
EE:</strong> Fixed positioning of milestone dropdown in create board dropdown (!1972</a>)</li>
Omnibus:</strong> Fix cron worker being set to "" when no value was provided (!1580</a>)</li> </ul>
Upgrade barometer</h2>
This version contains no migrations and should not require any downtime.</p>
Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> file</a>.</p>
Updating</h2>To update, check out our update page</a>.</p> Enterprise Edition</h2> Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>.</p> Access to GitLab Enterprise Edition is granted by a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p>
9 Attributes of Successful Development Teams 2017-05-23T00:00:00+00:00 Not all development teams work the same way, but there are some values, processes and attitudes that all successful teams share.</p> 1. They Automate Everything</h2> There’s no substitute for the work of the human brain, but by automating some of the more time-consuming (and sometimes tedious) aspects of a developer’s job, you not only free up time that could be spent on other, more creative tasks, but you ensure that your software development process is easily repeatable, and consistent every release cycle. “We have a big release every month,” says GitLab Platform Backend Lead, Douwe Maan</a>, “but we have numerous patch releases. We have tons of scripts in our release tools repository that automate that so that we don’t miss little bits and so that it’s identical and reproducible every time.” Automation also means doing things like leveraging continuous integration to run scripts, so a portion of your code review is taken over, offloading work that would otherwise be done manually.</p> 2. They’re Meticulous about Documentation</h2> “Documentation of processes and guidelines is a way of kind of scripting or automating your team’s behavior,” explains Douwe. Because we’re a distributed team, it’s important that if a question comes up often, that there’s somewhere people can find what they need without having to wait for team members in other time zones to come online and answer a question – this saves time not just for the person with the question, but for others who are spared answering the same questions over and over. “If people on my team have a certain question or things that are blocking them repeatedly, that probably means it’s something we should either document better or invent a process around,” says Douwe.</p> “As a consequence of that, for example, we have the process around getting merge requests and issues into a patch release when it’s a regression or security issue and so on. At one point we had so few people that we could just say, ‘Hey that needs to go into the patch release,’ but of course as the team grows, that doesn’t scale anymore, because you’d have 20 people asking one person. To address that we invented the process around labels, where we use labels and milestones very heavily in GitLab to signal to people what has to happen with an issue.”</p> 3. They Use Collaboration Tools</h2> Having space for comments, questions or suggestions at each stage of the cycle is critical for fostering collaboration and making sure that everyone can follow the latest progress of a project. “For us, the single source of truth is always the issue</a>. Tools like labels, milestones, assigning to people, these all make sure that the right person knows when it’s their turn to do something, and the handoff happens through issue comments,” explains Douwe. This is another area in which we’ve had to become disciplined about documenting the latest update on an issue, because as a distributed team we can’t just walk over to a colleague’s desk to check something. “We don’t have the problem where after two days people will be like, ‘Hmm, what did we decide again?’” says Douwe. Discussion takes place right in the same environment where we’re working – whether it’s a comment on an issue or a merge request or an inline question on the code itself – so it’s easy for everyone to see the context for it and to refer back to it later.</p> 4. They Use Integrated Platforms</h2> Having all your software development tools in one environment reduces context-switching, tiresome maintenance when APIs change, and administrative complexity. It also makes the development process smoother, as an integrated tool often offers shortcuts within the UI that would not exist if you were using two separate products.</p> Douwe explains: “For a long time GitLab CI used to be a separately deployed web application: the UIs were not integrated in any way and they felt like separate products, as if they were not even made by the same company. At one point we decided to integrate it, and literally within one or two weeks we started seeing new possibilities of interlinking these applications. We’d think, ‘Hey, wouldn’t it be neat if we added a button to the latest status of this page?’ which previously is something we never would have thought about, because we really thought of the two as separate products that need to talk over an established channel, instead of just putting a link in everywhere where it would useful to have a link to CI. So with a built-in solution, the integration you get is not just tighter, it’s integrated in ways which other, separate products being developed by siloed development teams would never think of. We’re not just approaching it as an issue tracker, a code review tool or a CI tool, we’re seeing it as a development environment.”</p> 5. They Version Control Everything</h2> Using version control for source code is widely accepted as a good idea, but it’s useful for a number of other purposes too. Take documentation, for example: if you use a wiki, there is no concept of a merge request. “There’s no way of suggesting an improvement without immediately making it,” says Douwe, “so what that means is that in a lot of places that use a wiki, changing it is kind of scary.” This creates a feeling that suggesting updates or improvements is for senior team members only, and discourages participation and collaboration on the documentation. "Using source control here means that even the most junior person who’s like, ‘Hmm, I spotted a typo here,’ or ‘Hey, this wasn’t super clear, let’s do it like this,’ won’t be hesitant to bring up that suggestion." Having time to write a merge request that clearly outlines the advantages of what they're proposing makes it less intimidating to suggest a change. "It really makes the documentation, similar to the source code, an open source and living document that everyone can contribute to." The same principle applies to things like your CI/CD configuration, tests, and infrastructure code.</p> Improved collaboration and learning opportunities aren’t the only benefits of using version control for things beyond your source code: the ability to roll back in the event of something breaking, and to pinpoint where a bug was introduced are advantages both in that it’s easier to fix something, but also in that team members feel freer to experiment without the fear of causing irreparable damage if something breaks.</p> 6. They Make it Easy for Everyone to Contribute</h2> By opening up your development platform, other team members can discover, contribute to and learn from other team members’ work. “If you hide your CI configuration in an area that can only be accessed by the masters of the project, that means that very few developers on the team and especially very few developers on other teams will ever see that config,” says Douwe. “You really shouldn’t see your code as just a product of your team, you should also see it as a resource for everyone else in the company. If you ask a developer how they learned to code, most of them will not mention university or this book that they read, most of them will mention ‘code I read that was written by people who have more experience than me.’ So by giving them access to as much code as you can, that will actually make them better coders than if you have them work in a silo.”</p> If you ask a developer how they learned to code, most of them will not mention university or this book that they read, most of them will mention "code I read that was written by people who have more experience than me."</p> </blockquote> This isn’t just about less experienced developers learning from more experienced developers. Sometimes a fresh perspective from someone who isn’t as close to a project can spark solutions that aren’t apparent when you’ve been deep inside the code for a week. “Like if someone reads code and they ask a question like ‘Hey, what’s the reasoning behind this? I just found your code and I was wondering…’ it enables a conversation.” Douwe explains. “It helps us avoid Not Invented Here syndrome</a>.” Someone from another team might have already done work you require on a previous project of theirs – why not use it on your team? “It’s working together to make all of our code better, because if we use a shared library – even if it’s just a company internal one, like innersourcing – if one person improves it or fixes a bug or increases the functionality of that application, that’s work by one person that will immediately affect all the different teams.”</p> 7. They Spend Time on Side Projects</h2> “We don’t have explicit 20 percent time</a>,” says Douwe, “but at GitLab, as we are working on improving the same platform we use to do all our work, our job is to make our own job easier. Which means that even if something is not scheduled for this release, if it’s something that you think you can get done in couple hours, and it would save you more than a couple hours in the future, just do it.”</p> Sometimes going through the formal process for approving time to work on a new feature just isn’t necessary. “Unless you have something urgent you should be working on, it really helps to ask developers to feel responsible for the product, and also own the product in the sense that they can also suggest new features, and even spearhead the development of them without going through product management for example,” says Douwe.</p> 8. They Make Code Review Collaborative</h2> Having your work reviewed can feel like a personal judgement on whether you’re good enough or not. When code review is about “This is wrong, change it to this,” it can be really demotivating. Douwe explains: “A much better way, even if it seems like something is obviously wrong, would be to ask, ‘What do you think about changing to this/Did you consider X, Y, Z/I suggest changing it to this, if you think that makes sense.’ The communication there really helps and it also means that people don’t feel review is the time where they as person are being told if their work is good enough, if they are good enough, it’s really just talking about the actual code, the implementation, the best way to solve a problem.” Everyone on a team is free to review each other’s code or to ask for a review, so it becomes about just improving the merge request instead of passing a judgement about that person’s work. “If review feels like something that’s just done by the higher-up people and it’s a time when your code is deemed perfect or not, it might feel kind of scary to review someone’s code, especially if that someone is more experienced than you or has more experience in this area of the application. What really helps with collaboration is having everyone feel free to question each other’s code or question, ‘Is this the best way to go about this?’ without saying ‘This is wrong.’”</p> 9. They’re Allowed to Be Creative</h2> Problem solving is what developers do. So if a customer has a request for some feature that they would find useful, it can be helpful to ask the team to solve the problem the customer is experiencing, rather than presenting them with a spec which might not be the optimal solution. “In a lot of cases developers are aware of solutions either that already exist within the codebase or that exist in other people’s codebases because of innersourcing, or they might even have just read about this cool, open source tool, which a product manager might not be aware of,” says Douwe. “So allowing developers to be really critical of the proposal and having product managers not be too rigid in their specs also gives you better code and makes for happier developers.” This can also help you to build features that don’t just address one particular customer’s problem and fix it the way they would like, but rather work on solutions that can be useful to everyone.</p> To learn more about what makes development teams successful today, watch our webcast, "Managing the DevOps Culture Shift</a>" on demand.</p> GitLab Patch Release: 9.2.1 2017-05-23T00:00:00+00:00 Today we're releasing version 9.2.1 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> This version resolves a number of regressions and bugs in this month's 9.2 release</a>.</p> Please read on for more details.</p> CE/EE:</strong> MR widget styling fixes (!11591</a>)</li> CE/EE:</strong> Adds "comments on snippets" to doc (!11563</a>)</li> CE/EE:</strong> Add to docs: issues multiple assignees (!11556</a>)</li> CE/EE:</strong> Fix jQuery data attribute caching issue causing expanding issues (!11609</a>)</li> CE/EE:</strong> Fix placement of note emoji on hover (!11605</a>)</li> CE/EE:</strong> Change pipelines schedules help page path (!11592</a>)</li> CE/EE:</strong> Move environment monitoring to environments doc (!11583</a>)</li> CE/EE:</strong> Fix spacing of issue emojis (!11567</a>)</li> CE/EE:</strong> Add docs for change of Cache/Artifact restore order" (!11545</a>)</li> CE/EE:</strong> Add note about artifacts previewing in docs (!11539</a>)</li> CE/EE:</strong> Auto update docs (!11552</a>)</li> CE/EE:</strong> New doc topic: issues (!11075</a>)</li> CE/EE:</strong> Fix migrations for older PostgreSQL versions (!11620</a>)</li> CE/EE:</strong> Add missing regex to backup manager (!11635</a>)</li> EE:</strong> Fix the elasticsearch advanced search syntax link and edition details (!1958</a>)</li> EE:</strong> Fix "Remove your approval" button visibility for merged MRs (!1936</a>)</li> EE:</strong> Refactor advanced search syntax docs (!1953</a>)</li> EE:</strong> Remove redundant documented steps for Geo Setup (!1737</a>)</li> Omnibus:</strong> Mattermost: Fix config.json template for sql_data_source_search_replicas (!1575</a>)</li> Omnibus:</strong> Disable proxy_request_buffering for LFS endpoints (!1569</a>)</li> Omnibus:</strong> Splitting postgresql.conf into two separate configuration files (!1555</a>)</li> Omnibus:</strong> Fix sshd startup errors upon a full Docker restart (!1577</a>)</li> </ul> Upgrade barometer</h2> These versions have no migrations and should not require any downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> file</a>.</p> Updating</h2> To update, check out our update page</a>.</p> Enterprise Edition</h2> Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>.</p> Access to GitLab Enterprise Edition is granted by a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p> GitLab 9.2 Released with Multiple Assignees For Issues and Pipeline Schedules 2017-05-22T00:00:00+00:00 GitLab is designed to allow everyone to contribute whether their teams are large or small, remote or in a single room.</p> As a new feature or product is moving from idea to production, often multiple people work on the same issue together. For example, it is not uncommon to have a front end developer, backend developer, UX designer, QA tester, and product manager teaming together to bring an idea to market. With 9.2, GitLab introduces Multiple Assignees for Issues</a> to streamline collaboration and allow these shared responsibilities to be clearly displayed. All assignees are shown across our workflows and receive notifications as they would before, simplifying communication and ownership.</p> GitLab 9.2 also lays the foundation for the localization of GitLab, with Cycle Analytics now available in Spanish and German</a> languages. In future releases we will continue to localize additional workflows within GitLab, to ensure that everyone can contribute regardless of their native language.</p> Developers also have additional control over when their CI/CD Pipelines execute. We have added the ability to configure pipelines to run on a specific schedule</a> automating repetitive tasks like the creation of nightly builds, maintenance, or validation of external dependencies.</p> </a> This month's Most Valuable Person MVP</a> is Dosuken Shinya</a> </h2> Dosuken extended our Pipelines API</a> by adding additional search attributes</a>. This is a huge improvement to our CI API, for example enabling queries to easily return the latest pipeline for a specific branch, as well as a host of other possibilities. Dosuken also made a great contribution last release, laying the foundation for scheduled pipelines</a>. Thanks Dosuken!</p> </div> </section> </a> Multiple Assignees for Issues ees </span> </a> eep </span> </a> </div> </h2> On GitLab, it is not uncommon to have issues that require the collaboration of multiple individuals. In the past it could be difficult to track the shared ownership of an issue, especially in organizations where the issue’s contributors may not work together day to day. With this release, GitLab enables you to assign as many users as you want to a given issue. Every one of those assignees are first class citizens, and receive the same notifications as before. With this change, you can see multiple assignees in the issue list and on issue boards, and the assignees will all be able to track their association with the issue in their dashboard.</p> Note that as part of this change, the assignee_id</code> parameter in the issues API</a> has been deprecated. The assignee_ids</code> should be used instead. Also, the assignee</code> object in the JSON response has been deprecated. The assignees</code> array should be used instead. </p></p> </i> Learn more about multiple assignees for issues </a> </p> </section> </a> Internationalized Cycle Analytics ce </span> </a> ees </span> </a> eep </span> </a> </div> </h2> Hola Mundo, Hallo Welt! We are incredibly excited to announce the start of our journey to internationalise GitLab and would love your support to make this happen as broadly and quickly as possible.</p> Starting in 9.2, we have added the framework and infrastructure to translate GitLab into any language. To validate our technology decisions, we've only translated a single page (Cycle Analytics) into Spanish and German. In 9.3 and subsequent releases, we will continue to add more languages and more pages. If you want to help out, please take a look at our contributor Guidelines</a>.</p> To change your language, visit your Settings page by clicking on yourself in the top right corner.</p> </i> Learn more about Cycle Analytics </a> </p> </div> </div> </div> </a> Pipeline Schedules ce </span> </a> ees </span> </a> eep </span> </a> </div> </h2> For most projects, developers want to have their GitLab CI/CD pipelines executed for every new commit, ensuring any changes are built, tested and deployed. In some cases however, a developer needs extra control and would instead like a pipeline to execute on a specific schedule.</p> Today with GitLab 9.2, pipelines can now be configured to run when and how often you need them to</a>. Generating daily or weekly builds, performing maintenance, or even validating external dependencies can be easily configured to run on your schedule. This replaces the alpha UI for Scheduled Pipelines Triggers</a>. </p></p> </i> Learn more about scheduling pipelines </a> </p> </div> </div> </div> </a> Official GitLab installation on Kubernetes ce </span> </a> ees </span> </a> eep </span> </a> </div> </h2> We want to make GitLab the best cloud native development tool, so making it easy to get started on Kubernetes</a> is important. With GitLab 9.2, we are proud to announce that we have released official GitLab Helm charts</a>.</p> Helm</a> is the official Kubernetes package management tool allowing users to easily deploy, upgrade, and configure apps in their clusters. GitLab and Kubernetes go great together with easy autoscaling CI, app autodeployments to your clusters and everything else shown in the Idea to Production video</a> - out of the box, minimal setup! </p> </i> Learn more on installing GitLab using our Helm charts </a> </p> </div> </div> </div> </a> App Performance Feedback on Merge Requests ce </span> </a> ees </span> </a> eep </span> </a> </div> </h2> For most companies, determining the performance impact of a specific merge can be a challenge. Often performance data is contained within a separate tool, which the development team may not even have access to. At GitLab we want to make sure developers get feedback on every change they ship, and we are taking a big step forward today with our Prometheus integration.</p> With GitLab 9.2, we now automatically display the change in memory consumption after a deploy directly on its merge request. This allows the developer to quickly and easily determine if there are any performance changes and investigate as soon as possible, all within their usual daily workflow. In future releases, we will analyze additional metrics</a> as well. Building responsive and delightful apps is everyone's responsibility! </p> </i> Learn more on how the deployment memory usage on merge requests works </a> </p> </div> </div> </div> </a> Disaster Recovery Alpha Improvements eep </span> </a> </div> </h2> Since version 9.0, GitLab ships with support for Disaster Recovery in Alpha as part of GitLab Geo. We are committed to making Disaster Recovery better on every release, and GitLab 9.2 is no exception. Today we are improving the UX of the Disaster Recovery feature, with more obvious controls and more reporting on what’s going on during the replication process.</p> Finally, we had also made improvements to the repositories synchronization mechanism, and now it is smart enough to resync broken repositories due to a failed sync or repositories that have been recently updated on the primary node but have been synced some time ago on the secondaries. </p> </i> Learn more about GitLab Geo </a> </p> </div> </div> </div> </a> Auto-Refresh on Issue Titles and Descriptions ce </span> </a> ees </span> </a> eep </span> </a> </div> </h2> The issue page in GitLab is a key area of collaboration, with you and your team constantly editing content. When viewing an issue page, the title and description now refresh automatically (in response to someone else changing it) to keep up with your workflows. The issue page itself doesn’t reload. So you can simply leave a browser tab open to an issue you are interested in, and you’ll always be seeing the latest information. Even the browser tab title refreshes by itself.</p> We've also added a system note when an issue description is edited, so you can always scroll through the comment thread and see who made any changes, and when. Even adding comments now feels more responsive. And if you edit an existing comment, that comment will also be automatically refreshed on any other user's screen who happens to have the same issue open. </p> </i> Learn more about issues on GitLab </a> </p> </div> </div> </div> </a> Remove Filter in Search Bar ce </span> </a> ees </span> </a> eep </span> </a> </div> </h2> You can now easily remove filters in the search bar for issues and merge requests with a simple mouse click.</p> We've also styled the labels within the filter bar to match the colors they have elsewhere. </p> </i> Learn more about searching issues and merge requests </a> </p> </div> </div> </div> </a> Advanced search with Elasticsearch ees </span> </a> eep </span> </a> </div> </h2> We are bringing more advanced search capabilities leveraging Elasticsearch integration. Provided you have configured Elasticsearch, you can search for exact phrases using double quotes, search for content ignoring the order of search terms, match partial words, and other syntax. (Note that this applies to the search box in the top right corner throughout GitLab, and not the search bar inside issue lists and merge request lists.)</p> You can now also search globally across all wikis in your instance, again requiring and powered by Elasticsearch. </p> </i> Learn more about advanced search with Elasticsearch </a> </p> </div> </div> </div> </section> </a> Other Improvements in GitLab 9.2 </h2> </div> </a> Create Merge Request from Issue ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> With each iteration of GitLab, we strive to make going from idea to production faster and smoother.</p> This new small tweak allows you create a merge request right from the issue page, with GitLab creating the associated branch automatically in the background for you. It's especially useful when you want to make simple code commits right inside GitLab. </p> </i> Learn more on how to create a merge request from an issue </a> </p> </a> Comments for Personal Snippets ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> Collaboration often happens in snippets, even personal snippets. With this release, you now have a comment thread for each personal snippet, just like project snippets.</p> </i> Learn more about snippets </a> </p> </a> Rendered Code Preview ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> Many files, such as SVG & Markdown are displayed in GitLab’s file view in their rendered form. Sometimes, it’s much more useful to see the actual code. We’ve now added a handy little switch on the file view, which means you can now easily switch between the rendered preview and the raw code.</p> </a> Terraform Support for GitLab Runner on Google Compute Engine ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> As part of GitLab 9.1, we launched support for installing GitLab on GCE via Hashicorp’s</a> Terraform</a>. With 9.2 we are also adding the ability to deploy GitLab Runner as well, allowing you to complete the idea to production cycle!</p> </i> Visit our Terraform project </a> </p> </a> Job Artifacts Preview in UI ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> Artifacts can be files of any kind, and you have access to them by browsing the archive directly from UI. GitLab 9.2 improves this capability further: now PDFs, images, videos and other formats can be previewed directly in the job artifacts browser without the need to download them.</p> </i> Learn more on browsing job artifacts </a> </p> </a> Handling of Ambiguous Routes in Dynamic Paths ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> There are several paths that GitLab uses to access certain features. With the introduction of nested groups these features could become unavailable for projects or groups with names that conflict with these paths. For example: for a project called 'badges' the build and coverage status badges would become unavailable. To avoid confusion, it is now no longer possible to create projects or groups with names that could clash with existing GitLab routes. If you had any projects or groups named like one of these routes, they will have been automatically renamed during the upgrade. A project named badges</code> would be renamed to badges0</code>.</p> Keep in mind that git-remotes would need to be updated locally as well. That can be done like this:</p> git remote set-url origin <git@gitlab.com:the-updated-path/the-updated-name.git> </code></pre> The full list of reserved words can be found in the dynamic_path_validator.rb</code> file</a>. The list of existing projects and groups that were renamed in this release can be found in the migration</a> that renamed them.</p> </p></p> </i> Learn more on creating a subgroup </a> </p> </a> Deletion of branches after a merge request is merged is now on by default ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> Starting with GitLab 9.2, the deletion of the source branch in a merge request is selected by default. If you want to keep the branch around even when the merge request is merged, you’ll have to uncheck the option from the merge request widget before merging.</p> </a> Artifacts are Restored after Cache Files in CI Jobs ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> It may happen that someone, by mistake or by purpose, uses the same path in .gitlab-ci.yml</code> for both cache</code> and artifacts</code> keywords, and this could cause that a stale cache might inadvertently override artifacts that are used across the pipeline.</p> Starting with this release, artifacts are always restored after the cache to ensure that even in edge cases you can always rely on them. </p> </a> Omnibus Improvements ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> GitLab Mattermost 3.9</h4> GitLab 9.2 includes Mattermost 3.9</a>, an open source Slack-alternative</a>, which adds a new integrations directory</a>, Polish support, upgraded desktop apps with spellchecker, and much more.</p> This version includes security updates</a> and an upgrade is recommended.</p> GitLab Registry</h4> The GitLab Container Registry has been updated from 2.4 to 2.6.1.</p> </div> </a> Select Individual Approvers for Merge Request Approvals ees </span> </a> eep </span> </a> </div> </h3> Configuring merge request approvals allows for selecting individual approvers. The process is even easier, with the search now limited to project members and users in relevant groups (parent group or groups with access via a project share) in the project settings and the per merge request settings, so that you can easily identify relevant users.</p> </i> Learn more on configuring the merge request approvals </a> </p> </a> Commenting in Outdated Diffs ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> With this release, you can now link directly to an outdated diff from the merge request discussion thread, allowing you to quickly refer to older commits during code development, collaboration, and review. You can even comment in that previous outdated diff as well.</p> </p></p> </i> Learn more about merge requests </a> </p> </a> Deploys shown on Performance Dashboard ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> When investigating a change in performance behavior, one of the first questions asked is always if there have been any changes to the environment. GitLab 9.2 now quickly answers this question by showing all deployments to an environment directly on the monitoring dashboard. This allows easy correlation between any changes in performance and a new version of the app, all without leaving GitLab!</p> </i> Learn more on monitoring environments </a> </p> </a> Manual Actions Respect Protected Branches ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> Manual actions</a> now require the same permissions as a repository write, allowing control over who can trigger them. For example, triggering a manual deploy job to production from the master branch can now be restricted to a narrower set of users with access to commit.</p> This is a very important item in the list of security enhancements we're bringing into GitLab in order to protect your deployment process, you can read more in this issue</a>. </p> </a> Failed Jobs Tab allows you to access to a summary of all the failures quickly ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> When you commit new code to a project with continuous integration configured you normally expect to see a green check: this tells you the pipeline succeeded and everything worked as expected. In the unfortunate case something went wrong, you might want to know exactly what has failed as quick as possible, but walking through multiple stages and jobs could be frustrating, expecially if your pipeline is very complex.</p> GitLab 9.2 introduces a new tab in the Pipeline view: you can now directly go to Failed Jobs</code> and see the detailed list of jobs that were unsuccessful in one single place, having a big picture of the actual status. </p> </a> Usage Ping ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> This release contains two changes to the usage ping: you can now opt-out</a> of the usage ping through your configuration in gitlab.rb</code>. This allows you to turn off the usage ping before having started GitLab. You were already able to opt-out through the administration panel and this remains the case. In addition, we now include the hostname in the usage ping, similar to the version check</a>. For more, see the documentation on the usage ping</a>.</p> </i> Learn more about usage ping </a> </p> </a> Docker Registry Cleanup Tool ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> We’re glad to announce that an alpha version of our Docker Container Registry maintenance tool</a> is available to the public. This tool analyzes the container registry</a> and prunes unreferenced versions of tags, manifests, and layers to reclaim storage space.</p> If you're enthusiastic to experiment with how it works, you're encouraged to test it out and report your feedback! </p> </a> GitLab Runner 9.2 ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> We're also releasing GitLab Runner 9.2 today! Most interesting changes:</strong> Support for TLS client authentication (merge request</a>)</li> PodLabels setting for Kubernetes executor configuration (merge request</a>)</li> Support for Kubernetes Service Account in Kubernetes executor configuration (merge request</a>)</li> </ul> List of all changes can be found in GitLab Runner's CHANGELOG</a>.</p> </p></p> </i> Learn more about GitLab Runner in our docs. </a> </p> </a> Performance Improvements ce </span> </a> ees </span> </a> eep </span> </a> </div> </h3> With every release of GitLab we look to make significant improvements to the performance. In GitLab 9.2, the following areas should see visible improvement:</p> Listing groups</li> Listing projects</li> Listing merge requests</li> Listing milestones</li> Push mirrors should no longer put pressure on filesystem and sidekiq queues</li> </ul> Here is a full list</a> of performance improvements in GitLab 9.2.</p> </div> </div> </section> </a> Deprecations </h2> </a> Vendor support for Ubuntu 12.04 and OpenSUSE 13.2 </h3> Vendor support for Ubuntu 12.04 and OpenSUSE 13.2 has ended. GitLab will no longer provide support or packages for these platforms.</p> Due: May 22nd, 2017.</strong> </p> </section> </a> Upgrade barometer </h2> To upgrade to GitLab 9.2, no downtime is required.</p> However we're also migrating data for CI jobs. If you have a significant number of jobs, this could take some time. Starting with GitLab 9.1.0 it's possible to upgrade to a newer version of GitLab without having to take your GitLab instance offline. However, for this to work there are the following requirements:</p> You can only upgrade 1 release at a time. For example, if 9.1.15 is the last release of 9.1 then you can safely upgrade from that version to 9.2.0. However, if you are running 9.1.14 you first need to upgrade to 9.1.15.</li> You have to use post-deployment migrations</a>.</li> You are using PostgreSQL. If you are using MySQL you will still need downtime when upgrading.</li> </ol> This applies to major, minor, and patch releases unless stated otherwise in a release post.</p> A new version of our API was released in GitLab 9.0</a>. While existing calls to API v3 will continue to work until August 2017, we advise you to make any necessary changes to applications that use the v3 API. Read the documentation</a> to learn more.</p> </p> </section> Fast and Natural Continuous Integration with GitLab CI 2017-05-22T00:00:00+00:00 Do you use GitLab to store your repos? Have you ever stopped to check what some of those tabs on top of your repositories do? Well, you can either disable those in your project settings, or you can keep reading to discover some ways in which they can help you power up your development speed.</p> </p> This post aims to offer a high-level overview of how GitLab has interpreted the main concepts of Continuous Integration/Delivery and introduce the main features of the tool as well as their naming conventions, as it can sound more overwhelming than it actually is.</p> The product’s growth has made it present on many companies’ tech stacks. Part of this popularity comes from being indeed a great open-source project to follow, its release cycle is blazing fast and it’s delivering new features every month on the 22nd. One of the most important factors of this equation is the fact that it’s not only a self-hosted solution that enables you to have all your projects under control, but also a pretty solid one. Just ask your reference ops for his opinion on how even the community (non-commercial) edition brings many stuff to the table, that were incredibly expensive or even lacking on many other SaaS products before.</p> </p> It sometimes happens that we simply stick to well-known tools for us and won’t notice or research alternatives that may improve our everyday work. I believe this to be the case with some of the GitLab’s lesser-known features. The software is much more than a traditional VCS server. In fact, last year they came up with the idea of their so-called “masterplan” to extend the product to be more like a “suite” and cover every step of the development cycle, or in their words: go from idea to production</a>. And in both previous and future</a> releases, they are bundling some really cool additional integrations worth checking (e.g. Mattermost ChatOps or Prometheus monitoring).</p> Differences with Other Continuous Integration Tools</h3> Let’s start getting the full picture of the features that make it so powerful. First of all, its model is based on a lightweight YAML configuration file stored in each repository’s root. This has some pros worth to mention along with the rest:</p> Tightly coupled systems (both Continuous Integration and VCS are a single product).</li> The Continuous Integration configuration becomes versioned: Enforcing different branches with different configurations.</li> Allowing contributors to also collaborate in the integration setup.</li> </ul> </li> Docker integration out of the box, including private docker registry per project.</li> Artifacts browser that allows to access the stages output the same way you’d do locally.</li> No nightmare maintenance time of the CI server.</li> </ol> Of course, from the user’s point of view, it also comes with some drawbacks compared to other Continuous Integration systems, since it embraces a “convention over configuration” model, which means you get a pretty powerful tool without having to spend your time configuring it while you stick to its way of doing things. The lack of plug-ins and integrations we are used to seeing in other tools to fine-grain configure some aspects of the project is one of them (e.g. creating jobs that require multiple repositories becomes non-trivial). On the other hand, most use-cases are covered enough and features like configurable email alerts, history browser or programmable builds, you have them all.</p> But let’s be clear, they neither have invented the wheel nor are the only ones using it. Many other Continuous Integration software solutions also lay in similar paradigms (.travis.yml, Jenkinsfiles…). This is all a matter of taste. The strongest feeling you get after using different solutions is that GitLab’s is easier to configure plus it allows having most details under control in the same browser tab. They took some of the best features of every tool and bundled them into this solution. It makes complete sense.</p> Main Features</h3> Let’s try to briefly illustrate the main features of this tool and demonstrate how easy it is just to get started with it even without any sysadmin experience or without bothering your DevOps. As said, everything spins around the .gitlab_ci.yml file containing the definition of the different stages (steps) that have to be completed in whole, in order to get the project successfully delivered. The file structure</a> is natural to be read and once you have seen a couple of examples, you’ll start writing your own without much effort.</p> Head first for GitLab’s CI docs</a> for lots of info about how to translate the specific needs of your project into their conventions. But to summarize a review of the Continuous Integration capabilities every project has enabled by default:</p> CI/CD settings</h4> The settings page gives an overview on just how easy it is to configure everything related to what’s needed for the creation of the continuous integration magic, i.e.:</p> Runners</h4> What if I tell you can finally forget about configuring and managing slave machines, the way they speak with the CI server through SSH, how to balance the workload between all the build machines, and many other stuff that is both tedious and often difficult? Meet the runners! Setup</a> becomes just as easy as it is to follow the three steps described in the CI/CD settings (settings/ci_cd) on your project: install the right binary for your OS, set the URL endpoint and the registration token provided in the settings page and you are done. Also, you can tag the runners based on their capabilities (e.g. docker, databases, etc.) to select them for specific jobs when they are required.</p> Runners can implement many executors, i.e. ways of running your build scripts/code in them; from the most basic ssh executor, through a container host and right to the biggest kubernetes cluster you can think of, supporting even Powershell/Batch in Windows systems.</p> In their self-hosted solution, gitlab.com</a>, they also provide "shared runners": VMs free of charge, dynamically allocated to build your project, extremely useful for those open source projects with limited resources.</p> Secrets management</h4> In the microservices era, where your project might be integrated and talk with dozens of APIs that require tokens, secrets, passwords, and many other ways to authorize that dialog, a way to handle this complexity in an elegant manner becomes a priority. A really bad smell seen in many projects</a> is to store all these in config files on a remote machine or even hang around in some piece of code. To stress the importance of this, just consider how many services</a> and projects</a> are popping up to handle this issue. GitLab projects provide a simple keystore in their Continuous Integration settings that can be accessed from the integration scripts, to help project members handle and configure all these secrets.</p> Pipelines</h4> This is the core feature of any Continuous Integration system and yet a really simple concept, that translates to all the steps you’ll follow from the moment you are facing your source code to the point in which you are about to deploy your application. In between, you can include everything you would consider to make sure your code looks right (linting), can be built, works right (testing), integrates with other systems and anything you can come up with to take the last steps and ship your code.</p> </p> Container Registry</h4> Imagine having your own private Docker hub, where you can store your project’s images and update them whenever it’s needed without having to expose them to the public, and being able to pull them login from anywhere into the registry. You can have an image ready for every stage of the road and pulling them from your runners is blazing fast. This becomes super handy to avoid initializing the environment and therefore speeding up the total time the pipeline takes to run: faster builds = happier devs.</p> Environments & Review Apps</h4> Everyone loves gitflow</a>, right? There are some good reasons for that. It’s built on the premise that if every branch is developed isolated, new features don’t interfere with each other or the stable version until they are merged back in the master branch. This helps with both developing new functionalities and testing them.</p> When containers came into our lives it was obvious how the process of deploying different, independent environments with individual settings per feature could be eased and improved. It’s fair to say we now use containers as standard de facto for environment templates. Most mainstream Continuous Integration solutions were released way before the first container was even created, so they were not built with Docker in mind, but for GitLab CI it’s the other way around: they embrace containers as the way to go, based on the many benefits it brings to the workflow.</p> </p> Imagine a very common scenario in the workflow: you are about to merge a feature branch that has to be tested out by the QA team, which introduces some new libraries and a new service (e.g. Redis, mongoDB…) to be deployed. Just update your Dockerfile to include the new layer(s) that manage those new dependencies and push the image to your local registry. Also, append the line to include the new service via docker hub to .gitlab_ci.yml. The feature branch, when pushed on the remote, will have everything in place to be deployed to the testing environment.</p> </p> This is where Review Apps</a> come into action, it’s just a posh way to call dynamic, per-branch environments created to verify changes and see them live. Every branch gets instant deploy support when pushed to the repo. This process can speed up with tools such as dpl</a>, that abstract many of the details for major deploy services, or go freestyle and call your custom deployment script from there. It also integrates an interactive terminal in-browser to introspect on builds to debug and troubleshoot if needed. You no longer have to go over the Jenkins’ mantra to clone a configured job, rename it, adjust the branch in the configuration… and 10 or 15 tedious steps before deploying an ephemeral test environment.</p> Another major feature you are going to love is the history browser</a>. Imagine you deployed some changes to a demo environment and 10 minutes before going live, you detect it contains a major bug that would be nasty if displayed on camera. No worries; it’s super easy to access the history of what was deployed on every environment and perform rollbacks or redeploy on-demand to any previous reproducible state. Just awesome.</p> </p> I hope after this post, the central concepts of GitLab’s Continuous Integration make good sense to you and your projects.</p> This post was originally published on solidgeargroup.com</a>.</em></p> Sign up for a </i> GitLab EE Trial</strong> </i> now!</a>!</p> Why Git is Worth the Learning Curve 2017-05-17T00:00:00+00:00 Over the last decade, distributed version control systems, like Git, have gained popularity and are regarded as the most important development tools</a> by developers. Although the learning curve can pose a challenge, developers told us that Git enhances their ability to work together and ship faster, suggesting that managers have a real incentive to help their teams over the initial hill imposed by the transition to Git.</p> With the full history of the repository stored on each developer’s machine, using Git makes commits, merges and other commands much faster, even enabling developers to work offline. Upgrading your source code management solution to a distributed version control system is the first step toward building a flexible working environment that can support modern development teams, but moving away from legacy systems and tools can be a daunting prospect.</p> The Challenge</h3> In our Global Developer Survey</a>, the biggest concern respondents cite about using Git is the associated learning curve, with 40 percent saying they consider it an issue:</p> </p> There are several reasons why this could be the case. Broadly, Git has a different underlying model than other VCS, one that makes it more intuitive for computer scientists and mathematicians</a>, but potentially less so for those with other backgrounds. Unlike with some programming languages where knowledge of one eases the adoption of another, Git commands are different from those in other version control systems, making familiarity with another system only a minor advantage. Finally, the number of Git commands and arguments that make it a particularly powerful tool also complicate the beginner’s task of learning the ropes. For teams transitioning to Git, this not only means migrating repositories, but relearning ingrained habits and workflows, and it may sting a bit.</p> The Rewards</h3> Greater collaboration and code quality</h4> Nearly 80 percent of respondents confirmed</a> that they see increased collaboration with teammates as a major benefit of the Git workflow, which nudges teams to update each other early and often, enabling them to collect feedback regularly and integrate suggestions throughout the process. The accessibility of Git repositories makes it easier for contributors and specialists across your organization to collaborate, making it more likely that errors are spotted, resulting in better and more stable code. Feature branches, or branches containing one feature or bug fix, allow teams to discuss and perfect their code at the merge request stage, before changes are accepted into master. Before merging, a developer can commit their code locally to ensure it works, preserving the quality of the master code base.</p> “Cheaper” branching</h4> The branching capabilities within Git are largely responsible for its popularity. Developers can create a new branch and isolated environment to work on new features, bug fixes, customer requests, or experiment on something new with minimal cost. Branching with Git is “cheap” in that it's easy to do and doesn’t take up a lot of space. Creating a new branch requires but a single command and no network connection, unlike Subversion and other centralized version control systems, where branching is a slow and repetitive process resulting in a complete copy of all code.</p> Easier merging</h4> When coupled with a source code management tool like GitLab, you can enhance merging capabilities with a user interface that allows you to review and comment on changes on branches before merging. At GitLab, we call this a merge request and run continuous integration</a> on every branch as an additional quality gate to ensure everything that goes into the master code base works. With GitLab branching and merging, you can even protect branches to prevent merges that aren’t ready, and apply merge request approvals for an added layer of security.</p> More good news: just a few commands are required to get started, and the open source community around the world ensures there’s always someone awake to answer your question.</p> Read our </i> Global Developer Survey Report</strong> </i> Download it here</a>!</p> Demo - Auto-Deploy from GitLab to an OpenShift Container Cluster 2017-05-16T00:00:00+00:00 Containers are an essential tool for achieving DevOps at scale. Bringing code and infrastructure closer together, containers provide consistency across environments and tools for developers, QA, and IT. Using GitLab's built-in CI/CD</a> and our integration with OpenShift, you can run all of your CI/CD jobs in a container cluster.</p> What is a Container?</h2> Containers work much like a virtual machine except that, instead of packaging your code with an operating system, containers are run as a Linux process inside of the kernel. This means that each container only contains the code and dependencies needed to run that specific application, making them smaller and faster to run.</p> For developers, containers make it possible to build one version of an application that can be easily deployed to multiple types of environments. Essentially, whatever developers and QA runs, is exactly what finds its way to production. What you see in development is what you see in testing, staging, and production. Code can be shipped faster when packaged in a container because errors and bugs are caught earlier in process.</p> Communication and collaboration between developers and operations also improves because developers have seen exactly what it is that operations is getting, and operations are running exactly what the developers gave them. The result is that everyone can focus more on shipping quality code faster because applications don't have to be rebuilt as they move through the development lifecycle.</p> GitLab intergrates with both Kubernetes and OpenShift container orchestration platforms, making it possible to run continuous integration and continuous delivery related jobs in the cluster. It also gives you the ability to set up different environments, called Review Apps</a>, for different branches of your code base. Review Apps make it easy to view and test changes in an environment, in the cluster, so you can iterate and test faster.</p> Demo</h3> In this demonstration, Senior Build Engineer DJ Mountney, will show how you can build, test, and deploy a basic application in a container from GitLab to an OpenShift containter cluster.</p> </iframe> </figure> Watch the webcast</h3> To learn more about containers, how they can help scale your DevOps workflow, and the GitLab/OpenShift integration, register to watch</a> The DevOps Journey: Using Containers webcast</strong>.</p> GitLab's Functional Group Updates - May 9th - May 12th 2017-05-15T00:00:00+00:00 Every day from Monday to Thursday, right before our GitLab Team call</a>, a different Functional Group gives an update</a> to our team.</p> The format of these calls is simple and short where they can either give a presentation or quickly walk the team through their agenda.</p> Recordings</h2> All of the updates are recorded using Zoom</a> at the time of the call. All the recordings will be uploaded to our YouTube account and made public, with the exception of the Sales and Finance updates.</p> Edge Team</h3> Presentation slides</a></p> </iframe> </figure> Discussion Team</h3> Presentation slides</a></p> Due to team members being on vacation, this Functional Group Update has only slides. Tune back next time!</p> UX Research Team</h3> Presentation slides</a></p> </iframe> </figure> Engineering Team</h3> Presentation slides</a></p> </iframe> </figure> Questions? Leave a comment below or tweet @GitLab</a>! Would you like to join us? Check out our job openings</a>!</p> GitLab Patch Release 9.1.4 2017-05-15T00:00:00+00:00 Today we're releasing version 9.1.4 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> This version adds some improvements and resolves a number of regressions and bugs in the 9.1 release</a>.</p> Please read on for more details.</p> CE/EE:</strong> Fixed search terms highlight. (!11198</a>)</li> CE/EE:</strong> Fixed bug where merge request JSON would be displayed. (!11096</a>)</li> CE/EE:</strong> Handle incoming emails from aliases correctly. (!11079</a>)</li> CE/EE:</strong> Sort the network graph both by commit date and topographically. (!11057</a>)</li> CE/EE:</strong> Handle failures for incoming emails. (!11014</a>/!1810</a>)</li> CE/EE:</strong> Fix error on CI/CD Settings page related to invalid pipeline trigger. (!10948</a>)</li> CE/EE:</strong> Fix cross referencing for private and internal projects. (!11243</a>)</li> CE/EE:</strong> Add missing project attributes to Import/Export. (!10880</a>)</li> EE:</strong> GitLab Geo: Backfill projects where the last attempt to backfill failed. (!1785</a>)</li> </ul> Upgrade barometer</h2> This version has no new migrations and should not require any downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> 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 granted by a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation</p> How to use GitLab CI and MacStadium to build your macOS or iOS projects 2017-05-15T00:00:00+00:00 In this article, we will see how to get started with MacStadium</a>, a provider that offers dedicated Mac hardware which you can use with GitLab CI</a> and build your macOS or iOS application.</p> Continuous Integration and Delivery with GitLab</a> is easier if you are developing your application on Linux. All you need to do is find a provider, spin up a VM, install GitLab Runner</a> on it and configure your project's .gitlab-ci.yml</code> file</a>. On macOS on the other hand, things may not be that easy. Finding a provider that offers a Mac machine that will be online 24/7 can be hard. MacStadium is here to help achieve that goal and offers a discount to all GitLab users. Let's see how to make this happen.</p> On this page</h3> Choosing a Mac mini plan</a></li> Connecting to the Mac mini</a> Connecting with VNC</a></li> Connecting with SSH</a></li> </ul> </li> Setting up the development environment</a> Installing Xcode</a></li> Installing the command line tools</a></li> </ul> </li> Installing and configuring the GitLab Runner</a></li> Testing a project with CI</a></li> Conclusion</a></li> </ul> Choosing a Mac mini plan</h2> The first step is to choose a plan. MacStadium offers many options, so you can pick whatever fits your needs. A Mac mini</a> is perfect to test things out and is a good first choice. It should be enough to get you started, but depending on your needs you may have to upgrade to a more beefy machine.</p> Depending on your location and project needs, you have to:</p> Choose the datacenter</li> Choose the Mac mini</li> Choose the macOS version</li> Click Start Trial</strong> (24 hours) on the Mac mini of your choice to get going in a few steps</li> </ol> At first you'll be asked to create a MacStadium account</a> Fill in your information and when in the Secure Checkout</strong> page, be sure to check the I want to use a coupon code</em> option and use GITLAB10</code> for 10% off.</p> </i> At the time of this writing, the staged machines come with macOS 10.12.2. As new releases com from Apple, MacStadium tests them thoroughly and then update their staged machines. Of course, as a customer you can run the OS update on your own machine anytime.</p> Connecting to the Mac mini</h2> When you sign up, you'll receive an email with two important pieces of information:</p> The static IP address of your Mac.</strong> This will allow you to find your Mac mini from anywhere in the world, and you can also point domain names to this IP address so it's easier to remember.</p> </li> The username and password to access the machine.</strong> The user is standard for all installs, but the password is randomly generated. Upon the first login, you can and are encouraged to change it.</p> </li> </ol> After you have this information, there are two ways of connecting to your Mac mini: VNC</a> and SSH</a>.</p> Connecting with VNC</h3> If connecting from a Mac, Apple's Screen Sharing</a> is ideal. It's installed on every Mac and can you can connect on your MacStadium Mac mini easily with the username and password that was sent to you via email.</p> If you don't have a favorite VNC client already, there are a number of options to choose from:</p> TigerVNC</a> (Multi-platform)</li> Vinagre</a> (GNU/Linux)</li> Remmina</a> (GNU/Linux)</li> RealVNC</a> (Multi-platform)</li> </ul> When you connect with VNC, you can use the same password that is setup for the user on the Mac mini.</p> </i> macOS has that as a separate setting, but MacStadium's provision scripts enable VNC connections by default.</p> Connecting with SSH</h3> You can SSH into your machine using the username and password. For example, if the username is administrator</code> and the IP address of your machine 1.2.3.4</code>:</p> ssh administrator@1.2.3.4 </code></pre> Enter the password when asked (you won't be able to see it), hit Enter and you're in!</p> Setting up the development environment</h2> The following steps are to be performed to the remote Mac machine. We need to install Xcode</a> and the command line tools that contain the SDKs and UNIX development applications like the LLVM compiler, etc.</p> </i> Apart from the needed toolset, the screensaver needs to be disabled otherwise the machine will be put to sleep, thus disrupting the workflow of CI. Thankfully, all the machines hosted on MacStadium are set to never sleep by default. It's just done in System Preferences > Energy Saver</strong>.</p> Installing Xcode</h3> There are two ways to install Xcode. You can either download it from Apple's developer portal or use the App Store where you might be asked to fill in your credit card information. To avoid that, manually download Xcode:</p> Connect via VNC to the remote Mac machine</li> Open a browser and go to https://developer.apple.com/download/more</a></li> Login with your existing AppleID or create one</li> Select the Xcode version you wish to install</p> </p> This should download the Xcode package in your Downloads folder and decompress it automatically. After a couple of minutes it should finish.</p> </li> Open a terminal and move Xcode.app</code> to /Applications</code> so that it can be found by Launchpad:</p> mv ~/Downloads/Xcode.app /Applications </code></pre> </li> Go to your Applications, and double click on Xcode in order to install it. The verification will begin, that should take a minute.</li> Answer "Open" when you are asked if you are sure you want to open it.</li> Select "Agree" in the License Agreement and provide your administrator password.</li> The installation process should begin and after a while you will have Xcode installed and ready to be used.</li> </ol> In the next step we will install the command line developer tools.</p> Installing the command line tools</h3> The command line tools are a subsection of Xcode, so if you installed Xcode, you may skip this part.</p> Open the Terminal app or run this command via SSH:</p> xcode-select --install </code></pre> </li> Accept the License Agreement and the installation will begin</p> </li> </ol> Now that all development tools are installed, it's time to install GitLab Runner.</p> Installing and configuring the GitLab Runner</h2> GitLab Runner is responsible for running your jobs in macOS and then it reports the results back to GitLab.</p> To install it, follow the instructions in the Runner's documentation</a>. Make sure to also carefully read the current limitations</a>.</p> Testing a project with CI</h2> The final piece of this puzzle is to set up a project in GitLab (your own CE/EE instance </a> or even GitLab.com</a>) and hook it up with Mac mini. We will not expand on that, but you can follow this nice blog post by Angelo Stavrow on Setting up GitLab CI for iOS projects</a>. It includes comprehensive steps to get you started.</p> Conclusion</h2> Having a dedicated Mac machine for your development can save you precious time when you follow the Continuous Integration workflow with your team. In this tutorial, you've seen how to quickly get a remote Mac mini up and running for your needs. Be sure to add the promo code GITLAB10</code> on checkout for 10% off!</p> Happy building!</p> </i> Get 10% off of all MacStadium plans by using GITLAB10</strong> at checkout. The coupon can only be applied when signing up hardware, but if you are an existing customer who is using Gitlab and makes a change in hardware, you can always apply it again or request the discount in a ticket.</p> Cover image provided by MacStadium</a>.</p> Join GitLab's 3rd Issue Bash This June 2017-05-11T00:00:00+00:00 There are currently over 7000 open issues on GitLab CE, and we need your help to sort them out! We have over 1500 GitLab contributors</a>, and we want everyone to be able to find issues to work on.</p> Of course, some lucky contributors will be rewarded with awesome swag! 🙌</p> Our last Issue Bash helped us to close over 160 issues.</p> When is it Going to Happen?</h2> We'll kick it off at 00:01 UTC on Saturday, June 3rd</strong> and will keep it up until 23:59 UTC on Sunday, June 4th</strong>.</p> Who Can Contribute?</h2> </i> At GitLab, everyone can contribute!</strong> </i></p> This is your chance to get involved! Most of the tasks don't require technical expertise, therefore, non-technical community members are definitely welcome and prize worthy!</p> How do You Get Involved?</h2> The last issue bash our contributors made over 1600 contributions in order to close 160 issues, label over 200 of our unlabelled issues and add accurate labels to countless others.</p> There are four main things we need from our task force:</p> Track issues that can be easily closed</li> Categorize issues</li> Fix known bugs and pain points</li> Ship existing feature proposals</li> </ul> Check out the Q2 Issue Bash Proposal</a> to find out how to get started.</p> We had some great feedback from the Community after the last event, so we aim to make some changes over the next few events to make participating and collaboration easier and more fun!</p> Prizes</h2> We have some awesome swag ready for you:</p> Five T-shirts</li> Four pairs of pajama pants</li> Three Moleskine notebooks</li> Two PocketCHIPs</a></li> One messenger bag (filled with all the stuff listed above!)</li> </ul> </p> If we can beat our old target from the last Issue Bash (> 200 issue closures), we'll give away a mystery prize</strong> as well! 🎉 We still don't know what it is!</p> Users making any contributions to the project that fall into the above categories, between the start and end times of the event, will be entered into the random draw to win a prize. The contributions will be collated after the end of the event and prize winners, drawn at random, will be contacted in the weeks that follow.</p> Questions? More info?</h2> Several GitLab team</a> and GitLab core team</a> members will be on hand to answer questions and close issues. Please mention them if you need any help or need attention on an issue</p> @markglenfletcher</a></li> @haynes</a></li> @blackst0ne</a></li> </ul> GitLab's Functional Group Updates - April 24th - May 5th 2017-05-11T00:00:00+00:00 Every day from Monday to Thursday, right before our GitLab Team call</a>, a different Functional Group gives an update</a> to our team.</p> The format of these calls is simple and short where they can either give a presentation or quickly walk the team through their agenda.</p> Recordings</h2> All of the updates are recorded using Zoom</a> at the time of the call. All the recordings will be uploaded to our YouTube account and made public, with the exception of the Sales and Finance updates.</p> UX Team</h3> Presentation slides</a></p> </iframe> </figure> CI Team</h3> Presentation slides</a></p> </iframe> </figure> Build Team</h3> Presentation slides</a></p> </iframe> </figure> Support Team</h3> Presentation slides</a></p> </iframe> </figure> Infrastructure Team</h3> Presentation slides</a></p> </iframe> </figure> Frontend Team</h3> Presentation slides</a></p> </iframe> </figure> Prometheus Team</h3> Presentation slides</a></p> </iframe> </figure> Channel Team</h3> Presentation slides</a></p> </iframe> </figure> Questions? Leave a comment below or tweet @GitLab</a>! Would you like to join us? Check out our job openings</a>!</p> Demo - GitLab Service Desk 2017-05-09T00:00:00+00:00 As you expand your software products, GitLab's new Service Desk</a> feature in 9.1</a> enables your growing user base to send emails to your team via a dedicated address per project for any kind of feedback or support.</p> After enabling Service Desk in your project settings, every email sent to the support email address shows up as a confidential issue in your project. Commenting on them generates a response to the original email sender, creating a brand new, integrated user feedback channel right inside GitLab. As Service Desk is built right into GitLab itself, the complexity and inefficiencies of multiple tools and external integrations are eliminated, significantly shortening the cycle time from feedback to software update.</p> Demo</h3> Watch this demonstration of a support workflow using Service Desk, and how you can use other features within GitLab — like creating a “service-desk-tickets” label so that your support team can quickly filter issues within a project.</p> </iframe> </figure> Sign up for a free trial of GitLab Enterprise Edition</a> to see firsthand how it can help your team.</p> GitLab 9.1.3, 9.0.7, and 8.17.6 Released 2017-05-08T00:00:00+00:00 Today we are releasing versions 9.1.3, 9.0.7, and 8.17.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> These versions contain several security fixes, including security upgrades for Mattermost, fixes for several persistent Cross-site Scripting (XSS) vulnerabilities, and fixes for several information disclosure vulnerabilities. We recommend that all GitLab installations be upgraded to one of these versions.</p> Please read on for more details.</p> Security upgrade for Mattermost versions 3.7 and 3.6</h2> Mattermost has not yet released full details, however an important security release was published and Mattermost has advised all users to upgrade immediately. GitLab Omnibus CE+EE versions 9.1 and 9.0 have been upgraded to Mattermost 3.7.5 and GitLab Omnibus CE+EE version 8.17 has been upgraded to Mattermost 3.6.7. #2282</a></p> This upgrade also required the addition of a new Mattermost setting in gitlab.rb</code>. #2286</a></p> Security upgrade for MySQL client libraries</h2> The MySQL client library included with GitLab Omnibus packages has been upgraded to 5.5.56 to patch CVE-2017-3305</a>, a potential man-in-the-middle vulnerability for installations using MySQL over the network. #2311</a></p> Cross-Site Scripting (XSS) vulnerability in project import file names for gitlab_project import types</h2> Timo Schmid from ERNW</a> reported a persistent Cross-Site Scripting vulnerability in the new project import view for gitlab_project import types. This XSS vulnerability was caused by the use of Hamlit filters inside HAML views without manually escaping HTML. Unlike content outside of a filter, content inside Hamlit filters (:css</code>, :javascript</code>, :preserve</code>, :plain</code>) is not automatically escaped. #28325</a></p> Cross-Site Scripting (XSS) vulnerability in git submodule support</h2> Jobert Abma</a> from HackerOne</a> reported a persitent XSS vulnerability in the GitLab repository files view that could be exploited by injecting malicious script into a git submodule. #30527</a></p> Cross-Site Scripting (XSS) vulnerability in repository "new branch" view</h2> A GitLab user reported a persistent XSS vulnerability in the repository new branch view that allowed malicious branch names or git</code> references to execute arbitrary Javascript. #31332</a></p> Cross-Site Scripting (XSS) vulnerability in mirror errors display</h2> While investigating Timo Schmid's previously reported XSS vulnerability in import filenames another persistent XSS vulnerability was discovered in the GitLab Enterprise Edition's (EE) mirror view. This vulnerability was also caused by the misuse of Hamlit filters. #28325</a></p> Potential XSS vulnerability in DropLab</h2> An internal code audit disclosed a vulnerability in DropLab's templating that, while not currently exploitable, could become exploitable depending on how the templates were used in the future. This is a preventative patch. #30761</a></p> Tab Nabbing vulnerabilities in mardown link filter, Asciidoc files, and other markup files</h2> edio</a> via HackerOne</a> reported two tab nabbing vulnerabilities. The first tab nabbing vulnerability was caused by improper hostname filtering when identifying user-supplied external links. GitLab did not properly filter usernames from the URL. An attacker could construct a specially crafted link including a username to bypass GitLab's external link filter. This allowed an attacker to post links in Markdown that did not include the appropriate "noreferrer noopener" options, allowing tab nabbing attacks.</p> The second vulnerability was in the AsciiDoctor markup library. AsciiDoctor was not properly including the "noreferrer noopener" options with external links. An internal investigation discovered other markup libraries that were also vulnerable. #29413</a> / #29374</a></p> Unauthorized disclosure of wiki pages in search</h2> M. Hasbini reported a flaw in the project search feature that allowed authenticated users to disclose the contents of private wiki pages inside public projects. #31157</a></p> External users can view internal snippets</h2> Christian Kühn discovered a vulnerability in GitLab snippets that allowed an external user to view the contents of internal snippets. #30487</a></p> Subgroup visibility for private subgroups under a public parent group</h2> Matt Harrison discovered a vulnerability with subgroups that allowed private subgroup names to be disclosed when they belong to a parent group that is public. #31068</a></p> Versions affected</h3> Mattermost vulnerability:</p> GitLab CE+EE Omnibus (with Mattermost enabled) 7.14-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> Update mysql to 5.5.56 for CVE-2017-3305:</p> GitLab CE+EE Omnibus (with MySQL enabled) All versions up to and including 8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> Cross-Site Scripting (XSS) vulnerability in mirror errors display:</p> GitLab EE 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> Cross-Site Scripting (XSS) vulnerability in project import via GitLab export (file names):</p> GitLab CE+EE 8.3.0-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> Cross-Site Scripting (XSS) vulnerability in repository "new branch" view:</p> GitLab CE+EE 8.13.0-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> Persistent XSS in git submodule support:</p> GitLab CE+EE 6.6.0-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> Potential XSS vulnerability in DropLab:</p> GitLab CE+EE 9.1.0-9.1.2</li> </ul> Subgroup visibility for private subgroups under a public parent group:</p> GitLab CE+EE 9.0.0-9.0.6,9.1.0-9.1.2</li> </ul> Tab Nabbing vulnerabilities in mardown link filter, Asciidoc files, and other markup files:</p> AsciiDoctor: GitLab CE+EE 7.12.0-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> Markdown links: GitLab CE+EE 8.14.0-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> Unauthorized disclosure of wiki pages in search:</p> GitLab CE+EE 8.14.0-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> External Users can view internal snippets:</p> GitLab CE+EE 7.4.0-8.17.5, 9.0.0-9.0.6, 9.1.0-9.1.2</li> </ul> We recommend that all installations running a version mentioned above be upgraded as soon as possible. No workarounds are available for these vulnerabilities.</p> Upgrade barometer</h2> These versions do not include any migrations and will not require downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations 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> What to Look for in a Continuous Integration Tool 2017-05-08T00:00:00+00:00 The advantages of Continuous Integration and Delivery for catching errors while they're still easy to fix and speeding up your time to market are well documented</a>, but even if you're sold on CI/CD, it can be tricky to take the next step. How do you choose the solution that's right for your team?</p> The factors to consider when choosing a CI/CD tool are similar to those of choosing a Git management solution</a>: hosted vs. on-premise, open source vs. commercial, and integrations. You'll also want to look at how easily the tool allows your team to visualize the release process and nip potential issues in the bud.</p> Hosting</h2> Whether you prefer SaaS or to host yourself, you have options. Integrations with third-party services are sometimes easier with a cloud-based service, but some organizations prefer the peace of mind that comes with everything being housed within their walls. Ultimately you need to weigh up what resources you have at your disposal for hosting, and how you want to use them.</p> Open Source vs. Commercial</h2> Using an open source solution has its advantages: it's free, and you can look under the hood and make alterations if needed. Make sure you do your research before committing though: do you need priority access to support? How will you manage if the vendor decides to abandon the product? Are there any features specific to a product that would make things easier for your team? Ask these questions first.</p> Support for Integrations</h2> It's fairly common for an organization's software development lifecycle to rely on several integrated tools (such as issue boards</a> and other discussion features). Find out what your teams are already using and if the CI/CD solution you're considering is supported. There's been growing interest in built-in CI/CD, which means developers can spend less time stringing together their tooling and more on new features and improvements. Bringing all your tools under one product with one interface and datastore is also useful for things like cycle analytics</a>, which can help to reduce the time between coming up with an idea and deploying it.</p> Visualizing the Release Process</h2> One of the advantages of leveraging CI/CD is being able to see changes and new additions from the moment they're created. Does your chosen solution offer Review Apps</a>, so you can automatically check out a live preview of new code? You might also benefit from Deploy Boards</a>, where you can watch a deploy roll out across pods and monitor the health and deployment status of each environment, all in one place. This makes it easier to spot problems and stop or roll back with one click. These are just a couple of features that can make a significant difference to your team's efficiency.</p> So how Does GitLab CI/CD Stack up?</h2> We offer self-hosted</strong> options for both GitLab Enterprise Edition and Community Edition</a> and a hosted</strong> option for GitLab Enterprise Edition Premium on GitLab.com</a>.</p> We have a free and open source</strong> offering, GitLab Community Edition, and two enterprise</strong> offerings, Enterprise Edition Starter and Enterprise Edition Premium, with advanced features such as GitLab Geo</a>, High Availability and Disaster Recovery</a>, File Locking</a> and Service Desk</a>.</p> You can visualize your release process</strong> in all versions of GitLab with GitLab CI/CD Pipelines</a>, Review Apps</a> and Prometheus monitoring</a>. GitLab Enterprise Premium comes with Deploy Boards</a> and Canary Deployments</a> for even more advanced control over deployments.</p> Visit our Products page</a> and Comparisons page</a> to see how GitLab measures against other tools.</p> To learn more about CI/CD and how it can help you release earlier and more often, watch our webcast, "From Continuous Integration to Continuous Everything</a>" on demand.</p> </iframe> “spiral</a>” by Vadim Timoshkin</a> is licensed under CC BY 2.0</a></p> Come See Us at OSCON and GitLab Training in May 2017-05-04T00:00:00+00:00 I'm a Developer Advocate at GitLab, and I'm taking our show on the road to share how your team can use CI/CD. We have several events coming up in May, which gives you several new opportunities to come meet the GitLab team and learn more about what we do!</p> GitLab at OSCON</h2> We'll kick the month off in Austin, TX at OSCON</a>, where you can learn about the software development lifecycle with us. Stop by booth #517 to get a SDLC passport and exclusive GitLab swag.</p> CI/CD Training</h2> In addition to OSCON, we're also offering Continuous Integration and Deployment</a> training in select cities. If you've ever wanted to incorporate CI/CD into your workflow but weren't quite sure how, be sure to attend one of these sessions.</p> Austin, TX on May 9th</a></li> Atlanta, GA on May 22nd</a></li> </ul> Don't see your city? No problem. We're always looking for new cities, so feel free to open an issue</a> for us to come to you.</p> We look forward to meeting you!</p> Inside GitLab’s Code Review Flow 2017-05-02T00:00:00+00:00 Code review, or engineers manually reviewing code as it is being developed, is one of several tools that organizations have to maintain code quality. Having a clean codebase allows developers to quickly build new features, which comes in handy if you find yourself needing to react promptly to the market.</p> Since teams can feel pressed to skimp on code reviews due to deadline pressure, it’s important to create a clear, repeatable process that becomes a habitual part of the workflow. In addition to the business benefits of keeping code quality high, a robust code review process also carries benefits for productivity, like helping share technical knowledge across teams, and looping in the right people during the process instead of at the end. With a tool like GitLab, where the intuitive UI and discussion features make it easy for non-technical people to contribute, code review can also become a mechanism for uniting stakeholders in your organization.</p> While using GitLab to build GitLab, we apply a quality-conscious mindset throughout the development process, sharing the responsibility among everyone instead of seeing review as an obstacle at the end.</p> How We Think About Code Reviews</h3> We review every single change, so nothing is ever committed directly to master, but we think “code review” is too narrow a term for what we do. Software engineers manually reviewing code is just one part of the entire product development process, and is interrelated with many other processes, so it doesn’t make sense to think about them separately. They all move us closer to our desired outcome: awesome features, shipped on a monthly basis, that meet our customer needs and grow our business.</p> Who Is Involved</h3> Our three core teams involved in the process are product managers, designers, and software engineers. All three teams are constantly collaborating and sharing resources; our roles are not strictly defined by our job titles. PMs and designers may write code, engineers may mock up a design, and everyone discusses the features and the product overall.</p> Our Process</h3> We have the benefit of constant dogfooding, or using our own product so as to discover new use cases, test our assumptions, and generally improve GitLab for our users. Loosely, we have a product-design phase, and a code implementation phase. We use GitLab issues</a> to mediate product-design discussions, and GitLab merge requests to mediate code discussions. We encourage “WIP</a>”, or work in progress, merge requests for code collaboration, especially when people with different skills are working together: non-engineers often actively engage in WIP merge request discussions to hash out edge cases and design decisions. Since we ship monthly, we schedule work monthly, and putting up WIP merge requests early helps us plan ahead and adjust the scope when we need to.</p> We generally assign one backend engineer and one frontend engineer to each feature, which is scoped as small as possible to reduce risk and help us move fast. The backend engineer and frontend engineer collaborate in the WIP merge request, and there is at least one reviewer who reviews the code and makes comments. When all comments, bugs, and design questions are addressed, we merge the feature branch into master. All designers, product team members, and engineers typically check out branches themselves and run code in a local or virtual environment to verify features throughout the development process. (This is also the case for our marketing and people operations teams — GitLab's UI makes it simple for non-technical users to get up to speed and start contributing without needing to work from the command line.) Engineers do their own manual and sanity testing, but we use Test Driven Development</a> to catch most errors. We don’t follow a strict Agile flow, instead, we call it Conversational Development</a>.</p> The Benefits</h3> We believe that this approach, which doesn’t segregate code review to the end of the process and entirely burden the reviewer, places responsibility on all of us. If something is broken, it is because we all failed collectively, so we do a retrospective and think about how to fix it. In a very concrete way, code reviews help enforce conventions, consistency, and technical standards among your team. Newer team members can accelerate their education about the product by creating code and then reviewing it critically. A collaborative code review process helps engineering and product teams work closely together to make the best decisions.</p> Watch our webcast, Code Review: A Business Imperative</a> to learn how code review can help you keep up with the market by shipping better features, faster.</p> GitLab Patch Release 9.1.2 2017-05-01T00:00:00+00:00 Today we're releasing version 9.1.2 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> This version resolves a number of regressions and bugs in the 9.1 release</a>.</p> Please read on for more details.</p> CE/EE:</strong> Lazily set UUID in ApplicationSetting for new installations. (!10893</a>/!1733</a>)</li> CE/EE:</strong> Remove description for build_events, add pipeline_events. (!10908</a>)</li> CE/EE:</strong> Resolve "Milestone sidebar display incorect number of MR when minimized". (!10933</a>)</li> CE/EE:</strong> Add index on ci_runners.contacted_at. (!10876</a>)</li> CE/EE:</strong> Fix ordering of commits in the network graph. (!10936</a>)</li> CE/EE:</strong> Skip validation when creating internal (ghost, service desk) users. (!10949</a>)</li> CE/EE:</strong> Refactoring rake task to import GitHub repositories. (!10695</a>)</li> CE/EE:</strong> Accept default branch param on notification services. (!10959</a>)</li> CE/EE:</strong> correct documentation on opt-out-ness of usage ping. (!10945</a>)</li> EE:</strong> Fix commit search on some elasticsearch indexes. (!1745</a>)</li> EE:</strong> Fix bug where Geo secondary Sidekiq cron jobs would not be activated if settings changed. (!1754</a>)</li> EE:</strong> Fix creating issues by email with Service Desk on. (!1743</a>)</li> </ul> Upgrade barometer</h2> This version does not require downtime. It includes two migrations:</p> Fill in missing UUIDs in application settings, which fixes a regression</a></p> </li> Add an index for the column contacted_at</code> in the table ci_runners</code>, which addresses a performance concern</a>.</p> </li> </ol> 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 granted by a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p> Why Code Gets Released too Early (and how to fix It) 2017-04-27T00:00:00+00:00 Code released before it’s ready might be good for meeting deadlines, but that’s about all it’s good for. Most software products today are in a continual state of development, testing and release, so making sure you’re only shipping code that’s truly ready is both challenging and critical.</p> Our 2016 Global Developer Survey</a> asked respondents about how they work, what they work with and what makes their jobs easier (or harder!). They told us resoundingly that between deadline pressure and unrealistic expectations from management, they end up releasing broken or non-functional code all too often.</p> Over Half of Developers Admit to Releasing Code Before it’s Ready</h2> The frequency of shipping incomplete code varies, but an overwhelming 81 percent of developers admitted to releasing code before it’s ready, with an alarming 15.75 percent saying it happens more than half of the time.</p> This isn’t the same as releasing early and often, although the two are easily confused. It’s common practice to release features that are not necessarily polished, with the aim of gathering feedback and improving with the next iteration. However, releasing code that isn’t ready refers to code that is incomplete, not yet fully functional, or hasn’t been tested across all environments. The pitfalls here are obvious: shipping code that’s not finished can break things and result in frustrated customers.</p> Why Does This Happen?</h2> It seems obvious that releasing too early should be avoided, yet it happens all too often. Why? Pressure from senior management and deadlines that must be hit were the top two answers from our respondents, with 38.34 and 58.9 percent each, suggesting a breakdown in communication and mismanaged expectations between senior management and development teams.</p> How to Prevent Premature Releases</h2> Having a robust release management strategy is essential for planning and controlling your software delivery schedule. Leveraging Continuous Integration and Continuous Delivery</a> to ensure your code is always tested and ready to be deployed at a moment’s notice helps to prevent the release of broken code. Adopting DevOps practices to improve communication and collaboration</a> between teams and encourage shared responsibility for each release is another way to ensure that deadlines are realistic and can be met.</p> Also, it might sound counterintuitive, but releasing more often can actually help to prevent premature releases: if you’re shipping once a month instead of twice a year, there’s no reason to rush code that isn’t ready into your upcoming release just to meet a deadline.</p> Download our Global Developer Report</a> to learn more about what developers want and need to do their jobs more efficiently.</p>

GitLab

“Pick Your Brain” Interview with CEO Sid Sijbrandij

GitLab's Functional Group Updates - May 16th - May 26th

GitLab Patch Release: 9.2.2

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

9 Attributes of Successful Development Teams

GitLab Patch Release: 9.2.1

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

GitLab 9.2 Released with Multiple Assignees For Issues and Pipeline Schedules

Fast and Natural Continuous Integration with GitLab CI