Tag: github

  • Anaxi Enhances Development Intelligence Tool, Helps Maintain Delivery Schedules with Added Support for Atlassian Jira

    App provides greater reporting and analysis capabilities

    SAN FRANCISCO, November 15, 2018 — Anaxi, maker of software that helps engineering organizations gain control over the development process, announced today its iPhone app has added support for Atlassian Jira Server and Cloud versions to its current support for Github,  giving engineers and managers increased visibility and intelligence on their software development projects and processes.

    “By aggregating data from different tools, we’re able to provide metrics that provide a holistic view of the development process — not piece parts,” said Marc Verstaen, co-founder and CEO of Anaxi. “Now, for the first time, there is a system of record for software engineering to better control the process and keep development schedules on track.”

    Anaxi’s app now integrates data from both GitHub and Jira, the leaders in code versioning and issue tracking, respectively. The company intends to expand the number of tools it supports in the coming months.

    The Anaxi software development intelligence app analytics include productivity reports on individual, as well as team performance, providing more transparency and delivering actionable insights.

    Currently, Anaxi offers a free version of its app for the iPhone that is available on iTunes. The company is planning to make available in the coming weeks a beta version of its web app followed by an Android version. The company’s plans include a paid version for users who want premium reporting and communication features.

    The newly added capabilities for the Anaxi free app on the iPhone include the following.

    • Issue and Pull Request Metrics

    Users can look into their pull request and issue data to better understand how their projects are evolving. Users can use any filtering and sorting options to surface the items of interest to them and save them as new reports for quick access. Also, Anaxi created an evaluation of complexity for pull requests, as an additional consideration for users in terms of assessing which pull requests to review first.

    • Productivity Metrics

    Analysis of project commits provides metrics on individual and team productivity, including a breakdown of the effort in terms of code added and removed, refactoring, code churn, and more on a weekly basis.

    • Project Management

    From their iPhone, users can edit their issues and pull requests. All edits are synchronized back to their GitHub and Jira projects.

    • Data Confidentiality

    To protect the need for confidentiality and access to users’ GitHub and Jira accounts,  the Anaxi app is designed to connect directly to the users’ Github repositories and/or Jira projects. Then, the app builds the reports using the data, which remains secure and inaccessible, even from Anaxi itself.

    For more information go to www.anaxi.com/features.

    About Anaxi

    Co-founded by Marc Verstaen (previously executive vice president of product development at Docker) and John Lafleur (previously CEO at CodinGame) in December 2017, Anaxi is the system of record for software engineering organizations that need to facilitate decision processes. Anaxi will open a new data-driven era to engineering organizations, empowering them to better allocate their development time and resources.

  • Using Netflix’s HubCommander to Automate GitHub Organizations

    Using Netflix’s HubCommander to Automate GitHub Organizations

    Netflix owes a great deal of its exponential growth to its phenomenal tech stack. Throttling its content through a single internal API, the company was able to deliver content agnostic of device type and quickly disrupt its contemporary competitors in the consumer entertainment industry.

    We’re intrigued, then, when Netflix exposes some of its internal architecture for others to use. HubCommander is just one recent addition to Netflix’s growing collection of open source tools. It’s a ChatOps tool for GitHub management.

    We’ve previously covered an open source approach to ChatOps, tracking how to bring free operational tools into the conversation for increased transparency and efficiency. In this article, we’ll resume this research by learning how Netflix has utilized HubCommander and delve into its open source iteration to see how others might leverage it to automate its GitHub organization.

    Problems

    Managing many GitHub repositories while working in a large organization can be frustrating; especially difficult is the task of managing permission levels between various user subsets. Not only are various user permission levels difficult to trace, but there is an intrinsic security problem to address as well, especially when working with external teams.

    “One of the biggest challenges with using GitHub organizations is user management.” — Netflix

    Project managers need to administer different organizations, and GitHub requires admin privileges to manage such repository settings; if onboarding thousands of employees, editing this manually could be an extremely tedious job.

    Benefits!

    At Netflix, HubCommander standardizes its user management approach, enabling automation for GitHub repo permissions across development teams.

    “Management of many users on GitHub can be a challenge without tooling. We needed to provide enhanced security capabilities while maintaining developer agility. As such, we created HubCommander to provide these capabilities in a method optimized for Netflix.”

    HubCommander thereby provides this missing link, granting admins the ability to quickly grant privileges. Easily to embeddable into chat, the HubCommander is made with ChatOps in mind. Therefore, privileged GitHub organization management tasks can be performed from the Slack channel, “without granting administrative or owner privileges to your GitHub organization members.”

    Using HubCommander

    To use HubCommander, first, you must have Python 3.5+, Slack, a GitHub organization, and a GitHub bot user with ownership level privileges.

    Next, Slack channels with HubCommander installed can make the call !help to return a list of bot commands:

    Source: Netflix

    To create a repo, for example, you can simply use the command !CreateRepo:

    Source: Netflix

    Utilizing HubCommander also has security benefits as it reduces the number of GitHub API permissions granted per user—reducing attack vectors inherently increases security. Another point on security is HubCommander’s integration with Duo for additional authentication:

    Source: Netflix

    The total list of HubCommander features include:

    • Repository creation
    • Repository deletion
    • Repository description and website modification
    • Granting outside collaborators specific permissions to repositories
    • Repository default branch modification
    • Repository PR listing
    • Repository deploy Key listing/creation/deletion
    • Repository topics creation/deletion
    • Repository branch protection enabling/disabling
    • Enable Travis CI on a GitHub repo
    • Safeguard commands with 2FA via Duo

    Automating GitHub With ChatOps

    If your code resides in multiple Git repositories, like Netflix, having a method to configure permissions across all entities in a convenient way becomes a necessity. With a bot to perform operational tasks on GitHub repositories, Netflix is benefiting from automatic manipulation and a wider team access, adding to its agile goals:

    “The reduction in administrative overhead has significantly simplified our open source efforts.”

    Netflix operates with three development channels (a core Netflix OSS, Spinnmaker and a skunkworks project for new ideas). Thus, having a consistent permissions model across organizations can decrease friction. Also, since Netflix collaborates with third parties, such as contractors or other open source contributors, HubCommander also acts as an effective way to maintain security.

    Final Thoughts

    Netflix recognizes a growing popularity in the ChatOps approach and cites other benefits such as team transparency, a timestamp for each event and a self-service nature—all reasons for adopting a ChatOps strategy into its developer tooling.

    HubCommander appears like a good ChatOps tool for GitHub repository management. However, GitHub Actions (still in beta at the time of writing) is a new feature that will aid development workflows, offering automation for the GitHub operational duties themselves. This may spark alternative bots to be developed, especially in terms of workflows that respond to events.

    For now, with open source utilities such as HubCommander, certain GitHub duties can be quickened, stimulating a culture of more efficient management to decrease redundant tasks. While shorthand for GitHub repository management might not seem at first glance as a priority, it could scale down operational headaches tremendously.

    — Bill Doerrfeld

  • Twistlock Releases Cloud Discovery Open Source Tool for Cloud Native Services

    A simple, powerful way for audit and security practitioners to discover all ‘unknown unknowns’ across cloud environments

    PORTLAND, Ore., Nov. 13, 2018 /PRNewswire/ — Twistlock, the leader in container and cloud native cyber security, today announced the release of the open source Cloud Discovery tool. Cloud Discovery gives enterprise infrastructure, operations, and security teams the ability to easily understand and quantify the size of their environment, and get a birds’ eye view of what cloud native services are running and where. The first release supports Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), with more platforms to be announced.

    Cloud Discovery connects to cloud providers’ native platform APIs to discover services such as container registries, managed Kubernetes platforms, and serverless services, and requires only read permissions. Other key features include:

    • Network discovery to discover cloud native infrastructure and applications, such as Docker Registries and Kubernetes API servers
    • Instantly identify weak settings and authentication
    • Easily integrated into DevSecOps processes
    • Provided as a simple Docker container image that can be run anywhere and requires only read permissions to cloud accounts
    • Works well for both interactive use and automation
    • Outputs data into standard JSON for easy integration with other tools
    • Written in Go

    “In many organizations, IT ops, security, and audit personnel need to discover all the cloud native entities being used at their organizations,”  said John Morello, Chief Technology Officer, Twistlock. “This is often a result of development teams starting up resources and deploying cloud native applications, but the security or operations team may not always know exactly where they’re deploying them. We want to make that easy without creating any new security gaps.”

    “Since our founding, we’ve been committed to enhancing security efforts for the cloud native community through upstream contributions to open source projects,” said Ben Bernstein, Chief Executive Officer, Twistlock. “From creating the authorization framework within Docker and Openshift and secrets management for Docker Swarm, to the release of Cloud Discovery — open source is in our DNA. We hope Cloud Discovery helps the community and look forward to adding new features and components that benefit everyone.”

    View the Cloud Discovery repo (https://github.com/twistlock/cloud-discovery) on Github to get started or contribute to the project.  To learn more, visit Twistlock (https://www.twistlock.com/2018/11/13/open-source-cloud-discovery-tool/).

    About Twistlock
    Trusted by 25% of the Fortune 100, Twistlock is the most complete, automated, and scalable cloud native cybersecurity platform. From precise, actionable vulnerability management to automatically deployed runtime protection and firewalls, Twistlock protects applications across the development lifecycle and into production. Purpose built for containers, serverless, and other leading technologies, Twistlock gives developers the speed they want, and CISOs the control they need. For more information, please visit www.twistlock.com

  • Infosys Launches Open Source DevOps Project

    Infosys Launches Open Source DevOps Project

    Infosys has decided to make its DevOps platform—which consists of more than 2,000 prebuilt scripts and more than 150 pipelines spanning 70-plus tools involving more than 25 different classes of technologies—available as an open source project available via GitHub.

    Ravi Kumar, president and deputy COO for Infosys, said the global systems integrator has spent the last several years turning each element of its DevOps platform into a set of microservices based on containers that can now be deployed almost anywhere. That decision made it more practical for Infosys to then offer the up the entire DevOps framework it relies on to drive thousands of projects employing more than 200,000 developers as a single open source project, he said. That framework relies on an instance of the open source Jenkins continuous integration/continuous deployment (CI/CD) framework at its core.

    Each element of the Infosys DevOps platform can be consumed via a set of templates hat Infosys has developed. The goal is to reduce the amount of time any organization needs to spend developing that framework and processes required to accelerate any digital business transformation project, Kumar noted.

    To accelerate the development process, Infosys enables organizations to automate the promotion of any module without having to create any additional scripts. In addition, Infosys makes extensive use of encryption to make sure DevOps workflows are secure.

    Most recently, during the DevOps Industry Awards 2018 event, Infosys won awards for Best Overall DevOps Project in the finance, retail and communications, in addition to best automation project and most successful cultural transformation initiative.

    Kumar noted that DevOps is now integral to any digital business transformation initiative. Each organization today is required to significantly increase the rate at which applications are developed and updated to create a modern digital experience for customers, employees and business partners, he said.

    The single biggest hindrance when it comes to making the transition to DevOps within most organizations is a lack of tools and processes. Most organizations quickly become aware there is a chicken-and-egg relationship between tools and DevOps processes. Without the right set of DevOps tools, it becomes difficult to set up a DevOps process. But the tools in of themselves have no value without a set of well-defined processes in place. To enable organizations to address that issue in a holistic manner, Infosys developed the IT Process Enabler repository alongside a DevOps maturity framework.

    Most of the adoption of DevOps within most organizations has been driven by the bottom up by individual development teams resulting in adoption of DevOps that has been uneven at best. But as those individual DevOps initiatives become increasingly successful, there is now a lot of interest at the senior most levels of organizations in finding a way to drive DevOps processes across the entire organization. That requires a level of change process management that tends to proves too elusive for many organizations to achieve on their own.

    — Mike Vizard

  • Rollout Adds Configuration as Code Support and Integration with GitHub to Treat Feature Flags as Mission Critical Operations

    Plans to Open Source Flagship Platform to Drive Innovation and Provide Operational Benefits of Software Production Changes Without Sacrificing Management Processes

     San Francisco, October 24, 2018 – Rollout.io, a feature delivery and management company, today announced its feature management platform will leverage Configuration as Code (CaC) and a powerful integration with GitHub, so developers can treat feature flags as they treat any other mission-critical infrastructure.

    Additionally, Rollout plans to open source its feature management platform, providing greater flexibility and stronger ownership of feature changes in production. Both moves allow development organizations to gain the benefits of using feature flags – such as increased speed of development and deployment, and reduced risks of deploying new code – without sacrificing any of the known management processes that govern the software development lifecycle (SDLC).

    “Rollout’s CaC approach, the integration with GitHub, and the decision to open source its feature flag technology means that developers now enjoy the benefit of both worlds – faster development and deployment of new features without the risk of breaking things,” said Kyle Daigle, director of Ecosystem Engineering for GitHub.

    Feature flags modeled with CaC means that for the first time, software developers can design, implement, and deploy application features using the same processes used to manage code changes, like full change management, ability to rollback, track ownership of changes, and more, to reduce the inherent risks of breaking production. The ability to treat feature flags like configuration as code and use the same tools as any other software project allows dev teams to be more agile, and rapidly deploy features that add value to a business much faster than before.

    “Until now, control of feature flags has circumvented existing software development and deployment processes or known checks and balances for software development and production changes,” said Erez Rusovsky, co-founder and CEO of Rollout.io. “The decision to integrate our configuration as code with Git & GitHub and open source our platform means that product and development teams have consistent and reliable control of every feature in production, resulting in applications that are easier to develop and maintain.”

    Rollout’s feature management solution with CaC will initially leverage GitHub as an integration point with support for Atlassian, Gitlab and other hosting services coming soon.

    “We use feature flags to continuously deploy new features to production without risk so, it was important to find a solution that is engineering-friendly. One platform met those requirements, and it was Rollout,” explained Ron Shoshani, vice president of R&D at Testim.io. “Integration with GitHub allows our dev teams to work faster in collaboration on dev and deploy goals. Rollout’s plans for open source will ultimately provide us with more flexibility and ownership over the code that drives our business.”

    Using Rollout, developers, DevOps and product managers can speed the development and deployment of software, while reducing risk and improving customer satisfaction and experience. Rollout designed its management system with feature flags and controls for gradually releasing features in development and production with the ability to rollout back features when needed. This is possible by separating version release from feature deployments, and it provides companies with flexibility to deliver features to specific users at a granular level.

    Rollout supports multiple clients and backend platforms. It adds feature level support across an organization’s entire stack. The company also recently announced its integration with Atlassian’s Jira Software.

    Pricing for Rollout’s feature management is based on seats and MAU and starts at $75.00. To try Rollout, please visit www.rollout.io.

     Learn more:

    For more information on feature flags, check out Rollout’s eBook The Ultimate Feature Flag Guide or follow Rollout’s blog, or on Twitter @RolloutIO and LinkedIn.

    About Rollout.io

    Rollout.io is a feature delivery and management company that accelerates software development and release and minimizes the risk of deploying new code. It is the only unified platform for feature delivery, experimentation, and application-layer remote configuration. Built for engineers, developers and product managers, to rollout, rollback, test and adapt features at scale, in real time. Rollout gives teams full visibility and control of all application features to deliver the right feature to the right user at the right time. Founded in 2014, Rollout has offices in San Francisco and Tel Aviv, Israel. Learn more at www.rollout.io.

  • SnapLogic Extends DevOps Reach via GitHub

    SnapLogic Extends DevOps Reach via GitHub

    SnapLogic has extended the reach of its SnapLogic Enterprise Integration Cloud into the realm of DevOps by making it possible to store integrations creating using Snap connectors in GitHub.

    The company also announced integration with the DC/OS platform from Mesosphere along with a new service catalog and several updates to the Iris artificial intelligence (AI) software it uses make recommendations concerning the construction of integration pipelines. At the same time, SnapLogic has enhanced both its monitoring tools for application programming interfaces (APIs) and search tools for discovering broken integration pipelines.

    Craig Stewart, vice president of product management for SnapLogic, said support for GitHub makes it easier for developers at all skill levels to share preconfigured integrations via GitHub alongside all the other code they already share via the widely employed repository. That capability also makes it easier for DevOps teams to include preconfigured Snap connectors within a continuous integration/continuous development (CI/CD) pipeline, he noted, adding those integrations now can be more easily discovered within a Patterns Catalog to help developers discover and reuse integration patterns.

    Support for Mesosphere, Stewart said, is being provided by customer request. That effort will then be extended to include support for Kubernetes, which SnapLogic expects will become the de facto standard for container orchestration engine.

    Finally, SnapLogic updated its Iris AI software to provide an additional option for users to build their integration workflows starting with the last Snap of the integration pipeline. Previously, the Iris recommendation engine started with the first Snap connector. Now, when a user first places the last Snap on the canvas, the Integration Assistant will display suggested previous Snaps until the pipeline is complete. Users also have the option to start with the first and last Snaps of the pipeline and the Integration Assistant will work from the outside-in to recommend Snaps to build out the entire pipeline.

    SnapLogic is making investments designed to facilitate self-service capabilities that promote reuse of integrations, Stewart said. A recent survey of 500 IT decision-makers conducted by Vanson Bourne on behalf of SnapLogic finds on average organizations expect to generate a 547 percent return on their data investments, increasing revenue by an average $5.2 million by using data more effectively. But the survey also finds that on average organizations are using only half (51 percent) the data they collect or generate, and data drives less than half (48 percent) of the decisions being made. Organizations will spend $1.7 million on an average to operationalize data over the next five years to rectify that problem, according to the survey results, which is more than double what they currently spend.

    Much of that effort will be driven by so-called citizen integrators that reside within various lines of business outside the traditional IT department. In many cases those citizen integrators will be leveraging prebuilt integration patterns created by developer working within the internal IT department. The challenge now is finding a way to make sure all those integration patterns can be slipstreamed into a larger set of DevOps processes that are increasingly spanning the entire enterprise.

    — Mike Vizard

  • DevOps Chat: CI/CD with CircleCI’s Rob Zuber

    DevOps Chat: CI/CD with CircleCI’s Rob Zuber

    Microsoft’s recent acquisition of GitHub has spurred a lot of conversations regarding which company is the next big acquisition target, and here on DevOps Chat is no exception. In this episode of DevOps Chat, I speak with Rob Zuber, CTO of CircleCI about the CI/CD space, the future of the market and, yes, M&A activity in the DevOps space.

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

    Alan Shimel: Hey, everyone, it’s Alan Shimel, staging-devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Rob Zuber, CTO, CircleCI. Rob, welcome to DevOps Chat.

    Rob Zuber: Thanks. Good morning.

    Shimel: Good morning.

    Zuber: It’s a pleasure to be here.

    Shimel: Or afternoon, in my case, or evening. Who knows when people are listening to this? But, Rob, thanks for being our guest. I think this is the first time we’ve had anyone from CircleCI on a DevOps Chat here. So, you know, you are a mold-breaker and thanks very much.

    Zuber: I’m excited.

    Shimel: All right. So, Rob, our audience tends to be pretty DevOps-y, and so I’m assuming they know of CircleCI or at least have heard of CircleCI, but maybe they haven’t. So, in case they haven’t, Rob, give us a little background, just a real quick elevator, on CircleCI.

    Zuber: Yeah. So we’re a big part of the delivery pipeline for many software organizations. We offer continuous integration and continuous deployment, both as a cloud offering so that you don’t have to manage any of it yourself, but, if you’re interested in doing that, we also have a server-hosted version. And, you know, our objective is to help people focus on their business and get their software into market faster, taking out of the way the overhead of managing a lot of the tooling around doing that.

    Shimel: Yep. And, Rob, just in way of history and background and setting the table here, CircleCI really is – it was kind of a cloud-native CI/CD solution originally and it’s only relatively recently that you started having sort of an on-prem solution as well, offered as an option. So it’s kind of opposite of the usual SaaS migration, if you will, right, where people turn on-prem stuff into SaaS solutions. You were kind of a SssS solution and now offer an on-prem option.

    Zuber: Yeah, that’s exactly right. And that’s probably partly a function of when the company was started, so CircleCI launched in 2012. At that point, people were pretty comfortable with cloud offerings. GitHub had been around for a little while, so people were used to having the source code in someone else’s servers, and so we were able to leverage that a little bit. And we were able to grow quite effectively off of that base, but we did reach a point where there were very large customers with very specific needs, where it made a little more sense for them to run the software themselves and be able to have a little bit more opportunity to customize the environment in which it was being run, etc.

    One thing that’s interesting about that – and you talk about the difference in which way you go across that transition – because we built a multi-tenant platform from the beginning and really focused on our ability to operate that on behalf of other people, we find that, even in an on-prem solution, especially for very large organizations, we have a lot of the capability around that management at scale and centralized management that doesn’t – that still gives freedom to the individual developers to do their work. So it is actually quite interesting, how the genesis of the product affects how it operates in those multiple environments long-term.

    Shimel: Absolutely. Rob, another area – and I didn’t really talk to you off mic about this, but another area I wanted to explore was, historically, was CircleCI originally just CI or was it always CI/CD?

    Zuber: I think you could kind of look at that two ways. I mean, there was CD pretty early in the product, at least for some particular cases, but, if you look at the evolution of the software industry, many more people were doing CI in 2012 than CD. I mean, it was sort of this slow transition of people getting to, you know, “First, we’re gonna figure out Agile process and just how we do our actual software development. And then we’re gonna add CI on top of that. And then we’re gonna add CD.”

    So we always had some CD capabilities, but the number of our customers or the percentage or breakdown of our customers using CD has grown pretty significantly over that time, and I think that’s partly an effect of the kinds of tooling we’re offering, partly a shift in what CD even means, and then partly just growth in the market and comfort level of people doing that, right? Of – especially – and CD, of course, is always challenging ’cause some people are talking about continuous delivery and some about continuous deployment, but, in particular, on the continuous deployment side, other things had to come into play – you know, feature flagging, canaries, just better control of what it meant to actually put something in production. And so the comfort level and increase in that has led to more people using our platform for CD as well.

    Shimel: Absolutely. You know, as an observer of the space, sort of the market, I’d seen it come – when I first launched staging-devopsy.kinsta.cloud, four years ago, Rob, there was this clear sort of distinction between “We’re not CD. CD is something else. We’re CI,” or reversed – “Those folks are just CI. They’re not CD.” And it kinda just seemed like an artificial wall had been built, right? Not to get all political.

    But – and so I, for one, am happy to see sort of that wall being torn down and the natural flow of the software development life cycle, of the modern software factory, if you will, taking place, where CI kinda naturally flows into CD. And I think the next thing we’re seeing is this natural connection to what Gartner and some of the others call “ARA.” Right? Which I don’t even know what the difference between that and CD is, but I don’t know. What do you think?

    Zuber: Well, I think that, overall, this evolution, as I was saying, it always takes a long time for people to get – or, let’s say, for everyone to get comfortable with each of these stages of the evolution. And we’re always looking to the next frontier, right? So, at one end of the spectrum, you have those early adopters, who, in 2012, were doing CD or before that. I’m trying to think of the original sort of posts around CD that I think came out of, I wanna say, Etsy, but I don’t know if that’s actually true or me projecting kind of them as a pillar of this type of thinking. But, you know – and we’re still at a point where some people are just getting comfortable with and adopting it, so the spectrum is really broad, from early adopters to sort of overall mass adoption.

    And the early adopters have moved on to, probably, things that I haven’t even thought about, and so we’re always seeing that and it’s nice to have people try those things and, in some cases, fail, and, in some cases, discover really new and interesting ways of approaching stuff. And it takes – it definitely takes a little bit of a mindset of “I’m just willing to try this. I’m willing to take some risk and do new things,” and the people that do those create opportunities for the rest of us to learn from, the things that go well and the things that go horribly wrong.

    And so it’s one of the reasons that I just love being in the space in general, is just the constant kind of desire to do things better and find new opportunities, of course, with a good balance towards actually focusing on getting stuff done, but there’s just such a creativity and desire around improving, in any way we can, this process and how we get stuff out and how we build it reliably and work efficiently.

    Shimel: Absolutely. So, Rob, let’s turn a little bit to – we’ve done a nice history. Let’s look a little bit to the future now, though.

    Zuber: Mm-hmm.

    Shimel: Talk to me – what did – how – you’re the CTO. You kinda have a lot of the vision for CircleCI. Where do you see CircleCI and the market in general going?

    Zuber: Yeah. Well, that’s a great question. I think a lot of people’s perspectives of this market was changed a little bit in the last week or so, with news around Microsoft and GitHub and just the value that people are starting to recognize in developers, the happiness of developers, the efficiency, the value that they place on the tools that they use. So, for the market overall, I think we’re just a really exciting time, where we talked about this – or I talked about this creativity and passion to do things better, but we’re at a sort of inflection point where there’s a really, really high-level recognition of the value of that.

    I would say there’s been a significant shift in the mentality of many companies. And we talk a lot about how every company is becoming a software company, in that, even if you’re an airline, your biggest issue, when you ground your planes for a day, is that you have some software glitch somewhere, right? You know, multinational trading markets are shutting down on software issues. So the impact and value of software is becoming really, really visible and, as a result, there’s a shift in mentality about how we build software, from “This is a cost center that I just have to manage down,” to, “This is the core of my business and I need to be really investing and doing this in the best possible way.”

    And so that’s obviously exciting for us. And one of the things that’s really interesting for us, as we look forward, is that we – we’ve had the fortune of some success and growing and, to the best of our knowledge, run the largest or one of the largest build platforms on the planet. As a result, we know a lot about how people are building software, and so we’re investing a lot of our time and energy in figuring out how to use that to then help those people, meaning, if you’re building on CircleCI, you don’t just get an understanding of your particular code change that you just made, but you can get an understanding of how your team is doing, how your whole process is doing, how effective you are, relative to other teams out there.

    And I think that’s a place where we have a lot of opportunity to really add additional value for our customers, in not just, again, direct feedback on this one thing that you did today, but really helping understand your process, maybe where things aren’t working well, maybe where you have some opportunities to improve. We’re all in this, trying to be better every day. And if we can help customers at that at a higher level, that’s really exciting for us.

    Shimel: Yep. You know, it’s interesting you brought up the GitHub thing and to justify all this. And so I have some views on it. What a surprise. But, you know, Rob, couple things. No. 1, when you look at GitHub and the price Microsoft paid, it obviously is a ridiculous multiple to revenue. I saw a chart earlier today. I forgot if they said it was 21 or 24 times revenue, which is wow. Right? That’s why people do software companies.

    But another way of looking at it is, look, Microsoft has always coveted the developer community. And, over the last – I mean, for as long as I’m in technology, 25, 30 years, they’ve done not a crappy job of working with the developer community. Yeah, there are haters and Linux folks and the open source, when Ballmer was there, you know, but they’ve always gone after the developer community hard. And so they had an opportunity to buy a company that has, some estimates say, 28 million people or potential developers, right, in that community that GitHub has. So, when you look at 28 million and what they paid – don’t get me wrong; it’s still a lot of money, but it’s a little bit – you could see where they saw the value, okay?

    Zuber: Mm-hmm.

    Shimel: No. 2, having been in the tech, software infrastructure business a long time, I learned a lesson from my friend Brad Feld, who I sold my first company to and he financed or was one of the key VCs behind many of the companies I’ve been involved in, and that is, look, first mover or first – not the first mover, first acquisition in the space always gets the lion’s share and the best multiple. The second one does okay. The third one does a little worse. If you’re not in the top three, don’t bother. Right? That was something Brad always preached to us.

    So, when you look at Git – or GitHub, excuse me, being the first kind of acquisition in that space, getting this kind of multiple, they deserve it. Right? They were first. They were the first ones bought; they’re gonna get the lion’s share. I think the message to other folks in the GitHub space, specifically, is “Hurry up and get bought ’cause you don’t wanna be number four or five.” Right? You don’t wanna be left in the musical chairs game when the music stops.

    Part and parcel of that, though, Rob, is that companies like Microsoft, like IBM – we used to say “like HP, Cisco,” you know, big, big public entities – it’s very hard for them to be innovative. It’s very hard for them to do their own R&D. It’s very hard for them to build these communities themselves. And so what they would spend in R&D or community actually goes into their M&A budget and they buy those things.

    Zuber: Mm-hmm.

    Shimel: So, when we look at a GitHub, we look at a CircleCI, we look at any – a Chef, a Puppet, any of the – even the Jenkins or CloudBees, any of the players in this DevOps space that is so hot right now – GitLab, another one – they all are gonna be very attractive to companies of a Microsoft kind of girth. Right? Because the big guys can’t – they can’t do what you’re doing, Rob. They don’t –

    Zuber: Yeah.

    Shimel: You know.

    Zuber: Yeah. I mean, I think this is classic innovator’s dilemma, right?

    Shimel: Yeah.

    Zuber: Did I get that right? So it’s difficult. I mean, if you look at the first five year – I mean, we all talk about these overnight successes, right, and they always – they’ve been around for 10 years. And the first five years many of those companies is extremely painful, it’s a grind, and the incremental increase, the amount of revenue you’re driving or whatever, would be so insignificant on any one of these companies’ radar that they just – they won’t put the time and energy into it, right?

    Whereas you’ve got a company like ours or anybody in the space, honestly – I’ve done a bunch of different startups in different spaces – you’re living and breathing it, right? And you’re so tuned into what’s happening that you can see it. And that kind of incremental growth, to you, is everything and it’s super exciting and you get this passion behind it that allows you to build a very focused and, honestly, a great product. And I think GitHub is a great product. And then, suddenly, you have 28 million users – I’m quoting your number so I’ll assume you’re right –

    Shimel: _____ I’ve seen.

    Zuber: And a massive community. You know, and then, going back, as you were talking about the time and tech, I mean, I got into tech with the quarterly mailing of MSDN CDs and, honestly –

    Shimel: Exactly. Yeah.

    Zuber: – my favorite IDE – I’m a Mac and Linux user, almost exclusively, but I used Visual J++ in the late ’90s, when I started doing Java development. It’s still the best IDE I ever used. So Microsoft has been good, very, very good, with developers, but the kind of developer community has started to drift away from where they were going. And so this is – I wouldn’t call it a course correction because they still have all of their community, from a .NET and sort of Windows world, but this is an opportunity to be less about Windows, you know? And we’ve seen Microsoft shifting away from –

    Shimel: Oh, yeah. Satya Nadella’s Microsoft, Rob –

    Zuber: – just pure kinda _____ –

    Shimel: Not to step on you, but Nadella’s Microsoft is a very, very different place than when Steve Ballmer was there. Right?

    Zuber: Yes.

    Shimel: And they are moving to Azure and though Azure does Windows well, it does containers well, it does Linux, it does – you know, there’s very little it doesn’t do.

    Zuber: Right.

    Shimel: You know? And I will tell ya – I’ve told people this – I think, one day, Microsoft buys Docker. That’s my personal opinion. I think it’s another kind of – not to get into it or badmouth or anything like that, I just think someone’s gonna buy Docker ’cause the revenue has to justify the valuation, and so – and Microsoft’s a great candidate to do so. But, anyway, you heard it here first. But, Rob, that’s all fine and dandy. GitHub plays in sort of a different segment of this DevOps market than you guys do, certainly.

    Zuber: Mm-hmm.

    Shimel: And we really haven’t seen the consolidation yet, that I think we will in the CI/CD and, if you wanna call it, ARA space, but it’s coming. I’m sure.

    Zuber: Yeah, we’ve seen movement in the market, but most of it has been off the bottom end, if you will, meaning sort of the smaller people we would consider to be our competitors but didn’t quite reach critical mass and then got pulled in by other companies, for the people or because the product was going to be useful to them internally, that sort of thing. Not a roll up and now we’re taking this and getting it scales or _____ –

    Shimel: So we used to say, when I worked with Brad, those are companies that really were a feature, not a product.

    Zuber: Mm-hmm.

    Shimel: But, with that being said, Rob, we went off on a little bit of tangent here. We’ve used up way more time than we were supposed to. But maybe we could have you back on and – ’cause I wanted to really get into a little nuts and bolts around continuous integration, delivery, what it means for developers, what it means for ops folks, but why don’t we do this? We’ll call it a day on this 25-minute DevOps Chat and we’ll have you back on maybe next month. And let’s get into what it means for developers and ops folks in even testing, in this new world of CI/CD.

    Zuber: That sounds great. I’m always happy to talk about that as well. There’s so much happening in this industry, in this space right now, that it’s hard to keep it short. [Chuckles]

    Shimel: You know what? Hey, man, it keeps my kids going to college, Rob. [Laughs] Anyway, hey, Rob, Zuber, CTO, CircleCI, this episode’s guest on DevOps Chat. Thanks for joining us. This is Alan Shimel. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • 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

  • 10 Views on What Microsoft’s GitHub Deal Does for DevOps Users

    10 Views on What Microsoft’s GitHub Deal Does for DevOps Users

    The DevOps and open source communities have been in a tizzy all week over the massive $7.5 billion Microsoft acquisition of GitHub. Even as many developers rage on Twitter about the deal and still others are rushing to migrate their repositories to alternative solutions—#movetogitlab has trended heavy this week—for the most part the DevOps community is taking it in stride. As staging-devopsy.kinsta.cloud’s Don MacVittie explained, complaining or planning a move away from GitHub solely due to long-held grudges against Microsoft seems pretty counterproductive at the moment.

    He’s not alone. A lot of developers, evangelists, CTOs and other GitHub users out there doing the work that drives applications into production are looking at this as a potentially great thing. Others are more cautious, but at least believe this won’t set the movement backward. We’ve gathered a few thoughts from these professionals to help balance out the dialogue.

    Ensures GitHub Viability

    “For those developers that may be anxious and thinking about jumping ship, I am sure they also must realize the hard truth that for GitHub to succeed moving forward it needed an influx of cash. Inevitably, there would come a point where GitHub would need to start to actually turn a profit, something it has yet to achieve, before it would have to shut its doors. ”

    —Adam Mansfield, Microsoft practice leader at UpperEdge

    Provides Much-Needed Leadership

    “Satya Nadella has so far done a great job dropping the Windows religion to embrace the reality of the iOS, Android, Linux and multi-cloud world, which he will hopefully continue with the GitHub community. By putting Nat Friedman—former CEO & co-founder of Xamarin—in place as a technical CEO, Microsoft is sending a clear message that they’re committed to GitHub and the larger developer ecosystem.”

    —Jyoti Bansal, former CEO of AppDynamics and current co-founder of DevOps platform Harness

    GitHub Champions in Enterprise Have Easier Sell

    “For one, I wouldn’t be surprised if we start to see corporate firewalls allowing access to GitHub now that it’s a Microsoft owned property, and perhaps considered ‘enterprise-ready.’ Microsoft knows how to make products that make enterprise architects feel confident, so their blessing and ownership of GitHub could really encourage social coding within enterprise organizations.”

    —Matt Stratton, DevOps evangelist at PagerDuty

    Net Neutral Immediate Impact

    “Developers should not be anxious about this acquisition nor should they be excited. I honestly think this is an ‘oh well’ moment. Unless Microsoft has some crazy plan to sunset features or support for one vendor or another, everything should behave as business as usual for the foreseeable future. The only thing developers should watch is license fees and terms and conditions. Expect Microsoft to monetize the solution better in the coming months and potentially tie usage into MSDN.”

    —Morey Haber, CTO of BeyondTrust

    GitHub Already Had Its Own Problems

    “GitHub is not strong in this area (DevOps) and never has been; maybe if Microsoft made it easy to deploy to Azure it could be seen as an improvement. As a tangent, GitLab which is now the attractive alternative, has its own CI/CD tooling and can also be self-hosted for free. This is a major advantage over GitHub, and I’m wondering if corporate America will start looking more closely to the FOSS alternative to GitHub Enterprise.”

    —Mitch Pirtle, longtime developer and consultant at SpaceMonkeyLabs, former Tech Fellow at Capital One

    Opens Eyes for About Dangers of Centralization

    ” My hope is that – one way or another – this leads to greater competition, more innovation, and less reliance on any one single platform. I don’t feel that centralization around any one platform is good for the DevOps and FOSS communities. I also don’t feel consolidation to larger companies is a good thing, as it creates conflicts of interest and generally a lack of innovation. This consolidation could result in a more decentralized approach to both software development and DevOps integration, which will hopefully drive more innovation. I think that could ultimately be a positive outcome of this acquisition.”

    —Jeremy Steinert, CTO of WSM International

    Expect Better Integration for More Seamless CI/CD

    “Longer term, I expect GitHub’s integration with Azure to expand substantially, enabling some truly exciting developments for one-click code deployment to a Cloud infrastructure. DevOps for smaller companies will gain easier access to Azure resources. For DevOps as a whole, we will see acceleration of seamless code management within the context of actual deployment to containers. DevOps for enterprise has the greatest potential for improvement with this deal. There will be massive investment in improving developer interactions between infrastructure and code.”

    —Clint Wilson, VP of product management at DigiCert

    Here Come Better Enterprise DevOps Features

    “While I think the development community will have mixed emotions about the news, ultimately this is a massively positive moment for GitHub. GitHub is at the center of the developer community, but as a business, they have faced challenges in reaching the enterprise buyer—something Microsoft is extremely well-versed in. With Microsoft’s resources and expertise, GitHub no longer has to wrestle with the internal struggle of being open to the community and being open for businesses, ie. selling to the enterprise. Assuming it’s kept a separate entity and is not beholden exclusively to Azure, this acquisition gives GitHub the opportunity to deliver the features enterprise DevOps and development teams need.”

    —Tal Weiss, co-founder and CTO of OverOps

    Accelerates GitHub’s Servicing of DevOps Market

    “The new Microsoft is not the bogey of the past — VS Code is great; TypeScript is terrific; Microsoft has not merely accepted open source, but become an open source leader through its GitHub contributions. From a business perspective, I think the deal will pay off. Unlike competitors such as IBM and Oracle, Microsoft not only understands developers, but has a proven ability to sell to the SMB as well as to the enterprise market. Microsoft can probably grow the GitHub business substantially by executing better on GitHub’s existing strategic objectives, such as GitHub Enterprise, without alienating users. It may also be able to create significant value by applying its AI technology and VS Code innovation to GitHub’s enormous corpus of code.

    —Rod Johnson, co-founder and CEO of Atomist and creator of Spring

    Validates Value of What Open Source and Devs Do

    “I think overall this is good for the DevOps movement, and open source in general. It’s a very strong validation of how important open source is not just to open source developers, but also the business world. Developers have a right to be anxious, but there are many viable options for open source hosting in this day and age, so if Microsoft does not prove to be a good steward of GitHub, they have other options. However, Microsoft could very well keep GitHub going.”

    —Logan Abbott, president of SourceForge.net

    — Ericka Chickowski

  • Microsoft and GitHub: The Sky is Not Falling

    Microsoft and GitHub: The Sky is Not Falling

    The consternation seen in some corners of the internet over Microsoft’s agreement to acquire GitHub is overblown and too early.

    For those who don’t follow me normally, I am a developer for Windows, Android and Linux. I am also a user of both GitHub and BitBucket. While I am an advocate, I am more of an IT productivity/tools advocate than a pro/con MS advocate. So pretty much, I am IT. I’ve worked in pretty much every IT environment from developing embedded devices to cell phones to apps for smartphones to a raft of enterprises from financials to utilities.

    Until we know what Microsoft intends with GitHub, it makes no sense to go crazy with plans to migrate away from the platform.

    Oh, I could draw up plans to move my company’s GitHub repositories to BitBucket (or GitLab, or wherever), but honestly at this point there is no reason to do so. We (all of IT) have a limited amount of time available, and is migration away from GitHub the best use of that time?

    I argue that at this point, it absolutely is not.

    Stop. Breathe.

    There are things Microsoft could do that would make my company want to move away from GitHub. I do not expect that any of those things will happen. Or if they do happen, it is because they were going to happen anyway.

    Remember, early rumors of this merger started with, “They were working on joint marketing, and GitHub let slip they needed a cash infusion …” needed a cash infusion. That means something at GitHub needed to change regardless of ownership. You don’t go as long and get as large as it has and need a cash infusion, if you’re doing things right. So change was likely coming, regardless of ownership.

    But until we see what Microsoft has planned, expending energy either complaining about it or planning to move away seems like a bad use of your time. As long as git pull still works, and the terms of service haven’t changed, it is much ado about nothing.

    Stay focused on your customers, and keep a wary eye on developments with regards to all of your back-end tools, but don’t waste energy in potentially unnecessary or fruitless exercises. Think about it, and if it becomes necessary, we can all make careful, planned moves when it’s clear that is the proper course.

    — Don Macvittie