Tag: gitlab

  • GitLab Joins Unicorn Club With $100m Raise

    GitLab Joins Unicorn Club With $100m Raise

    GitLabGitLab has become the latest member of the Unicorn club after announcing a $100m round of funding led by ICONIQ Capital.  This latest round, a series D brings the total capital raise for GitLab to $145m over 3 years. According to the company it also raised their market valuation to over the magical $1B mark.

    Some of GitLab’s success in raising this latest round of capital can be attributed  to a raising tide lifting all boats. Microsoft’s acquisition of GitHub for $7.5B continues to make ripples in the software developer tools space. But while they share Git in their name, GitLab is not just another Git or GitHub imitator. No, GitLab has a far more ambitious mission. They actually want to be a one stop shop for a complete end to end DevOps solution. Using GitLab you can replace 6 to 9 different DevOps related tools. Or at least that is the vision.

    I have always thought this was a tall order that would require a different way of building software to succeed. GitLab’s CEO Sid Sijbrandij thinks he has found this new method. Using open source, GitLab has an army of software contributors that donate their software to GitLab everyday. With monthly releases you can see the results of this philosophy with constant progress on all fronts at once.

    While Sid realizes that every component or area of GitLab may not be best of breed today, it is his vision that it will be. So what does $100m buy you today to recognize this vision? Well you can hear it right from the horse’s unicorn’s mouth. I sat down with Sid to discuss the raise, the future of GitLab and the market in general.

    I have had the pleasure of interviewing Sid before. He has some very good ideas on where the market is and where it is heading. Below is our conversation, enjoy!

    [wpvideo lvF0Ey0B]

    — Alan Shimel

  • GitLab Raises $100M to Ensure its Single Application Beats 9 Best-in-Class Products

    With Series D Led by ICONiQ Capital, GitLab Surpasses a Valuation of $1 Billion

    SAN FRANCISCO – September 20, 2018 – GitLab, the only single application for the entire DevOps lifecycle, announced it has completed a $100 million Series D round of funding valuing GitLab at $1.1 billion. GitLab plans to use the funding to become best-in-class in every DevOps software category from planning to monitoring. More than 100,000 organizations use GitLab to deploy to multiple clouds, implement cloud native architectures, and practice Concurrent DevOps. This results in a 200 percent faster DevOps lifecycle with unmatched visibility, higher levels of efficiency, and comprehensive governance.

    Enterprises are facing a tool chain crisis, investing time and resources into piecing together disparate tools from different stages of the software development and operations lifecycle. A typical enterprise needs to integrate tools like VersionOne, Jira, GitHub, Jenkins, Artifactory, Electric Cloud, Puppet, New Relic, and BlackDuck. This causes poor visibility because data lives in so many different tools, slow cycle time because teams need to wait on each other, and bolted on security as an afterthought.

    GitLab, an open core software project with more than 2,000 contributors, is breaking down this barrier by building features for each stage of the DevOps lifecycle into a single application. This enables Concurrent DevOps, the ability for teams to manage, plan, create, verify, package, release, configure, monitor, and secure software together so they can have visibility into what matters, start without waiting, and ship with confidence.

    GitLab started as source code management based on Git. But when announcing their series C last year, GitLab voiced the ambition to grow beyond that to cover every product category of the DevOps lifecycle. Some GitLab features have already become best in class, like the continuous integration system that scored highest in the current offering category in The Forrester Wave™: Continuous Integration Tools, Q3 2017 report, and was recognized as a “Strong Performer” in The Forrester New Wave™ for Value Stream Management Tools, Q3 2018. With this latest funding round and the growing number of people contributing code to GitLab, GitLab is well positioned for all of its features to become best-in-class.

    “Two of the defining characteristics of modern application development are an open, collaborative process and toolchains that transcend individual product categories from planning out to operations,” said Stephen O’Grady, Principal Analyst with RedMonk. “By marrying an open source development process to a comprehensive set of functional capabilities, GitLab aims to leverage those precise qualities in a single applications that meets enterprises’ DevOps needs.”

    The latest round brings GitLab’s valuation to over $1 billion and validates its position as the world’s first single application for the entire DevOps lifecycle. As other DevOps tools become locked in to a single cloud, GitLabs customers are embracing a multi-cloud future, so their tooling must be independent of any single cloud provider and work across on-premises, private cloud, and public cloud. Customers want their tooling to be consistent, whether they deploy it themselves or use it as a service.

    “GitLab is emerging as a leader across the entire software development ecosystem by releasing software at an exceptional velocity,” said Matthew Jacobson, General Partner at ICONIQ Capital. “They’re taking the broad software development market head-on by developing an application that allows organizations to ship software at an accelerated rate with major increases in efficiency. ”

    “Since raising a Series C round last year, we’ve delivered on our commitment to bring a single application for the entire DevOps lifecycle to market, and as a result have been able to reach over $1 billion in valuation,” said Sid Sijbrandij, CEO of GitLab. “With this latest funding round, we will continue to build out our management, planning, packaging, deployment, configuration, monitoring and security features for a more robust DevOps application.”

    “With GitLab we are able to continuously improve our entire product development pipeline, which increases productivity and synergy among our team,” said Marcelo Lebre, VP of engineering at Unbabel. “Using GitLab has been a game changer and has fostered an entirely new way of working that allows our team to be more focused on the end result.”

    GitLab is purpose built for organizations undergoing a digital transformation, aiming for faster DevOps lifecycles, cloud native architectures, and multi-cloud deployments. Recent product milestones include the release of Auto DevOps, a Kubernetes integration so clusters can be spun up from within GitLab, Web IDE to let everyone contribute without needing to setup a development environment, and a series of built-in security capabilities bolstered by the acquisition of Gemnasium by GitLab.

    GitLab was recognized by Inc. Magazine as a top four software company in its list of 5,000 fastest-growing private companies in the United States. GitLab has achieved a three year growth rate of 6,213 percent. GitLab has grown from fewer than 10 people in 2015 to more than 350 team members in over 40 countries across the globe. There are currently 77 open job opportunities to continue this worldwide growth.

    “Deployments are no longer limited to a traditional software release cycle,” said Chris Hill, head of systems engineering, next generation infotainment at Jaguar Land Rover. “Using GitLab-CI for our Continuous Deployments over-the-air, we have empowered the customer to be their own technician while increasing the rate at which software can be delivered.”

    About GitLab

    GitLab is a single application built from the ground up for the entire DevOps lifecycle for Product, Development, QA, Security, and Operations teams to work concurrently on the same project. GitLab provides teams a single data store, one user interface, and one permission model across the DevOps lifecycle, allowing teams to collaborate and work on a project from a single conversation, significantly reducing cycle time, and focus exclusively on building great software quickly. Built on Open Source, GitLab leverages the community contributions of thousands of developers and millions of users to continuously deliver new DevOps innovations. More than 100,000 organizations from startups to global enterprise organizations, including Ticketmaster, ING, NASDAQ, Alibaba, Sony, and Intel trust GitLab to deliver great software at new speeds.

    ᐧ

     

  • GitLab Moves to Automate DevOps

    GitLab Moves to Automate DevOps

    GitLab is looking to eliminate the pain of setting up and maintaining DevOps processes by making available an option that automates DevOps processes end to end using a prescriptive approach defined by GitLab.

    The latest version of GitLab includes an Auto DevOps option that organizations can employ to automate the building, testing, code-quality scanning, security scanning, license scanning, packaging, performance testing, deploying and monitoring their applications.

    GitLab CEO Sid Sijbrandij said the company is now able to make this service available because GitLab 11.0 can now be deployed as a set of more integrated applications running on top of a cluster based on Kubernetes container orchestration software. That support for Kubernetes also makes it easier to deploy GitLab 11.0 in a public cloud or on-premises environment as needed. To facilitate that process, GitLab now includes templates that simplify the spinning up of Kubernetes clusters as needed, Sijbrandij said.

    To further its support for Kubernetes, GitLab also decided to start deploying the software it makes available as a cloud service on Google Cloud Platform. Previously, GitLab had been committed to Microsoft Azure. Microsoft recently announced plans to acquire GitHub.

    GitLab is all in favor of automating DevOps processes, but doesn’t think organizations should be forced to move everything into a public cloud to achieve that goal, explained Sijbrandij. Organizations can still elect to construct their own DevOps processes using GitLab as they best see fit.

    But as interest in DevOps continues to rise, more organizations now would prefer to rely on a set of best practices that are defined to make them much easier to consume, he said.

    GitLab 11.0 also adds security scanning capabilities for application built using .Net and Scala programming language in addition to existing support for C, C++, Java, Python, Ruby on Rails, Go and PHP.

    In general, Sijbrandij noted that organizations that embrace DevOps usually find themselves trying to manage various islands of automation with mixed success. Auto DevOps is intended to provide a more comprehensive approach that eliminates the friction that often exists between those various islands of automation. Sijbrandij acknowledged that a prescriptive approach may not appeal to every IT organization, but as traditional enterprise IT organizations start to embrace DevOps, many of them prefer a more platform-centric approach that’s easier to both set up and maintain, simply because they lack internal DevOps expertise.

    Sijbrandij also noted that as DevOps gains more traction in the enterprise, many of the decisions about what platforms to employ will be driven from the top down. Today, most acquisitions of DevOps tools and practices are driven from the bottom up, which accounts for why there are already so many silos of automation, he said.

    Over time many organizations will conclude that the opinionated approach enabled by Auto DevOps will free developers to spend more time on writing code instead of on managing the infrastructure employed to create it, Sijbrandij said. Most traditional enterprise IT organizations today are at least aware they should be employing DevOps practices, they just know exactly what such an effort fully entails.

    Thanks to advances in automation, many IT leaders may never know or care what specific DevOps processes are in place. After all, what most of them are primarily interested in how fast the next set of application code is going to be delivered.

    — Mike Vizard

  • Picking a Git for the Enterprise

    Picking a Git for the Enterprise

    Some of my Agile and DevOps transformation work, not surprisingly, involves helping clients with tooling adoption—to set up, scale and operate across the organization. This blog piece is about a recent experience of setting up Git across a client organization.

    Git, as most of you are aware, is a fundamental building block for many of the modern engineering practices associated with Agile and DevOps. Software configuration management tools such as Git, in simple words, allow you to track and manage your software code and configuration changes in the most-effective, efficient and distributed way. Git, as the choice of source control, has remained steadfast over the years, while other tools across various categories of DevOps tools have seen their fortunes go up and down with the ever-changing technology landscape of DevOps tools. In fact, one new buzzword is GitOps—some even calling it the next stage of evolution for DevOps.

    Origins of Git

    More than a decade ago , the Linux community faced a challenge  because none of the existing revision control tools met their need for a distributed version control tool. And from that need Git was born. In the words of the creator of Git, Linus Torvalds, “The main issues with SCMs is the politics around who can make changes.” Ever since its creation, Git has radically changed the notion of software configuration management (SCM), by enabling engineers to work remotely and autonomously. (If you are new to Git and interested in exploring more about Git and its features, Atlassian has a tutorial and GitHub has a list of resources.)

    Git and More

    While Git as the core product is fundamentally the same whichever flavor your prefer—GitHub, GitLab or Bitbucket—the wrapper around it determines the important non-functional characteristics such as operatability, security, usability and maintainability. Our quest for an enterprise-scale Git focused on the wrapper and not the core product itself, as much has been written, debated and documented on the core product of Git itself already. The value and relevance to enterprises is in the wrapper that these productsplatforms provide.

    We looked at the core product and related offerings; as you can imagine, the three tooling vendors have different positioning and taking different directions with the future road map for their respective tools. Bitbucket’s strength lies in the fact that Atlassian is bundling the product with the omnipresent Jira Software and Confluence. GitLab’s road map seems to be taking the product beyond Git and into the idea of a single product for your entire pipeline automation, from concept to cash. GitHub, which is being acquired by Microsoft, is increasingly relying on the strength of integrations with other tools and the workflow capability the company is bundling with it.

    (I avoid an overemphasis on the commercial aspect in this blog; however, I’m not ignoring it completely. Part of the reason is due to the fact that enterprise pricing is not entirely transparent and may vary wildly depending on organization’s negotiating capability, the scale of usage, future potential and marketable track records as perceived by the tooling vendors. This blog is also not meant to be a feature by feature comparison, as this is something you can Google and find out yourself very easily.)

     

    The Verdict

    Github Enterprise pros and cons
    Image1; Github Enterprise – Pros and Cons
    Gitlab Ultimate and features
    Image 2:  Gitlab Ultimate – Pros and Cons

    My Recommendation: It Depends

    1. I liked the vision of GitLab as a single-stop tooling platform for continuous integration/continuous delivery (CI/CD), which goes beyond source control. I think the tool is simple and intuitive to use and great for small to midsized setups or even large enterprises that are focused on having smaller and autonomous teams.
    2. GitHub seems to be well-suited for large and complex enterprises with significant outsourced and offshore-based technology teams.

    I would love to hear your views on what has been your thinking with regards to choosing a Git-based product for your enterprise or teams. Meanwhile, here are some links you might find useful in your decision-making:

    1. Why and how GitLab abandoned Microsoft Azure for Google Cloud – https://venturebeat.com/2018/04/06/why-and-how-gitlab-abandoned-microsoft-azure-for-google-cloud/
    2. Tooling integrations of GitLab – https://docs.gitlab.com/ee/integration/README.html#doc-nav%20for%20list%20of%20integrations
    3. GitHub add-ons are listed at Addons are listed at https://github.com/marketplace
    4. Security and scalability info of GitHub is at https://github.com/jonico/github_security_and_scalability_overview
    5. Products that integrate with GitHub platform – https://github.com/works-with
    6. Pricing of GitLab – https://about.gitlab.com/pricing/

    — Aditya Vadaganadam

  • Enthusiasm for DevOps Greater Than Actual Adoption, Survey Shows

    Enthusiasm for DevOps Greater Than Actual Adoption, Survey Shows

    When it comes to DevOps practices, adoption continues to lag intention by quite a bit.

    GitLab recently surveyed some 5,300 software developers and engineers from mostly small and medium businesses around the world. The survey examined overall attitudes and perceptions around the state of DevOps, with a particular focus on uncovering any disparities that might exist between developers and IT management.

    The responses showed that many organizations are sold on the idea of DevOps, especially those who have implemented it. Sixty-five percent of the developers polled felt that using a DevOps workflow would save development time. An even higher 81 percent of managers shared that same sentiment.

    Organizations with an integrated DevOps strategy reported a high correlation between DevOps practices and overall team productivity. Development teams that deploy code on demand and spent more than half their time on new projects, for instance, had twice the rate of DevOps adoption compared to lower-performing teams. Higher-performing teams also generally considered automation of the software development life cycle a top priority and had access to better tools.

    Yet, the number of organizations in the survey that have actually implemented DevOps practices was far smaller than the otherwise enthusiastic support for it would suggest. In fact, only 23 percent of the respondents in the survey identified their team’s methodology as following a pure DevOps model. Thirty-five percent described their DevOps culture as being somewhat established.

    The low adoption rates are somewhat at odds with Forrester Research’s prediction about 2018 being the “Year of Enterprise DevOps” and may reflect the global nature of the survey base and the fact that many respondents were SMBs. Forrester found DevOps adoption to be around 50 percent when it conducted a survey of its own of 237 DevOps pros last year.

    GitLab’s survey found that while developers view DevOps as critical to software development life cycle, many have not implemented a DevOps workflow. Similarly, while over 95 percent of the survey respondents placed a high value on collaboration and 81 percent felt that such collaboration was easy to achieve, 25 percent said they did not have enough visibility into operations, security and production. And 42 percent reported unclear directions as one of their biggest challenges to getting work done.

    Culture continues to be a big roadblock. “It’s hard to get Dev and Ops to work together in a cross-functional way,” said Mark Pundsack, head of product at GitLab. “That challenge can be exacerbated by tooling. Disjointed toolchains lead to disconnected processes and barriers to communication that get in the way of working together.” Many developers in the survey reported using at least five tools to get their job done.

    Nearly 6 in 10 of the survey respondents (58 percent) pointed to ingrained practices as their biggest roadblock to adopting new tools and practices, while 50 percent blamed an inherent resistance to change.

    Interestingly, remote employees tended to have a more favorable outlook on how things were going with DevOps, with 67 percent saying they had good visibility into what others in the organization were doing compared to 57 percent of on-premises teams.

    “DevOps culture is clearly important to achieving high performance,” Pundsack said. “For managers … the survey identified the top challenge in getting work done was unclear direction and managers should be able to play a role in fixing that.”

    The apparent gap that exists between intent and adoption was not the only surprise in the survey, Pundsack said. Also unexpected was the extent of the discrepancy between how executives think their teams are operating, and what developers are actually saying. When asked how often they deployed code, 47 percent of managers were under the impression their organizations were deploying multiple times a day in contrast to the substantially smaller 39 percent of developers who said the same thing.

    That one area aside, though, developers and IT manager seemed better aligned on other issues in the Gitab survey. For example, more than three-quarters of both developers and managers feel they are set up to succeed and about one-third of them felt that they deadlines they have to deal with are fair.

    GitLab’s survey showed that most organizations expect to invest in continuous integration and continuous deployment tools in 2018, with nearly half strongly agreeing that CI can help speed up the development process.

    “CI can help alleviate blockers in the development cycle such as removing the manual process to verify code before deploying,” thereby allowing development teams to have a faster and more effective feedback cycle, Pundsack said.

    — Jai Vijayan

  • DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

    DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

    In this DevOps Chat we speak with GitLab CEO Sid Sijbrandij. Sid has guided GitLab as a co-founder to the heights of the DevOps market. Joining Sid and me is Ashish Kuthiala, who recently joined GitLab. I have always been impressed with the completeness of GitLabs’ vision of the DevOps toolchain and what the company wants to offer. Sid’s vision for this is something he calls Concurrent DevOps. You will hear more about Concurrent DevOps in our chat, as well as in the months to come.

    Another thing about GitLab is is an open source-based company, which allows for a lot of transparency. With hundreds of thousands of organizations using GitLab and thousands of paying customers, GitLab is a great example of a DevOps success story.

    As usual, the audio of our conversation is immediately below, followed by a transcript of our conversation.

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 120255″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Sid Sijbrandij
    Sid saw the first ruby code in 2007 and loved it so much he learned to program and made this his profession. Before that he was engaged in various businesses, from selling programmable infrared receivers to starting a recreational submarine company. He is always looking to publicly document an answer or to make a process more efficient. He was never good at sports but tries to make it up in quantity by hiking, sailing, skiing, snowboarding, speed skating, dancing Zouk, squashing, and running. In love participating in conversations on Hacker News, and reading Marc Andreessen’s tweets (now that Marc stopped this greatly increased his productivity).[/su_pullquote]
    Alan Shimel: Hey, everyone, it’s Alan Shimel, and it’s time for another DevOps Chat. Our DevOps Chat episode today is gonna be all about GitLab, and we’re joined by two GitLab folks. First joining us is the co-founder and CEO of GitLab, Sid Sijbrandij, and I hope I did that justice. Sid, welcome to DevOps Chat.

    Sid Sijbrandij: Thanks for having me.

    Shimel: Thank you. And joining Sid and I is a friend of mine, recently joined the GitLab team, Ashish Kuthiala. Ashish, I didn’t mess that up too bad, did I?

    Ashish Kuthiala: No, you didn’t. No, that was perfect.

    Shimel: Alright! Well, one of the nice things about tech is, I get a lot of experience. Not a lot of Smiths in the group. [Laughter] And as I said, this is Alan Shimel, and we’re here with DevOps Chat.

    So, guys—GitLab. You know, first of all, Sid, I’m sure you’ve probably heard this before, but I’m sure there are people in our audience who still have to ask themselves, “GitHub, GitLab,” right? And as silly as it sounds, they may confuse them sometimes.

    So, let’s set it straight in terms of GitLab. Sid, you co-founded it. What exactly is GitLab and how does it differ, let’s say, from GitHub, and we’ll go from there.

    Sijbrandij: Yeah, so GitLab started off as an open source alternative to GitHub, where you could have Git repositories, do version control, do some issue management, and it’s now grown a lot as a company and as a project. We now do the whole DevOps life cycle. So, anything from planning to rolling out what you’ve made—CI/CD, packaging, monitoring—all in a single application.

    Shimel: Great. And I think you’re being modest, actually. GitHub is certainly—when you say branched out, it’s branched out, I mean, from what I know, and I’m no expert, obviously, the breadth of the vision is pretty dynamic. So, congratulations with that.

    Sijbrandij: Thank you.

    Shimel: Ashish, you were—thank you. Ashish, you recently joined GitLab, and why don’t you give us out, what’s your position there?

    Kuthiala: So, Alan, I think you and I have known each other for a while, and I am very passionate about the promise of DevOps, especially at large scale enterprises, right? Not smaller teams or not those who had the luxury of building out their infrastructure and teams to adopt DevOps and realize the promises of that.

    We still a lot of the larger enterprises struggle with adopting and realizing the promise of DevOps as it is. I mean, a lot of them are achieving results, but a lot of them are still in the journey and trying to figure out how to get there.

    So, and I had heard about GitLab, I knew that they were building out a solution for this, but I think it was in the last DevOps Enterprise Summit, you, I, and Haydn ran into each other. And I started talking to Haydn and I learned more about the company, and I think it’s just the right product at the right time. Because if you look at all the challenges that exist in the big enterprise, there’s massive transformation needed, and there’s several things that prevent this from moving forward at the speed that everybody would like, whether this is different organizations within the large organizations to get them to collaborate together, whether this is stitching together the different toolset chains to kind of make this seamless.

    And I think GitLab has really built something from ground up that addresses this problem. And the good news is that the velocity at which we are adding functionality, we are adding the needs that need to be addressed. Because we are an open source company, we are completely open and transparent, right? We gather input from everybody, a road map is opened. We take the input, we take contributions, and we build the right thing for solving today’s problems. And as needs change, I see this model as something that can really adopt to that, right?

    Because the world of DevOps is changing very rapidly, and often there’s a fear of getting locked in with a vendor, too. With our solution, I think the openness of it and the direction it can go to solve problems as they change is a great promise, and we’re already solving a lot of problems. So, that was a big thing for me, you know, that I considered in joining GitLab.

    And the other thing is the culture and open transparency that Sid and the company have built in the company. It’s just phenomenal for me, right? I mean, that was just an eye opening model of how everything we do is open to the world. It’s open within the employees. Anybody can contribute, anybody can look at everything we do and how we move forward to help our customers.

    So, these two are the main things for me that really inspired me to join GitLab.

    Shimel: Great. So, Sid, I’d like to come back to you. Certainly, we can all have vision, but execution is what kinda separates winners from losers in the market. And I’d like to ask you, as the CEO, what’s the secret, if you want to share it with us, right? How do you translate this vision that attracts someone of Ashish’s quality and character and then translate that into an execution that actually translates to success in the market?

    Sijbrandij: Yeah, I’d love to talk about that. We’re biting off a lot, so I think we’re now—GitLab offers a great solution for 10 different product categories. So, that’s massive. There’s a lot of engineering effort. For example, we have a CI/CD team that is just 10 people, and that they have to compete with people that are 100 times bigger. So, how do they do that? First, they’re just selected. GitLab CI is the leader in this space. There’s GitLab CI on the top right and then whole lot of nothing.

    Shimel: Mm-hmm.

    Sijbrandij: So, how do you do that with 10 people? Well, there’s a couple of secrets. The first one is—you don’t do that with 10 people, you do that with 1,800 people. So, we’ve got over 100,000 organizations using GitLab, and over 1,800 people contributed to the product. So, in the release that will go out in a week from now, there’s not just 1 contribution, there’s not 10, there’s 93 features that people contributed that aren’t paid by GitLab.

    So, we see it as, instead of having a tool chain where you have to make the integrations yourself—and that’s not just a few, we identified over 24 integrations you have to make in a standard DevOps tool chain. Instead of making them all yourself with your DevOps tooling team, you work together with 100,000 organizations and 1,800 people to do that.

    So, that’s the big secret. It’s open source. We work together. Then there’s some small secrets, and one of them is iteration. Iteration is one of our six values, and it’s something that everyone is super excited about when they join, but they all kind of don’t understand how painful it is, because it’s very, very painful to do the minimal thing. We’re now in a call with Ashish that Ashish will probably not like that we’re gonna probably change the header on our home page today, because we thought of something better. He’s probably gonna say no, but give me a month, I can think of something even better. And I will be like, “That’s great, Ashish. Think of something even better and then change it again.”

    Shimel: Yep.

    Sijbrandij: It’s very, very painful, and we do that throughout the company, and in product, it’s a very painful thing. My previous call was with Martin, and they’re working on a cloud native chart for GitLab, and we have a thing with uploads and we probably are gonna ship a chart with an NFS server as a part of that. A very clumsy thing, but it unlocks everybody else, and we can keep shipping. And one of our other subvalues is boring solutions, and I love that, because it’s so obvious. You say “boring solution” and people understand what you mean. We don’t go for the shiny toy. Our mission is, everyone can contribute, and people can only contribute if there’s a stable environment to do that, if they understand what you’re doing.

    So, when I saw the GitLab code base a year after Dmitri created it, I expected to see a hobby project. Someone super passionate, but doing this outside of work, like, putting some new development paradigms in it and having something that is hard to comprehend, especially since 300 people already contributed in that first year.

    And instead, I opened up the code base, and I saw a pristine Ruby on Rails application. Totally idiomatic, like, exactly how it should be, and we kept that. We don’t allow anyone to do anything that isn’t boring, and that enables everyone to contribute. That enables us to make forward progress, and we adopt the best of what’s out there. We embrace Kubernetes, we embrace Prometheus—really great, rock solid open source solutions that we can build for later on, and that’s been a big success.

    Shimel: Absolutely. You know, Sid, that was a mouthful in more ways than one, right? So, let’s hit on a couple things. First of all, harnessing the power of open source, right? Right out of The Cathedral and the Bazaar, you know, the book, and what’s gone on is, I mean, the false multiplier there is amazing. Of course, there’s a certain amount of a herding cats element to it, right, in getting everyone moving the same way. But if you can, harnessing that power is just—you know, it’s amazing.

    No. 2, you know, you spoke about iterations and sort of feedback loops and constant change, right? This is core to DevOps, right? This is DevOps 101 kinda stuff.

    Sijbrandij: It really is. This is exactly what we deliver to customers.

    Shimel: Yeah.

    Sijbrandij: Organizations adopt GitLab because we can make their DevOps life cycle three times faster, but you still have to work between the tools. They had these handles between the tools, they had these integrations that weren’t transparent, that weren’t seamless.

    With GitLab, they can work concurrently. As soon as you push your change, QA is gonna run, security tests run, production is gonna have the first review up out there. There’s not a sequence to it. It is, you paralyze the whole process and you gain tremendous speed and you reduce your time to value, and you allow to get feedback and to improve based on that. That’s the value we bring as a product and of course, we try to practice that ourselves.

    Shimel: Yeah. Well, so, but you more than practice it yourself. I think, you know, Sid, I’m a little different. You’re the CEO of this great company, GitLab. I’m an observer, I’m a fly on the wall of many DevOps companies, of many DevOps transformations, and I will tell you, the DevOps tools providers who do it best are those who eat their own dog food, who are practicing DevOps themselves. If you can’t do DevOps internally, don’t try to tell other people how they should do it or, you know, what they should be doing.

    It’s not a case of “do as I say, not as I do.” You have to live that, you have to talk the talk, walk the walk in order for you to truly understand it well enough to get other people to buy into it and be successful. So, kudos to GitLab for doing that.

    You guys recently announced an acquisition in the securities space. We’re kinda running low on time, but I wanted to just touch on that. Sid, your take on it?

    Sijbrandij: Yeah, we acquired a company called Gemnasium, and I think they’ve done the best job of any company of assessing all the different libraries, all the dependencies that are out there and saying which ones are vulnerable, which ones contain a problem. And that is functionality that’s gonna, that’s part of the DevOps life cycle, so we want them to be right in the product.

    So, we’re really happy to join their team, and I’m super proud of them for embracing our values, because they joined us, and within three weeks, all the Gemnasium functionality ended up in GitLab, so.

    Shimel: That’s cool.

    Sijbrandij: We know we hired the right people, they’re amazing, so congrats to Philippe and his team.

    Shimel: Yep. Congratulations to them. And look, we see it here, you know, this whole DevSecOps thing, if you will, if you want to call it that, is probably, along with testing, two of the hottest areas within the larger DevOps community.

    Ashish, we’re almost out of time. Let me come back to you, though. So, you joined this fantastic organization. We’ve heard from Sid a little bit of a peek into what’s making this engine roar, this rocket lift off. What are you gonna bring to the table? What are we gonna see from you, Ashish?

    Kuthiala: I think we need to take this message out to the marketplace, like, you know, a couple of things you talked about when people hear GitLab, they sometimes confuse it with the Git community and other Git offerings like GitHub, for example. So, we really need to tell the world what we are doing, and we are much more than just a repository engine, right? We do a lot more.

    And now that, you know, we are out there trying to help other customers with their DevOps challenges, it’s actually a little bit more than what Sid mentioned here; he is being humble. So,  not only are we practicing our own DevOps methodology to develop and roll out our application, but we actually use DevOps in every single aspect of running the company, right? Right from the hiring process when I joined to everything that I do in the company adopts a pipeline—you know, you create an issue and you run it through the pipeline and you merge that issue and it goes to production. If something is wrong, you know, it comes back.

    Amazingly, everything, between signing for benefits to updating the webpages to running our tracking of issues of what we do, it’s all run through pipelines. And I think I see that as a future. You know, DevOps is not just to be applied to delivering IT value, but you know, it is a methodology that can be applied across running your company for all functions.

    So, I think the version of GitLab is much bigger than just helping companies deliver efficient software really fast out there with feedback on the DevOps methodology. It’s almost to pivot and change the way we think about delivering value to our customers, in every aspect of running the company that we do. And I want to be part of that. I think it’s really exciting. I can’t wait to kind of start talking about this to everybody and, you know, seeing how we go down this journey.

    Shimel: Great. Sid, we’re over time, but I want to give you the last word, so I’m gonna ask one last question for you. What can we expect to see next from GitLab?

    Sijbrandij: We detail a really ambitious vision, and the vision is called Complete DevOps. And we said we’re gonna realize that this year, and we’re executing on that. We’re really proud, we integrated a complete web IDE in GitLab, so VS code running in GitLab. No need to check out this autocode base, you can just edit right there and then.

    But it consists of a lot of parts. We’re gonna have real time editing of issue and merge request descriptions. We’re gonna add logging to GitLab. You can already do monitoring, but we’re gonna add something for your logs, we’re gonna add application performance monitoring. Lots of other things that we think are needed to have a complete solution.

    So, if you started a startup, the only things you have to do is incorporate it, get a Kubernetes cluster, and install GitLab on it—job solved. Like, you’re up and running, you don’t need any other tools, and the only thing you have to do is, you push your code and already today, GitLab detects what language is it, it builds your code, it tests your code, it tests for all the security issues that might be there, it tests your code quality. It gives you all that. It gives you a review app to work with, kind of a staging app. That already works in GitLab today and we’re expanding on that, and I’m super excited to deliver that to the market this year.

    Shimel: DevOps complete. Thank you. Ashish, Sid—thanks so much for being our guests on this episode of DevOps Chat. Continued success with GitLab. We’ll be checking in—actually, I’ll see some of the GitLab folks at IBM Think in a few weeks, and we’ll get an update there, but Sid, you’re always welcome to be a guest here, don’t be a stranger, and congratulations.

    Sijbrandij: Thanks so much. Thanks for having us. I enjoyed this. Looking forward to coming back.

    Shimel: Alright, Ashish—

    Kuthiala: Thank you, Alan, for having us.

    Shimel: – good luck, my friend. Be well. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat, and we’ll see you soon on another DevOps Chat, everyone.

    — Alan Shimel

  • GitLab Acquires Gemnasium to Advance DevSecOps

    GitLab Acquires Gemnasium to Advance DevSecOps

    GitlLab, as part of its effort to extend the reach of its DevOps platform into the realm of security, has acquired Gemnasium, a provider of tools to mitigate vulnerabilities in open source code.

    The goal is to incorporate the IT security tools Gemnasium has developed within a single software development lifecycle (SDLC) platform, said GitLab CEO Sid Sijbrandij.

    Because both companies relied on the Ruby on Rails programming language to write their respective applications, integration of the Gemnasium software into the core GitLab platform will be easier, he said.

    Sijbrandij noted a growing number of organizations are looking to extend the reach and scope of their DevOps processes to include security, also known as DevSecOps. The pitfall they face will be trying to integrate disparate DevOps and security management tools. GitLab is moving to integrate both classes of tools within a single SDLC environment that will make it easier for organizations to make the transition to DevSecOps.

    GitLab, Sijbrandij said, already had been moving down that path prior to the acquisition of Gemnasium. Previous releases of the company’s platform have included support for static application security testing (SAST), dynamic application security yesting (DAST) and container scanning. The separate software that Gemnasium developed will no longer be supported after May 15.


    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    CA Technologies Survey Uncovers DevSecOps Challenges


    Longer term, Sijbrandij said GitLab is moving toward being able to host its software on top of the open source Kubernetes container orchestration platform. That approach will make it easier to automate deployment of its software on multiple public clouds and on-premises IT environments using a zero-touch provisioning framework.

    Ultimately, embracing DevSecOps should result in more secure applications. But just as importantly, IT organizations need to be able to adroitly remediate software vulnerabilities whenever required. There’s a direct correlation between how long malware goes undiscovered and the amount of potential damage caused. It’s not uncommon these days for malware to go undetected for months; as such, eliminating as many of the vulnerabilities that cybercriminals routinely exploit must be a much higher priority for developers.

    Achieving that goal, however, is as much about process as it is tooling. Most developers are not security experts. Conversely, IT security experts typically know little about building applications. Developers are under more pressure than ever to roll out applications faster. But that pressure also often leads to them to short-shrift testing processes that otherwise would have uncovered a vulnerability. Organizations that embrace DevSecOps are trying to address security issues earlier in the process because fixing them once an application is in production is expensive. At the same time, however, no one wants to slow down the speed at which applications are being developed. That creates something of a chicken-and-egg dilemma for IT leaders trying to determine degree to which new tooling will foster changes to processes and culture, or whether they need to accomplish the latter before investing in new tooling.

    There’s always been a natural tension between developers and IT security teams. The hope is that by making them all part of the same DevSecOps team, that tension is either eliminated or sharply reduced. That outcome stands a better chance of being achieved when everyone involved is employing a common framework.

    — Mike Vizard

  • GitLab Expands Authentication Capabilities, Adding Support for U2F and YubiKey Through Partnership with Yubico

    New Offering Gives Developers the Ability to Securely Access Any Number of Online Services, with One Single Device

    SAN FRANCISCO and PALO ALTO —June 22, 2016— Today GitLab, the open source code collaboration tool that allows developers to code, test and deploy together, expanded its authentication capabilities for the enterprises via a partnership with Yubico.  GitLab now supports the FIDO Universal 2nd Factor (U2F) protocol for user authentication with the added layer of hardware security from YubiKey. U2F changes the game for online authentication as it uses public key cryptography and has built-in support to prevent phishing. This higher level of authentication enables organizations and individual developers to maintain the security of their servers, code, sites, and more from a single source.

    With the steady rise of new devices and the growing capabilities of existing ones, the average user logs into networks, applications, or platforms from a variety of different devices. While device flexibility is great from a user perspective, it represents significant security challenges for organizations and developers. Each new access point makes it tougher to fend off malicious attacks particularly phishing while maintaining the integrity of accounts and systems.

    GitLab’s VP of Engineering, Stan Hu, said, “GitLab and Yubico recognize the importance of security and are excited to be able to provide additional security measures for GitLab customers. GitLab has long supported two-factor authentication via a mobile application, but adding U2F support with YubiKey now provides an additional level of security. GitLab customers will have the option to choose which method of authentication is best for them.”

    The new YubiKey offering reduces the number of steps coders must take to access their accounts, while maintaining usability and providing secure authentication with just a touch of the YubiKey. With U2F, GitLab customers can now authenticate by inserting their YubiKey into the USB port when prompted. The customer activates their YubiKey by simply pressing the button on the device, then instantly, the YubiKey securely authenticates the user into the account.

    The same U2F YubiKey that works with GitLab also works for logging into a growing number of other services, including Google, Dropbox, and Dashlane, without any personal data or encryption secrets shared between service providers. With YubiKeys, there are no drivers or client software to install.

    Jerrod Chong, VP of Solutions Engineering at Yubico, says, “GitLab is making a strong statement with their support for U2F, providing their user community with the highest level of account security by enabling YubiKey’s U2F capabilities.”

    Stan Hu, GitLab’s VP of Engineering, said, “We are committed to securing our user’s work with proven, seamless solutions. Supporting YubiKey for two-factor authentication is a logical step towards that goal.”

    About GitLab

    Founded in 2014, GitLab, Inc. is the open source code collaboration platform that provides a complete workflow to create, review, and deploy code simply and effectively. Downloaded over one million times, GitLab includes Git repository management, code review, issue tracking, wikis and GitLab CI, a continuous integration and deployment tool. Built for the enterprise, GitLab scales effortlessly, handling more than 25,000 users on a single server. GitLab provides companies from startups to Fortune 500 enterprises with a faster and more effective development environment. More than 100,000 organizations all over the globe currently use GitLab on premises including NASA, CERN, Alibaba, SpaceX, O’Reilly, IBM and Expedia. Follow @GitLab on Twitter or learn more it at http://about.gitlab.com.

    About Yubico

    Yubico sets new world standards for simple, secure login, preventing unauthorized access to computers, servers, and internet accounts.

    Supporting multiple authentication and encryption protocols on all devices and platforms, YubiKeys protect access to user accounts for the world’s largest enterprises with a simple touch, and with no driver or client software needed. Yubico is a leading contributor to the FIDO Universal 2nd Factor open authentication standard, and Yubico’s technology is used, and loved, in more than 150 countries.

    Founded in 2007, Yubico is privately held with offices in Palo Alto (California), Seattle (Washington), Stockholm (Sweden), and London (UK). For more information, please visit www.yubico.com.