GitLab

Why We Chose GitLab CI for our CI/CD Solution

2016-10-17T03:35:00+00:00

At OOHLALA Mobile</a>, our testing and deployment of code is done through Fabric, essentially a set of Python scripts (called “fabfiles”) that are executed on various servers. Recently, we started looking for a CI/CD solution</a> that help manage our fabfile deployment system, which is growing more complex each day. In the end, we went with GitLab CI</a>, and here’s what we found through our experience.</p>

Simple to Use</h2>
Since the bulk of the work is done in Fabric, the CI/CD solution can be very simple, as it only needs to be able to execute fabfiles. GitLab CI’s shell executor is perfect for this. The complexities of other solutions (e.g. Jenkins) are unnecessary for us.</p>
Fast</h2>
We will be using the system for all code deploys, including development and QA environments, so the CI/CD system needs to be fast, to keep up with the fast-paced changes required for development. Primarily Docker based solutions, such as CircleCI, took considerably longer to run due to the dependency set up stage. With GitLab CI, we can set up our own runner with all dependencies pre-installed, and jobs are executed really fast</strong>.</p>
We would like to have a solution that can be installed on arbitrary hardware, specifically our own dedicated macOS and Windows machines that perform our mobile app CI/CD for iOS and Android respectively. The reasoning is that in the future we may use the same CI/CD service for our mobile teams as well. GitLab CI can do this for free, as we can simply install GitLab runners on our dedicated machines. Other CI solutions (e.g. Travis CI, CircleCI etc.) do offer mobile CI/CD solutions, but will not meet our requirements since we need our in-house build and deploy scripts on dedicated hardware to effectively manage the hundreds of mobile apps that we maintain.</p>
Economical and Secure</h2>
The solution should be relatively economical, especially since our development team is still relatively small. Most CI solutions are relatively expensive (e.g. Travis CI starts at $129/month minimum), and the ones that have free tiers are very limited in capacity (e.g. CircleCI and Shippable both allow only 1 concurrent job on their free tier). GitLab CI only costs as much as the machine used to run it, which is very flexible (a $40/month DO instance can run many concurrent jobs without issue).</p>
Ideally (i.e. not a hard requirement), we would like to keep all SSH private keys within our own infrastructure for better security. With most other CI solutions, we would have to hand them the private keys for all the servers we need to deploy to. With GitLab CI, the keys are stored on the CI runner instance, which is hosted by us and fully under our control.</p>
In the end, we actually chose to host our code on GitLab.com</a>, because of the seamless integration with GitLab CI. There weren’t any major differences in features (at least ones that we wanted) in the repository hosting solutions we looked at (GitHub, Gogs, and GitLab mostly), and the CI solution made the choice easier.</p>
About the author</h2>
James Dang is the co-founder the CTO of OOHLALA Mobile</a>, an education technology company building the mobile platform for universities and colleges to connect and engage with their students.</p>

GitLab 8.12.7 released

2016-10-17T00:00:00+00:00

Today we are releasing version 8.12.7 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p>
This version resolves a number of regressions and bugs in the recent 8.12 release</a>.</p>
Please read on for more details.</p>

CE/EE:</strong> Prevent running GfmAutocomplete</code> setup for each diff note. (!6569</a>)</li>
CE/EE:</strong> Fix long commit messages overflow viewport in file tree. (!6573</a>)</li>
CE/EE:</strong> Use gitlab-markup</code> gem instead of github-markup</code> to fix .rst</code> file rendering. (!6659</a>)</li>
CE/EE:</strong> Prevent flash alert text from being obscured when container is fluid. (!6694</a>)</li>
CE/EE:</strong> Fix due date being displayed as NaN</code> in Safari. (!6797</a>)</li>
CE/EE:</strong> Fix JS bug with select2 because of missing data-field</code> attribute in select box. (!6812</a>)</li>
CE/EE:</strong> Do not alter force_remove_source_branch</code> options on MergeRequest unless specified. (!6817</a>)</li>
CE/EE:</strong> Fix GFM autocomplete setup being called several times. (!6840</a>)</li>
CE/EE:</strong> Handle case where deployment ref no longer exists. (!6855</a>)</p> </li>
Omnibus GitLab:</strong> Use forked gitlab-markup</code> gem. (!1015</a>)</li> </ul> Upgrade barometer</h2> This version has no migrations and should not require any downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> file</a>.</p> Updating</h2> To update, check out our update page</a>.</p> Enterprise Edition</h2> Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>.</p> Access to GitLab Enterprise Edition is included with a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p>
GitLab reinstates list of servers that have malware 2016-10-15T00:00:00+00:00 Willem de Groot published a list of web stores that contain malware. He first hosted this list on GitHub but it was deleted. Then he hosted it on GitLab where it was also deleted. The reason we gave him for the deletion was "GitLab views the exposure of the vulnerable systems as egregious and will not abide it.". Willem wrote about his experience in a blog post</a>.</p> At GitLab we strongly believe in responsible disclosure, for examples of this see our policy</a> or Hacker One's guidelines</a>. So publishing a list of servers that are vulnerable or hacked without contacting the owner first and giving them time to remedy the situation is not OK.</p> But in this case the victim of the vulnerability is not only the owner but also the users of the web store. The owners of web stores have a responsibility to their users. And it is in the users interest to have the list published so owners fix their stores</a>. We currently think that the interest of the user weights heavier. Therefore we reinstated the snippet</a>.</p> Willem just tweeted about my phone call to him to apologise</a>. Thanks for that!</p> We applaud Willem's effort to protect users from malware. We'll keep listening and will do our part to make the internet a more secure place for everyone.</p> 30 Fundraising Tips from the CEO 2016-10-14T00:00:00+00:00 How do you raise money for your startup in a climate where it’s increasingly hard to obtain funding? Securing support from the right investors is not only a vital source of money, but is also an opportunity to benefit from their skills, experience, and connections.</p> This post outlines the strategies that have worked for us. Of course, every organization is unique, so these are the tips that have been most beneficial in our own quest to raise funding at GitLab.</p> When Is the Best Time to Raise Money?</h2> Eight quarters of run rate is the best time to raise money for your organization.</strong> This gives you sufficient time to spend as long as you need to plan the deck and meet investors without feeling like time is running out. It means that if you are offered a deal you don’t like, you don’t have to accept it. You have the time to step back from fundraising, get back to stockflow neutral, and not be forced to lay off any employees.</p> </li> Make sure that you have a lot of runway.</strong> This is indicative of how conservative you are financially, so investors will be looking closely at this. You can achieve this by fundraising early. Another strategy is to make sure that your net worth compared to your revenue is low. Don’t make your burn equal to half of your revenue, make it equal to 20% or even 10%.</p> </li> </ol> Organize Your Time Efficiently</h2> Surround yourself with a great team.</strong> Fundraising requires hours of work from everyone in the group. Make sure you can work effectively with everyone on the team and that you will enjoy spending significant amounts of time together!</p> </li> Set aside around three or four months for the fundraising process.</strong> When we went through our first round of fundraising at GitLab, we spent one month on the design phase, one month on the road, two weeks wrapping up with the people that had term sheets, and then one month closing. But, this is extremely fast—most organizations take longer to raise funding. The time consuming element for most organizations is meeting with investors. Some companies can raise funding in just a few weeks, for others it takes months</a>. It’s always best to be prepared for the process to take longer than you expect.</p> </li> As a CEO, you should be prepared to focus solely on fundraising.</strong> There will not be enough time to run the company as well as raise funding. Hire an assistant to prioritize emails and direct your attention towards urgent messages.</p> </li> Try to minimize the amount of time you spend traveling to investors.</strong> This stage can easily last anywhere between three to six months. At GitLab, we decided to spend only four weeks as we wanted to focus on progressing the company, rather than fundraising. This approach to travel is much better for the team’s quality of life because fundraising is very intense. There are a lot of ups and downs, where you can be ecstatic one day because you are connecting with one investor, and frustrated the next day because you have been turned down by another investor. Confining the traveling stage to a relatively short period of time worked best for us.</p> </li> </ol> Put Together the Perfect Slidedeck</h2> Make the deck the sole focus of one team member.</strong> Although content is vital, good design is equally important. Spend some time with designers, whether they work for your company, or whether they are employed by an organization like SketchDeck. The right design will help to clarify and strengthen your message.</p> </li> Spend time working on the pricing chart.</strong> Your pricing chart should be sufficiently detailed and include the relevant information, but the investors have to be able to understand it!</p> </li> Over the course of fundraising, your deck will evolve.</strong> Although you have spent weeks perfecting it and believe it to be a finished product by the time you go out onto the road, you will find that there’s more to add. As you speak to investors, issues are raised that you may not have addressed in sufficient detail, or questions are asked that you might not have considered. It will be necessary to add more slides as you learn more about investors’ interests, expectations, and concerns.</p> </li> If you have an unusual business model, discuss it in your slidedeck.</strong> Investors will ask lots of questions about it, so you want to give them as much information as possible, and ensure they see the advantages of your choice. When we were fundraising, some investors were concerned about our decision to be a remote-only company. Mid-way through fundraising, we wrote a presentation to provide them with information on why being a remote-only organization works so well for us.</p> </li> Don’t include too many slides in the deck.</strong> There is no hard and fast rule, but between 10 and 20 slides</a> will enable you to strike a balance between informing the investors and sharing an overwhelming level of detail. The pitch is your chance to tell investors everything they need to know about your organization, your product and customers, financials, and projections. It’s an opportunity to get them excited and allay any fears they may have.</p> </li> If you get useful feedback, use it.</strong> It doesn’t matter how late in the process you receive it, take the time to incorporate feedback into your fundraising strategy if you feel that it could make a real difference to the funding you secure.</p> </li> Be prepared for the deck to change from series A to series B.</strong> In series B, there will need to be a lot of data relating to sales figures, as the investors will be very interested in this. You will need to share details of the funnel, and where the sales team is meeting its targets. In general there should be less strategy, as you should have consolidated your place in the market by the time you reach this stage.</p> </li> </ol> Preparing for Meetings and Follow Ups</h2> Turn on the TV!</strong> If you really want to know what life is like when you’re in the fundraising bubble, watch Silicon Valley! (But when it comes to the show’s portrayal of investors, just remember that it is a TV show and certain aspects may be amplified!)</p> </li> Check the time.</strong> When you are preparing for meetings and follow-ups, make sure you are always on time.</p> </li> Dress code is not important.</strong> What matters is what you say during the meetings and follow-ups.</p> </li> Don’t go hungry!</strong> Eat something before going into a meeting, especially if you know you don’t perform well when you’re hungry!</p> </li> Have some backup slides for your deck.</strong> We found it useful to create a slide that listed questions we did not yet have an answer for; after the meeting we could find the answer, then follow-up with the investor and add it to the slidedeck for future presentations if we felt it would be helpful. When you’re preparing your slidedeck, there will always be content that you’re not certain will be required, but could still be informative for the investor; these slides should go in the backup set. If and when you need the information, you can switch to that slide easily.</p> </li> It can be hard to keep the meeting on track.</strong> The investors will start asking questions based on the content in your slidedeck. It is possible to skip ahead to the relevant slide, then go back to resume the presentation, but this can get confusing and you will lose the flow of the presentation. It is best to acknowledge the investor’s question and let them know that this will be dealt with later in the slidedeck.</p> </li> There should be someone on your team who is not presenting.</strong> Their role is to write down the questions, so you can follow up after the meeting. If possible or relevant, add this information to your presentation.</p> </li> Keep a list of when you last spoke to each investor.</strong> If they are silent for a few days, then it’s important to follow up to find out why. If they don’t respond to your first message, ask if they are still interested in potentially investing in your organization. There are generally three reasons behind this: They are not interested</li> They may have been too busy to reply, but are still interested</li> They are keeping their options open. Whatever the reason, you need to find out so you know who you should focus your attention on.</li> </ul> </li> Ask permission from the venture capitalists to record one of your pitches.</strong> There is a lot of mystery surrounding what goes on in a pitch—this is your chance to help others.</li> </ol> Familiarize Yourself with Financial Terminology</h2> Prorata rights.</strong> Prorata rights can be one of the most contentious aspects of investment, so make sure you understand it. Any lead investor will want a certain percentage of your company. For the A round it’s usually around 20%, for B round it’s 15%, and for C round it’s 10%. They need that much of the company to make it worth their time and effort investing.</p> Prorata investment rights allow investors the right to keep their percentage of their share of the company the same when you start the next fundraising round. During the second (or third) fundraising round, all existing shareholders get diluted; these investors can invest more money so they maintain the same percentage. This is what it means when you hear about investors ‘doing their prorata’. Super prorata is what happens if the investors want to increase their ownership percentage in the next round. If you would like to learn more on prorata, this post</a> is helpful.</p> </li> Super prorata rights are not founder-friendly.</strong> Firstly, what do we mean by ‘founder-friendly’? These are terms that do not give too much leverage to the investors. Instead, the CEO will be given the freedom to make decisions. If an investor asks to use super prorata rights, they want to increase their percentage ownership in the next funding round. This is not founder-friendly because it might make it difficult for you to secure funding from new investors, as there isn’t a significant percentage of the company left for them to invest in.</p> </li> </ol> How to Find the Right Investor and / or Boardmember</h2> Ask yourself whether a potential investor is the right fit for your board of directors.</strong> If someone is prepared to invest in your organization, that is extremely flattering, but it important to consider whether they believe in your vision and whether they can help you meet the challenges ahead.</p> </li> It isn’t easy to raise money in an economic climate where less investors are keen to invest.</strong> But, whatever the climate, you will be valued on more than 10 or 20 eighths of your sales - this is to your advantage, as it means that you can give clearly demonstrate your company’s success and potential. Market forces (such as what similar deals are being priced at, the competitors in your sector and how your company is different) will affect the valuation of your company. You can’t change this, but you can control how you present your own organization to investors.</p> </li> Show investors that you have disrupted the market.</strong> Being the market leader is good, and certainly what you must aspire to be, but as a startup it is not always possible. You want to demonstrate to investors that you are innovative, you have the drive to make your organization the best, that you have a better strategy, and, ultimately, the best product.</p> </li> The right investor is more important for your company than the valuation.</strong> That’s not to say the valuation of your organization isn’t important, but it’s important that you don’t miss out on the best possible investor who great connections and a wealth of knowledge, for a relatively small sum of money.</p> </li> Know what you’re looking for in a board member.</strong> As well as acquiring some funding for your company, another reason for fundraising is to find a great board member. You have to be able to work well with your board member because you will be working together for many years to come. They have to be intelligent, ethical, hardworking, and well connected in the industry. Many times, a board member will be used to close somebody who is considering joining the company. Their strategic outlook and understanding of your industry will give you confidence in their abilities to be a real asset to your organization.</p> </li> Know the difference between what round A and round B investors are looking for.</strong> Round A investors will be looking at your prototype, traction, and management team. Their terms will be more founder-friendly, as they know that subsequent terms will be increasingly investor-friendly. In the B round of fundraising, investors will be scrutinizing your metrics, sales, and conversion rate will be scrutinized.</p> </li> </ol> A good series B investor will reach out to the existing board members. They will also want to know whether the A round investors will take advantage of their prorata. The terms of investment for the B round will not only have to be acceptable to the company, but also the investors, so make sure your current investors are happy with these.</p> If you have any insights on fundraising, share them with the GitLab community. Start the discussion below.</p> GitLab 8.12.6 released 2016-10-12T02:35:00+00:00 Today we are releasing version 8.12.6 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> Version 8.12.6 contains a fix for the mail_room package not being included in the package. This update is only necessary for users who use mail_room for Reply by email.</p> Please read on for more details.</p> CE/EE:</strong> Update mail_room to 0.8.1 in Gemfile.lock (!6814</a>)</li> </ul> Upgrade barometer</h2> This version has no migrations and should not require any downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> file</a>.</p> Updating</h2> To update, check out our update page</a>.</p> Enterprise Edition</h2> Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>.</p> Access to GitLab Enterprise Edition is included with a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p> Automated Debian Package Build with GitLab CI 2016-10-12T00:00:00+00:00 This post is a customer story by Adfinis SyGroup</a>.</p> We've decided to use GitLab CI</a> to build Debian packages automatically. GitLab CI allows users to execute tasks based on definable events, such as Git tags.</p> We've created a generic Docker container which contains the base package-building tools and is used by GitLab to build the package. Updates can be easily installed in the build environment, since the Docker container can be simply replaced with a new one.</p> The following shows the automated packaging of the GoAccess</a> log analysis tool. Many tools are not packaged in their latest version and thus have to be created manually.</p> Prepare the Debian Package</h2> First, the files which control the building of the Debian package are created. In the case of GoAccess, these are:</p> debian/changelog # Changes to the package and software </span> debian/compat # Compatibility level for debhelper </span> debian/control # Package-specific information such as dependencies and description </span> debian/rules # Instructions for debhelper </span> </code></pre> Debian themselves already offer detailed documentations</a> to simplify the introduction to packaging.</p> Prepare the Docker Container</h2> On a host system, a container must be prepared in which a package can then be built. Start by creating a Dockerfile</code>:</p> FROM</span> debian:wheezy </span> ADD</span> setup.sh /opt/ </span> RUN </span>/bin/bash /opt/setup.sh </code></pre> In the Dockerfile</code> (official documentation</a>) is indicated which base image is to be used. In this case, it's Debian Wheezy. After that, the setup.sh</code> script is copied into the /opt/</code> directory of the container. In setup.sh</code>, the mirror which is going to be used is configured, and the most basic dependencies are installed, which can be used in any build:</p> #!/bin/sh</span> # change to our own mirror</span> echo</span> "deb http://pkg.adfinis-sygroup.ch/debian/ wheezy main non-free contrib"</span> > /etc/apt/sources.list echo</span> "deb http://security.debian.org/ wheezy/updates main"</span> >> /etc/apt/sources.list echo</span> "deb http://pkg.adfinis-sygroup.ch/debian/ wheezy-updates main contrib non-free"</span> >> /etc/apt/sources.list # requirements</span> apt-get update apt-get -y install git dh-make build-essential autoconf autotools-dev </code></pre> As soon as these files have been prepared, we can build the Docker container:</p> docker build -t generic-package-build-runner:v1 </code></pre> The container is now created and ready for use.</p> Configure GitLab CI</h2> Now, the prepared Docker container has to be registered for the current project</a>, in which a package is to be built:</p> gitlab-ci-multi-runner register \</span> --non-interactive \</span> --url "</span>$(</span>GITLAB_URL)</span>"</span> \</span> --registration-token "</span>$(</span>CI_TOKEN)</span>"</span> \</span> --description "Generic debian wheezy package build runner"</span> \</span> --executor "docker"</span> \</span> --docker-image "generic-package-build-runner:v1"</span> </code></pre> The GitLab URL and the CI token can be found in the GitLab project on the page Settings</strong> > Runners</strong>. Each project has its own CI token.</p> In order for GitLab CI to know which commands in the container should be executed, the file .gitlab-ci.yml</code></a> is created within the repository.</p> # Is performed before the scripts in the stages step</span> before_script</span>:</span> -</span> source /etc/profile</span> # Defines stages which are to be executed</span> stages</span>:</span> -</span> build</span> # Stage "build"</span> run-build</span>:</span> stage</span>:</span> build</span> script</span>:</span> -</span> apt-get install -y libncurses5-dev libglib2.0-dev libgeoip-dev libtokyocabinet-dev zlib1g-dev libncursesw5-dev libbz2-dev</span> -</span> autoreconf -fvi</span> -</span> cp COPYING debian/copyright</span> -</span> dpkg-buildpackage -us -uc</span> -</span> mkdir build</span> -</span> mv ../goaccess*.deb build/</span> # This stage is only executed for new tags</span> only</span>:</span> -</span> tags</span> # The files which are to be made available in GitLab</span> artifacts</span>:</span> paths</span>:</span> -</span> build/*</span> </code></pre> The most important part of this file is the run-build</code> stage. This part defines which actions are executed, when they are executed and the locations of the files created in the build.</p> Since a generic Docker container was created, the necessary dependencies have to be installed in the first step.</p> After that, the building procedure is prepared with autoreconf</code>. Among other things, this results in the creation of the Makefile, which is indispensable for the build. Since we're using the copyright from the package, we'll copy it to debian/</code>.</p> The building process is then started with the command dpkg-buildpackage</code>. The package is compiled and the Debian package is created. These packages are then moved to the build</code> directory that was created and uploaded to GitLab.</p> Workflow</h2> As soon as we have a new release, a Git tag is created. This Git tag starts a new build in GitLab, which builds the package using the latest version. The package that is created will then be made available in the web interface of GitLab, where it can be downloaded.</p> </p> Outlook</h2> Ideally, the packages or artifacts built should be processed automatically, for example by uploading them to a mirror. In our case, we're using a bot which, when instructed by a GitLab Webhook</a>, downloads the artifacts onto a target server, adds them to a Aptly repository and publishes the repository, such that the process can be fully automated from package build to publication</a>. The final result can be freely viewed on our Aptly mirror.</p> This post was originally published</a> by Adfinis SyGroup</a>.</p> GitLab 8.12.5, 8.11.9, and 8.10.12 released 2016-10-11T18:20:00+00:00 Today we are releasing versions 8.12.5, 8.11.9, and 8.10.12 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> Version 8.12.5 contains two security fixes for GitLab, plus fixes for minor regressions. Versions 8.11.9 and 8.10.12 only contain the security fixes.</p> Please read on for more details.</p> CE/EE:</strong> Switch from request to env in ::API::Helpers. (!6615</a>)</li> CE/EE:</strong> Update the mail_room gem to 0.8.1 to fix a race condition with the mailbox watching thread. (!6714</a>)</li> CE/EE:</strong> Improve issue load time performance by avoiding ORDER BY in find_by call. (!6724</a>)</li> CE/EE:</strong> Add a new gitlab:users:clear_all_authentication_tokens task. (!6745</a>)</li> CE/EE:</strong> Don't send Private-Token (API authentication) headers to Sentry</li> CE/EE:</strong> Share projects via the API only with groups the authenticated user can access</p> </li> Omnibus GitLab</strong> Update the storage directory helper to check permissions for symlink targets. (!1028</a>)</li> </ul> Private tokens sent to Sentry</h2> This vulnerability only affects GitLab instances that use Sentry exception tracking. This feature is off by default in GitLab.</em></p> As a GitLab administrator you have the option to integrate your GitLab instance with Sentry, an external exception tracking system. When this feature is enabled, you can see details of each error ('500 page') that occurs on your GitLab server. These details include HTTP headers of the request that experienced the exception. Prior to GitLab 8.12.5, when an exception occured in the GitLab API (a URL starting with /api/v3/</code>), GitLab would inadvertently send the Private-Token</code> header used to authenticate with the GitLab API in the error report to Sentry. This meant that when you viewed a Sentry error report for an exception that occurred during a GitLab API request you could see the Private token of the user that performed the request. This also meant that if there is a data breach at your Sentry server, GitLab user private tokens may be exposed.</p> The holder of the private token for a GitLab user can impersonate that user in GitLab via the API. That includes writing comments, adding SSH keys, creating repositories. The holder of the private token of a GitLab administrator is able to do much more, for instance creating new user accounts. See #22537</a> for more information.</p> Mitigation</h3> Even though private tokens are not sent to Sentry starting with GitLab 8.12.5, the tokens are valid forever as long as they are in the GitLab database.</p> That's why we strongly</strong> advise you to invalidate all your users' Private tokens with the following Rake task</a>:</p> # omnibus-gitlab sudo gitlab-rake gitlab:users:clear_all_authentication_tokens # installation from source bundle exec rake gitlab:users:clear_all_authentication_tokens RAILS_ENV=production </code></pre> New tokens will automatically be issued once users sign-in.</p> As a less secure alternative (or as an additional precaution), you can also clear the exception history for your GitLab instance in Sentry</a>.</p> Note: At any time, individual GitLab users can reset their private token on their Account</code> page (/profile/account</code>).</p> Information disclosure via the "Share project with group" API endpoint</h2> The new implementation of the "Share project with group" API endpoint allowed projects to be shared with groups that the current user wasn't allowed to see, leaking the group name and the name of its owners. See #23004</a> for more information.</p> Upgrade barometer</h2> This version has no migrations and should not require any downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> file</a>.</p> Updating</h2> To update, check out our update page</a>.</p> Enterprise Edition</h2> Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>.</p> Access to GitLab Enterprise Edition is included with a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p> To Wrap or Not to Wrap: One of Life's Greatest Questions 2016-10-11T00:00:00+00:00 Whether and how we should be making line breaks is currently a controversial topic amongst the GitLab folks; it's an issue of style as well as ease of use. In this post, we’re presenting the two current views held, and giving you the opportunity to speak your mind (in the comments or on Twitter</a>) about how we should handle this in our style guide</a>.</p> The current policy laid out in the style guide is that you should:</p> Split up long lines, this makes it much easier to review and edit. Only double line breaks are shown as a full line break in GitLab markdown</a>. 80-100 characters is a good line length.</em></p> </blockquote> The understanding is that you if you create a line break after 80 characters, the text becomes easier to review.</p> However, quite a few people feel that this isn't helpful and creates stylistic and/or visual messiness when, for example, edits are made which cause the line breaks to go amok. Basically, there are two options if your line exceeds 80 characters:</p> Wrap the text as the author of the code.</li> Rely on the reviewer to wrap the text with their local editor, and insert a new line for every sentence.</li> </ol> DON'T WRAP IT.</h2> Some of us at GitLab are in the don’t-wrap camp, positioning that it’s better to rely on the reviewer. If you modify text, you don’t want to have to realign the rest of the text when edits are made because the line breaks are uneven. Rewrapping requires a feature that some editors (including GitLab) don’t have. Some people might have it but not know they have it, or not know where to find it in their editor. If you do rewrap with your editor, the diff might get messy and make it hard to work out what's visually changed. Plus, that 80- to 100-character limit is more of a guess than an exact limit. It can be different depending on your editor/screen size.</p> This is how a paragraph looks like after a few reviews when you choose to wrap the text. It's odd, as it has long lines and short lines distributed unevenly:</p> </p> However, when you don't wrap it, a collaborator needs to point to the portion of the text before explaining the change, which can be very time consuming. For example, in the paragraph below, the collaborator needs to identify the link first, and repeat the section with the proposed changes:</p> </p> DO WRAP IT.</h2> The company's official position is of the do-wrap variety</em>, with the main reason that when people view and edit the text, they can do so without scrolling horizontally ad infinitum</em>, which drives some people nuts. As a result, the comment box sometimes extends beyond the edge of the viewport, making it difficult to use any of the buttons on the right-hand side.</p> To compare to the last example, the following screenshot of a text already wrapped, it's easy to comment inline directly, without having to identify what you're talking about first and commenting afterwards.</p> </p> Comparing Similar Views</h2> When editing a file in the GitLab UI, this is how wrapped text looks like:</p> </p> And this is how an unwrapped code looks like:</p> </p> Even when you're reviewing locally, check how a wrapped text looks like on Sublime:</p> </p> And how it looks when unwrapped:</p> </p> Clearly, wrapped text can be considered better for both reading and reviewing through inline comments. But it can also be annoying when writing and editing the file.</p> Going forward</h2> Particularly, while I'm writing, I don't wrap the text. I'll do that just when it's ready for review. This way, I save myself some time when writing and editing, but I still leave it wrapped for facilitating the reviewers to add inline comments in my merge request.</p> But yes, there are pros and cons for both cases, of course. The question is, what can we do to make it less painful for everyone?</p> One of the possible actions we could take going forward is to set a max-width both on the comment box container, and on the editor, so that it remains in a usable state, regardless of code length.</p> Other ideas? We’re open to them. Let us know what you think, and how you do that with your team.</p> Note</strong>: Currently for blog post technical articles we follow the Style Guide, but the Blog Post Style Guide</a> is an override or addendum to that. The consensus has been that wrapped text facilitates review. We have a lot of guest writers and many reviewers, and this seems to be their preference, so we’ve tried to honor that.</p> GitLab 8.12 Release Webcast: Cycle Analytics & Global Code Search 2016-10-07T00:00:00+00:00 In the GitLab Master Plan</a>, we promised to ship the entire development lifecycle before the end of the year. GitLab 8.12</a> is exciting because it brings us one step closer to realizing our vision</a> to be an integrated set of tools for the software development lifecycle.</p> In this release, we launched the first iteration of Cycle Analytics</a>. Cycle Analytics gives you feedback on your projects, measuring how long it takes your team to go from idea to production. Cycle Analytics helps you reduce cycle time, an important competitive advantage in today's development landscape. In fact, reducing cycle time to increase effectiveness is the very first principle of Conversational Development</a>.</p> We also launched Global Code Search</a> for GitLab Enterprise Edition (EE). If you're running Elasticsearch on your GitLab EE instance, you can now search through all the code on your server.</p> In this webcast, we walk through our vision, and demo some of the key features from GitLab 8.12</a>.</p> In this webcast:</h2> Introduction to GitLab and our vision</li> Why Cycle Analytics?</li> Introduction to Cycle Analytics</li> 8.12 Feature Release Demo</li> What’s next</li> Q&A</li> </ul> Recording & Slides</h2> </iframe> </figure> </p> </iframe> </figure> Key Takeaways</h2> In case you don't have time to watch the full video, here are the highlights.</p> GitLab Built-in Integrations</strong></p> GitLab has an integrated set of tools that supports the entire lifecycle of software development, including repository management, version control, code review, advanced issue tracker, Issue Board, built-in Continuous Integration, Continuous Deployment, Continuous Delivery</a>, and wiki, and now, Cycle Analytics</strong>.</p> </div> </div> Faster From Idea to Production</strong></p> Our goal is to help teams go faster from idea to production</a> by building a completely integrated toolset in a single UI.</p> </div> </div> 10-Step lifecycle</strong></p> We will ship this complete lifecycle in 2016.</p> Chat conversation → Mattermost ships with GitLab</a></li> Issue creation → GitLab Issues</a></li> Planning board → GitLab Issue Board</a></li> IDE → Koding + GitLab</a> Integration</li> Version control → GitLab Repositories</li> Continuous Integration → GitLab CI</a> and GitLab Container Registry</a></li> Code review → GitLab Merge Requests</li> Continuous Delivery → GitLab Deploy</a></li> Chatops → We're planning to ship Cog</a></li> Feedback → Cycle Analytics</a></li> </ol> </div> </div> New features</strong></p> Cycle Analytics</a>, Global Code Search</a>, and Merge Request Versions</a> are awesome features and you should really check them out.</p> </div> </div> Amplify Your Code at GitLab World Tour</h2> Join us for the GitLab World Tour</a> to learn more about our product vision, talk about changes in software development, and meet other GitLabbers in your area! We'll be in three cities:</p> Register for an event near you:</p> London</a> - October 19</li> NYC</a> - October 26</li> Amsterdam</a> - November 3</li> </ul> GitLab 8.12.4 released 2016-10-05T00:00:00+00:00 Today we are releasing version 8.12.4 for GitLab Community Edition (CE) and Enterprise Edition (EE).</p> This version contains two security fixes for GitLab, plus fixes for minor regressions and bugs in the recent 8.12 release</a>.</p> Please read on for more details.</p> EE:</strong> Indexer works with smaller batches of repositories to not exceed NOFILE limit. (!774</a>)</p> </li> CE/EE:</strong> Fix tooltip text when Copy to cliboard is clicked. (!6294</a>)</li> CE/EE:</strong> Fix build sidebar build details padding. (!6506</a>)</li> CE/EE:</strong> Changed compare dropdowns to dropdowns with search input. (!6550</a>)</li> CE/EE:</strong> Fix race condition on LFS Token. (!6592</a>)</li> CE/EE:</strong> Fix bug when trying to cache closed issues from external issue trackers. (!6619</a>)</li> CE/EE:</strong> Fix lint-doc error. (!6623</a>)</li> CE/EE:</strong> Skip wiki creation when GitHub project has wiki enabled. (!6665</a>)</li> CE/EE:</strong> Fix issues importing services via Import/Export. (!6667</a>)</li> CE/EE:</strong> Restrict failed login attempts for users with 2FA. (!6668</a>)</li> CE/EE:</strong> Fix project deletion when feature visibility is set to private. (!6688</a>)</li> </ul> Further improvements for security of Import/Export projects.</h2> Prevented access to foreign entities using the Import/Export functionality. This could be achieved altering the foreign key IDs in the project JSON of an exported GitLab project file. The foreign keys are now always being ignored at the time of importing a project. See #20821</a> for more information.</p> Exported projects were world-readable in the filesystem</h2> Exported projects are no longer world-readable in the GitLab server filesystem as permissions are set to owner access only. See #22757</a> for more information.</p> Upgrade barometer</h2> This version has no migrations and should not require any downtime.</p> Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> file</a>.</p> Updating</h2> To update, check out our update page</a>.</p> Enterprise Edition</h2> Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>.</p> Access to GitLab Enterprise Edition is included with a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p> YC application office hours 2016-10-03T00:00:00+00:00 Following our blog last Friday about What Founders Ask Founders About Getting Into Y Combinator</a> we got a lot of responses through HackerNews</a> to have Sid, our CEO, read through people's application. Sid figured talking in person would be way easier than leaving comments and we set up some office hours during the weekend and today to help founders applying with making their application as clear as possible.</p> With the blog post trending on the HackerNews homepage</a> last Friday, a lot of applicants wanted to know if their answers were clear and concise; like Sid advised in our blog. During the office hours and a few one-on-one meetings Sid read and talked through the application form answers and asked questions and discussed what applicants could improve.</p> Below are a few examples of the calls Sid did over the weekend. We posted the recordings on our YouTube account so everyone can have a look at the advice mentioned and hopefully adjust the last few details before sending in their own application</a>.</p> Color Search</a> lets you choose a paint color online, and TrueJob</a> is a data-driven startup job search. Both company founders have graciously agreed to let us post their call with Sid to help out other founders.</p> Below is the video of Sid's call with Color Search and they also shared their application form</a>.</p> </iframe> </figure> </p> TrueJob also sent us a link for their application form</a> and their call with Sid is below.</p> </iframe> </figure> </p> Good luck to both company founders.</p> GitPitch Slideshow Presentations for Developers on GitLab 2016-10-03T00:00:00+00:00 Today I would like to introduce GitPitch</a>, a slideshow presentation service for developers on GitLab</a>. GitPitch supports building, sharing, and presenting online and offline slideshow presentations. Presentations powered entirely by Markdown and Git.</p> As developers and advocates, we often need to communicate with diverse audiences about our code. We find ourselves needing to present everything from designs and best practices, to code snippets and complete frameworks. Our audiences include colleagues, clients, customers, end-users, and sometimes meetups and conferences.</p> With GitPitch, we no longer need to turn to external toolsets like Keynote or Powerpoint to prepare for these kinds of presentations. In fact, now the only tools we need are the tools we live in, our preferred code editor and a GitLab repo. And with these tools we can quickly create compelling, responsive, online and offline slideshow presentations.</p> </p> How GitPitch Works</h2> As GitLab users, we are already familiar with the convention of adding a README.md</strong> to our projects. GitPitch introduces a new convention for GitLab users, called PITCHME.md</strong>.</p> As soon as we add a PITCHME.md</strong> markdown file to the root directory of our GitLab.com project, GitPitch instantly creates an online slideshow presentation based on the content in that file. That slideshow presentation is then automatically made available at its public URL:</p> https://gitpitch.com/user/project/branch?grs=gitlab </code></pre> Here user</code> and project</code> matches our GitLab.com user and project names respectively and branch</code> matches the repository branch where we commited our PITCHME.md</strong> file. Note, the /branch</code> can be omitted from the slideshow URL if we are referencing the master</code> branch.</p> GitPitch In 60 Seconds</h2> To experience just how simple it is to create a GitPitch slideshow presentation follow along with this short tutorial.</p> Step 1: Create PITCHME.md</strong></h3> Using the GitLab web editor</a>, or your preferred code editor, create a file called PITCHME.md</strong> in the root directory of your repo, then add and save the following Markdown content:</p> # Flux An application architecture for React #HSLIDE ### Flux Design - Dispatcher: Manages Data Flow - Stores: Handle State & Logic - Views: Render Data via React #HSLIDE ![Flux Explained](https://facebook.github.io/flux/img/flux-simple-f8-diagram-explained-1300w.png) </code></pre> Before moving on to the next step it's worthwhile to note the following:</p> The PITCHME.md</strong> file name is case sensitive.</li> The PITCHME.md</strong> file content is standard Markdown</a>.</li> The #HSLIDE</code> markdown fragment acts as a delimiter between slides.</li> </ol> Using #HSLIDE</code> is another GitPitch convention, acting as a delimiter to denote the separation between content on different slides in your presentation. You can use custom delimiters</a> if you prefer. For this example, when GitPitch processes the Markdown content it will result in a simple presentation with just three slides.</p> Step 2: Commit PITCHME.md</strong></h3> If you used the GitLab web editor in step 1 then go directly to step 3. Otherwise, manually add this file to the root directory of your Git repo and push to GitLab:</p> git add PITCHME.md git commit -m "Added my first GitPitch slideshow content." git push </code></pre> Step 3: Done!</h3> Your GitPitch slideshow presentation is now waiting for you to share or present at its public URL. To see a live demonstration of this slideshow presentation click here</a>. Your own presentation should look a lot like this:</p> </p> Immediately you can download</a> your slideshow for offline presentation, print</a> it as a PDF document, or share</a> it on social media. But first, you might want to apply some personal touches using GitPitch customization, the topic we'll look at next.</p> Note that beyond support for standard Markdown on presentation slides, GitPitch delivers a number of features tailored for developers, including support for code blocks</a>, GitHub GIST</a>, math formulas</a> along with image</a>, and video</a> support. The full set of GitPitch features are documented on the GitPitch Wiki</a>. To see a live slideshow demonstration of these features try out the GitPitch Kitchen Sink</a>.</p> GitPitch Customization</h2> As with any presentation, a GitPitch presentation not only needs to capture and render compelling content, it also needs to be able to reflect the style, image or brand of the associated project, product or organization. To help us develop a strong visual identity for our slideshow presentations, GitPitch offers six distinct visual themes out-of-the-box. See the GitPitch Themes</a> Wiki page to learn more.</p> </p> Building on these base themes we can further customize the look and feel</a> of our slideshow presentations using background images, our own logo, and even custom CSS to bend the pixels to our needs.</p> </p> GitPitch and GitLab Workflow</h2> The PITCHME.md</strong> markdown for our slideshow presentation becomes just another file in our GitLab project repo. Therefore all of the benefits we currently enjoy when working with GitLab Workflow apply equally when developing our slideshow presentations.</p> Given GitPitch can render a slideshow presentation for any branch within a public GitLab repo, using feature branches also offers an excellent way to customize a presentation's content for different target audiences. For example:</p> Branch to tailor code snippets for a Scala rather than Java audience.</li> Branch to adjust the presentation focus for a dev-ops audience.</li> Branch to emphasize participation of a partner or customer for a specific conference.</li> </ol> Some common, in-person workflows are also greatly improved when working with GitPitch presentations. For example, how often have you heard this simple request following a successful presentation:</p> Can you please send me your slides?</p> </blockquote> If our presentation lives outside of our GitLab project it is very easy to misplace or forget to follow up. With GitPitch, a simple answer is always at hand:</p> The slideshow presentation is part of the project on GitLab, just click on the GitPitch Badge</a> found in the project README.md</strong>.</p> </blockquote> Going Faster from Idea to Presentation</h2> GitLab champions new, modern development tools and practices that foster collaboration and information sharing to help developers go faster from idea to production</a>. GitPitch embraces and extends this approach by helping individuals, teams and organizations to promote, pitch and present their ideas and code to ever wider audiences.</p> Note, by default the GitPitch service on GitPitch.com</a> integrates with GitLab.com</a>. If you are interested in using GitPitch with your own GitLab server see this note</a> on the GitPitch Wiki.</p> Like GitLab, GitPitch itself is an open source project</a>, built on some wonderful open source software. See the GitPitch website</a> for details. And remember, getting started couldn't be easier. GitPitch requires no sign-up. And no configuration. Just add PITCHME.md</strong> ;)</p> About Guest Author</h2> David Russell is a freelance developer, consultant for-hire, open source contributor</a> and the creator of GitPitch</a>. You can reach David on Twitter @gitpitch</a>.</p> What Founders Ask Founders About Getting Into Y Combinator 2016-09-30T10:31:00+00:00 Update: There is a followup post about the YC application office hours</a> as a response to this post.</p> You’ve got a great idea and feel you can make a great company and product out of it. You’ve worked on a basic version and feel like you’re ready to enter the big leagues.</p> Maybe the accelerator program of Y Combinator is a good idea? But you’ve got so many questions. When are you ready for the next step? How can Y Combinator help you? What are some tips or tricks to get in and what should you highlight in the application process?</p> The deadline to apply</strong></a> for the Y Combinator program is Tuesday October 4th 2016 by 8pm PT</strong>.</p> In combination with the blog post we released the application of GitLab to YC</a> as an example. Below some questions that Reinder Visser from Placker</a> asked Sid about applying at Y Combinator a few days ago.</p> Reinder: Why should I apply?</h4> Sid:</strong> The reason we applied for Y Combinator with GitLab was that we had lost our first customer mid 2014. The customer explained that while they liked GitLab they were standardizing on an alternative solution. Dmitriy and I figured every company would standardize on one solution to do innersourcing</a> and we wanted that solution to be GitLab. The need to grow faster became the main reason to apply since there was a window of opportunity of a couple of years before people would standardize on one tool and be decided.</p> We feel that the time to apply for Y Combinator is when you have mainly outlined your product vision, you’re still working somewhat on the market, and are still trying to figure out how to sell it, and how to scale to accommodate your customers. The Y Combinator program is ideal when you have a solid team of founders that have been working together for a while but you are ready to hire the rest of the team after you complete the Y Combinator program.</p> Reinder: So why choose Y Combinator if there are more than 2000 accelerator programs in the world?</h4> Sid:</strong> We feel that Y Combinator has the best network, the best partners, the best advice to give you because they see the most companies, and they are very strong at selecting them. Going where the other strong applicants are, you will have a program where they have the largest set of data to offer you advice. Investors have noticed the Y Combinator pattern which helps you raise funding under better terms with better investors. Our Y Combinator experience exceeded our high expectations.</p> Reinder: Is it a problem that I'm a single founder?</h4> Just last week Craig Cannon posted an article on the most common misconceptions about applying for Y Combinator</a>. A concern people have sometimes is being a single founder, which is addressed in this article. While Y Combinator does suggest having a cofounder</a> because startups are hard and cofounders definitely help, of the Summer 2016 batch, 8.5% had a solo founder. Here’s how the rest breaks down: 2 Founders (61.3%), 3 Founders (20.8%), 4 Founders (7.5%), 5+ Founders (1.9%). It may feel like being a single founder would make it harder to get the same load of work done, where it’s not so much that Y Combinator will be hard on your own, running a company on your own will be too.</p> Reinder: If you decide to apply, how do you get in?</h4> Sid:</strong> Take your time working on your answers for the application. Apply ahead of the deadline and don’t wait until the last minute if you can. But even last minute and late applications get a fair review so feel free to sleep on it. Describe what your company does and why it’s unique. Be concise and opt for simple descriptions with the use mundane language, because a main reason why you get declined is that a reviewer doesn’t understand you business. Have other people review your application. Then ask them “what does my company do”? and write down their answer. Take that answer they have given you and use it to improve your description. Writing down what your company does is one of the hardest things, and if you don’t agree with their answer than your first answer wasn’t clear enough.</p> Everyone feels their product is is better, faster, easier, so get down to specifics why you feel that way but keep it simple. If people can’t recite back to you what it is you do and why you’re different, you have to change your answers. There are a few question in the application that are of high importance to highlight you as a founder, one of them being: “Please tell us about the time you most successfully hacked some (non-computer) system to your advantage.” Don’t gloss over any questions but this one in particular is important. Choose answers or situations that show you’re an independent thinker and are creative. When you get invited to do a 10 minute interview after you’ve sent in your application make sure to prepare for the interview in detail. They will ask you questions which are to be found on the internet so make sure to write down your answers and practice those. Your answers need to be concise and clear, when they are too long you will get cut off. I had someone ask me the questions over and over and interrupt me if my answer was longer than one breath.</p> Reinder: So spill the beans; what’s it like?</h4> Sid:</strong> Y Combinator raises your ambition level; everyone is motivated by the feeling of progress, and that’s what fast growth gives you. You’re in a batch with the best people in the world, it’s a form of healthy peer pressure that motivates you to work harder and set that high pace to keep developing your product. The first thing they ask you to do is launch, in case you haven’t done that yet. Y Combinator teaches you not to want your feature or product to be a certain way before shipping. Ship today, and make it better or nicer over time. As soon as it’s live you’ll have more information and data on what the real problems are. Figuring out who your ideal customers are, how to reach them, how to raise your financing, how to hire people, these are questions that everyone in the program has. The team of Y Combinator is really good at helping you to answer these questions, both during and after the 3 month prgram. But the best part are the other founders, they are all interesting people and I'm very glad to call some of them my friends.</p> GitLab's Application for Y Combinator Winter 2015 2016-09-30T10:30:00+00:00 We released it together with out blog post What founders ask founders about getting into Y Combinator</a></p> Company</h2> Company name:</strong></p> GitLab</p> </div> </div> Company url, if any:</strong></p> https://about.gitlab.com/</a></p> </div> </div> If you have an online demo, what's the url?</strong></p> http://demo.gitlab.com/users/sign_in</p> Note:</strong> this URL no longer works, in 2016 our sign up url is https://gitlab.com/users/sign_in</a></p> </div> </div> What is your company going to make?</strong></p> We’re making open source software to collaborate on code. It started as ‘run your own GitHub’ that most users deploy on their own server(s). GitLab allows you to version control code including pull/merge requests, forking and public projects. It also includes project wiki’s and an issue tracker. Over 100k organizations use it including thousands of programmers at <Redacted>. We also offer GitLab CI that allows you to test your code with a distributed set of workers.</p> </div> </div> Where do you live now, and where would the company be based after YC?</strong></p> The Netherlands, Ukraine (with employees in San Francisco), we don't know yet where will be based after YC</p> </div> </div> Founders</h2> Please enter the url of a 1 minute unlisted (not private) YouTube video introducing the founders.</strong></p> https://www.youtube.com/watch?v=KzvDHA5323o</a></p> </div> </div> Please tell us about an interesting project, preferably outside of class or work, that two or more of you created together. Include urls if possible.</strong></p> We created GitLab together (https://about.gitlab.com/gitlab-ce/</a>) and now over 100.000 organizations are using it. We also created GitLab CI and GitLab CI Runner together https://about.gitlab.com/gitlab-ci/</a>. This pair of programs allow organizations to distribute their code testing over a number of workers.</p> </div> </div> How long have the founders known one another and how did you meet? Have any of the founders not met in person?</strong></p> In 2011 Dmitriy started GitLab. We met in 2012 via email when Sytse started building GitLab.com. In 2013 we formally started a company together and went on team trips a few times since than.</p> </div> </div> Progress</h2> How far along are you?</strong></p> Over 100.000 organizations are using GitLab. <Redacted>, Qualcomm, NASA, Nasdaq OMX and Interpol are paying customers. Over 600 people have contributed to it. It is the most popular open source version control software. It has more installations than anything else (including GitHub Enterprise and Atlassian Stash).</p> </div> </div> If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?</strong></p> Since 2011, over 10,000 commits, see http://contributors.gitlab.com/</a></p> </div> </div> Which of the following best describes your progress?</strong></p> Launched</p> </div> </div> When will you have a prototype or beta? How many users do you have?</strong></p> We estimate more than 1M</p> </div> </div> Do you have revenue?</strong></p> Yes</p> </div> </div> How much revenue?</strong></p> $1m annual Revenue Run Rate</p> </div> </div> What is your monthly growth rate?</strong></p> About 60% in revenue each month.</p> </div> </div> If you've applied previously with the same idea, how much progress have you made since the last time you applied? Anything change?</strong></p> No</p> </div> </div> If you have already participated or committed to participate in an incubator, "accelerator" or "pre- accelerator" program, please tell us about it.</strong></p> We have not applied to or participated any others.</p> </div> </div> Idea</h2> Why did you pick this idea to work on? Do you have domain expertise in this area? How do you know people need what you're making?</strong></p> Dmitriy wanted a solution he could use at his previous job. All employees except our account managers (8-2=6) are software developers. We listen closely to the community via direct customer feedback, pull/merge requests, issues, twitter, mailinglists, chatrooms and the non GitLab B.V. employees on the GitLab core team.</p> </div> </div> What's new about what you're making? What substitutes do people resort to because it doesn't exist yet (or they don't know about it)?</strong></p> We offer the a better way of collaborating on digital products ( the feature branch workflow) to organizations that prefer to work on open source tools. Open source is interesting for large companies because they can inspect and modify the code. They also can and do contribute back changes that are important to them. Substitutes are closed source alternatives (GitHub Enterprise, Atlassian Stash) or less functional open source alternatives (Gitorious, Gogs). GitHub currently has a lot of mind-share but they are under- serving the on-premises (behind the firewall) market. We can see us grow into the leading solution for those installations (which is currently the majority of the market). In the long run most software will live on some (hybrid-)cloud and we think there are many ways to differentiate our offering (open source/distributed/integrated). In the short term we are emulating the Netflix strategy, shipping DVD’s (focus on the on-premise installations) when the competitors focus on the video-on-demand (SaaS) offering.</p> </div> </div> Who are your competitors, and who might become competitors? Who do you fear most?</strong></p> GitHub Enterprise and Atlassian Stash are our primary competitors. We fear Atlassian Stash most since the GitHub Enterprise offering is weak (black box VM that doesn’t scale or cluster) and overpriced (4x more expensive than Stash or our standard subscription). We compete with Stash on usability, integration (no need to install Jira and Confluence separately), flexibility (you can inspect and adapt the source) and price.</p> </div> </div> What do you understand about your business that other companies in it just don't get?</strong></p> An open source development process allows you to market your product for free. It also allows a good product market fit at a low cost. We believe that version control is infrastructure software and that open source is the natural model for this kind of software . But to create and grow a competitive open source offering you need to have a proprietary commercial version to generate scalable revenue, support income alone is not enough.</p> </div> </div> How do or will you make money? How much could you make?</strong></p> Mostly by selling subscriptions that entitle our customers to support and our proprietary GitLab Enterprise Edition. Our most sold subscription by revenue costs $49 per user per year. Most or our revenue comes from organizations with more than 100 paying users. Every company with a substantial number of developers needs software like ours. We already declined an acquisition offer from a competitor for $10M because we want to grow this into a large company.</p> </div> </div> How will you get users? If your idea is the type that faces a chicken-and-egg problem in the sense that it won't be attractive to users till it has a lot of users (e.g. a marketplace, a dating site, an ad network), how will you overcome that?</strong></p> Currently we get users through word of mouth (amplified by twitter). During our time at YC we would like to grow our marketing, our continuous integration product GitLab CI and our SaaS (GitLab.com). GitLab.com currently has only 15k monthly active users but we see a lot of possibilities to grow and differentiate it.</p> </div> </div> Others</h2> If you had any other ideas you considered applying with, please list them. One may be something we've been waiting for. Often when we fund people it's to do something they list here and not in the main application.</strong></p> N/A</p> </div> </div> Please tell us something surprising or amusing that one of you has discovered.</strong></p> Before GitLab Sytse has build recreational manned submarines from scratch, the company he started is currently the largest producer of them in the world and is called U-Boat Worx http://www.uboatworx.com/</a></p> </div> </div>