<story><title>GitLab Master Plan</title><url>https://about.gitlab.com/2016/09/13/gitlab-master-plan/</url></story><parent_chain><item><author>PaulRobinson</author><text>It&amp;#x27;s interesting to me how much effort is being spent on adding tools like issue tracking, build pipelines, deploy management, etc. vs just providing good hooks for standalone tools that do all those things.&lt;p&gt;We have discussions about Jenkins vs Concourse, where to keep ansible vault passwords, should documentation live in Github wiki or in Confluence (apparently &amp;quot;tech&amp;quot; documentation in the form, &amp;quot;business&amp;quot; documentation in the latter - what if it&amp;#x27;s both? Who decides?), and so on.&lt;p&gt;There is something nice about being able to go to a single place and saying &amp;quot;OK, it&amp;#x27;s all here in this box&amp;quot;. Github has made inroads with some of this stuff, but not quite enough. Gitlab could try and do all this, but then people will moan (&amp;quot;I prefer JIRA&amp;#x2F;Trello&amp;#x2F;whatever&amp;quot;).&lt;p&gt;Most of the pain around developer&amp;#x2F;business workflow around us at the moment actually comes down to the fact that nobody has _really_ thought about providing a great unified UX for all of this.&lt;p&gt;Part of the concern is people want to be &amp;quot;flexible&amp;quot;. No, dictate, just make sure what you dictate is a better solution to what people have.&lt;p&gt;If GitLab get it right, github could be a minor player (unless they keep up) in a few years time.</text></item></parent_chain><comment><author>sytse</author><text>I used to think that a collection of standalone tools was better and that we should focus on code hosting and review. When Dmitriy started with GitLab CI I was dismissive but of course as the author he could do as he pleased. It turned out that having a CI tool that closely works together with the main product was a better experience, especially behind the firewall&amp;#x2F;single-tenant&amp;#x2F;on-premises.&lt;p&gt;Then Dmitriy and Kamil (our CI lead) proposed integrating the CI coordinated into GitLab the main program instead of a standalone Ruby on Rails app. Again I was sceptical. But this has been a great success.&lt;p&gt;We have all the API&amp;#x27;s (webhooks, commit status API, etc.) to integrate well with Jenkins (and we&amp;#x27;ll make sure that we&amp;#x27;ll always play well with that, JIRA, Slack, and others). But having everything in one interface and one datastore makes for a much better user experience.&lt;p&gt;We&amp;#x27;ve since doubled-down on this strategy. Bringing the entire software development lifecycle under one roof &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;about.gitlab.com&amp;#x2F;direction&amp;#x2F;#scope&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;about.gitlab.com&amp;#x2F;direction&amp;#x2F;#scope&lt;/a&gt; During the webinar we&amp;#x27;ll show a demo video of how these components will soon work together. We think it is an amazing experience and everyone on our team is focussed to get it right.</text></comment>
<story><title>GitLab Master Plan</title><url>https://about.gitlab.com/2016/09/13/gitlab-master-plan/</url></story><parent_chain><item><author>PaulRobinson</author><text>It&amp;#x27;s interesting to me how much effort is being spent on adding tools like issue tracking, build pipelines, deploy management, etc. vs just providing good hooks for standalone tools that do all those things.&lt;p&gt;We have discussions about Jenkins vs Concourse, where to keep ansible vault passwords, should documentation live in Github wiki or in Confluence (apparently &amp;quot;tech&amp;quot; documentation in the form, &amp;quot;business&amp;quot; documentation in the latter - what if it&amp;#x27;s both? Who decides?), and so on.&lt;p&gt;There is something nice about being able to go to a single place and saying &amp;quot;OK, it&amp;#x27;s all here in this box&amp;quot;. Github has made inroads with some of this stuff, but not quite enough. Gitlab could try and do all this, but then people will moan (&amp;quot;I prefer JIRA&amp;#x2F;Trello&amp;#x2F;whatever&amp;quot;).&lt;p&gt;Most of the pain around developer&amp;#x2F;business workflow around us at the moment actually comes down to the fact that nobody has _really_ thought about providing a great unified UX for all of this.&lt;p&gt;Part of the concern is people want to be &amp;quot;flexible&amp;quot;. No, dictate, just make sure what you dictate is a better solution to what people have.&lt;p&gt;If GitLab get it right, github could be a minor player (unless they keep up) in a few years time.</text></item></parent_chain><comment><author>solatic</author><text>The market will show that all-in-one box solutions are the best solutions for new companies.&lt;p&gt;When you&amp;#x27;re a new startup and you&amp;#x27;re trying to race to an MVP and being default-alive, what do you really want to do? Do you really want to spend time getting all of your ALM and build pipeline and production environments up and running? Or do you want to start iterating on business features as quickly as possible?&lt;p&gt;The truth is that providing 80% of the features is going to be good enough for 80% of new companies. When companies figure out that they need one of the 20% of the features that are missing, they can then migrate to get the feature that they positively identified a need for. Putting in much more effort in the beginning for ALM&amp;#x2F;pipeline&amp;#x2F;environment features you may not even need is a form of premature optimization.</text></comment>