staging-devopsy.kinsta.cloud

Tag: github

  • GitHub Extends Scope and Reach of Repository

    GitHub Extends Scope and Reach of Repository

    GitHub today at its GitHub Satellite virtual conference announced it has made it easier for developers to either launch a project or join an existing project on its repository and has added collaboration tools directly within the platform.

    GitHub is also moving to advance DevSecOps by adding code scanning tools and making secret scanning tools available for private repositories, in addition to making available GitHub Private Instances to provide organizations in highly regulated industries access to a more secure managed implementation of the GitHub repository.

    Max Schoening, VP of Product Design, said GitHub Codespaces removes a lot of friction associated with starting or joining a project by enabling developers to spin up a project in seconds. In many cases, he said, developers never launch a project simply because the effort required was too great relative to the value of the effort.

    Available in limited public beta, GitHub Codespaces should not only improve developer productivity but also significantly increase the number of projects being hosted on GitHub, said Schoening.

    GitHub Discussions, meanwhile, will provide a threaded format to organize unstructured conversations without having to leave the GitHub repository. Scheduled to be available in beta shortly, GitHub Discussions should increase developer productivity in addition to providing a place for developers to maintain a frequently asked questions document. Over time, Schoening said GitHub expects millions of communities to be formed around GitHub Discussions.

    GitHub is also moving to make DevSecOps a natural extension of any application development project. GitHub Advanced Security Cloud provides access to native code scanning and secret scanning tools that can be embedded within the developer workflow. Currently in beta, GitHub Advanced Security Cloud is based on security tools it gained via its acquisition of Semmle last year. Every Git push can now be scanned using a CodeQL semantic analysis engine to discover vulnerabilities. GitHub Advanced Security Cloud is designed to be an extension of an existing GitHub Advanced Security service.

    Finally, GitHub Private Instances will provide a fully managed alternative that, among other things, allows for bring-your-own-key encryption, backup, archiving and compliance with various regional data sovereignty requirements. GitHub did not reveal, however, when GitHub Private Instances will be available.

    As GitHub continues to evolve as an arm of Microsoft, there is no doubt more IT teams will be embracing DevOps. The biggest challenge is often making it easy to get started. In fact, many developers may find themselves unconsciously embracing best DevOps and DevSecOps processes as they, for example, employ scanning tools baked into the GitHub repository.

    Of course, no one knows for sure whether organizations will continue the pace of application development projects in the wake of the economic downturn brought on by the COVID-19 pandemic. However, Schoening noted the amount of time between pull requests has declined on the GitHub repository, which he suggests is an indication of increased activity and productivity now that more developers are working away from the office.

  • GitHub Makes Private Repositories Free for Unlimited Users

    GitHub Makes Private Repositories Free for Unlimited Users

    GitHub this week announced is making available private repositories for an unlimited number of collaborators available to all GitHub accounts for free.

    Kelly Stirman, vice president of product strategy and marketing, said that subsidiary of Microsoft could make this move because it is now generating enough revenue from the enterprise edition of its platform to sustain its business model.

    Previously, organizations that wanted to use GitHub for private development needed to subscribe to a paid plan. DevOps teams that need access to advanced features such as code owners or secure access markup language (SAML) support will still need to upgrade to a paid plan. However, the cost of a paid Team plan has been reduced to $4 per user/month from $9 per user/month, effective immediately, as part of an effort to increase the use of paid plans around the globe. Existing customers of paid plans will also see their bill reduced, added Stirman. Alternatively, existing customers can downgrade their current plan to take advantage of a free service.

    The overall goal is to increase the number of projects being developed on GitHub, said Stirman. Many open source projects generally get started by small groups of developers that are not initially ready to share their code publicly. GitHub provides an affordable way to launch those projects among a core set of developers that may not have ever met one another.

    Stirman also noted private repositories on GitHub provide a much more cost-effective alternative to standing up a private repository in an on-premises IT environment that requires IT teams to provision and manage their own infrastructure.

    GitHub also tracks all the vulnerabilities that are discovered in open source projects hosted on the platform, which is information that is shared with every developer on the platform, added Stirman.

    Additionally, GitHub provides access to a content delivery network (CDN) to more easily share code across geographically distributed teams of developers, Stirman said.

    It’s hard to forecast how much pent-up demand there is for access to a free private repository for an unlimited number of collaborators. GitHub has previously made private repositories available for a limited number of collaborators. Nevertheless, Stirman said there was a massive spike of adoption on the first day the new plan was available.

    In addition, Stirman noted there has been a marked increase in the number of teams that are working on projects related to COVID-19 research.

    Of course, the more development teams that are exposed to repositories such as GitHub the more likely it becomes more of those teams will find themselves to varying degree embracing best DevOps practices. Invariably, those bet practices will then find their way into a larger number of enterprise IT projects. Undoubtedly, GitHub views making private repositories available for free as a method to create increased demand for the enterprise edition of its platform down the line. Of course, rival providers of continuous integration/continuous delivery (CI/CD) platforms will be seeking to convert as many of those projects into enterprise customers as well.

    — Mike Vizard

  • GitLab Responds To GitHub Making Teams Free – We All Win

    GitLab Responds To GitHub Making Teams Free – We All Win

    Microsoft’s GitHub recently announced that it was going to make a change to its product lineup by making the team version of GitHub free and lowering the price on a full-featured version. The move seemed aimed squarely at matching GitLab’s offering. Well, now GitLab has responded to GitHub.

    While both of these excellent offerings compete to bring the best product to market, the real winners here are all of us. True market dynamics are at play resulting in both GitLab and GitHub lowering prices and adding more features (and not just GitHub and GitLab but also their competitors, including Atlassian among others).

    I had a chance to sit down with Sid Sijbrandij to discuss GitHub’s move, what GitLab will do and what this means for the market. (BTW, I have to apologize to Sid—it seems I have been mispronouncing his name for years and he is too much of a gentleman to correct me. The proper pronunciation of his name is “See Brandy.”) The video of our conversation appears below, and a blog on the GitLab site explains it all.

    In our interview, Sid was very clear that GitLab owes a huge amount of gratitude to GitHub, as it was GitHub that spurred on the early development of GitLab. He truly respects what GitHub has done, as well as the great job Microsoft has done since acquiring GitHub.

    The GitLab blog post lays out very clearly what the GitHub offering is and how it compares to the GitLab offering. It’s no coincidence that the new GitHub paid teams offering is the same price as the GitLab bronze offering.

    Price aside, according to Sid, the real advantage of GitLab is that its vision of an end-to-end total DevOps solution and the features it adds to achieve this vision give GitLab customers more than they can get from GitHub. While I agree that is true today, I don’t think GitHub is going to be content with its current lineup for long. I think the Microsoft entity already envisions a total DevOps solution as being part of GitHub’s future.

    On top of that, I think GitHub and Microsoft are already thinking of how they can leverage Azure to give GitHub an advantage. To Microsoft’s credit, though, at least until now there has not been any special advantage of using GitHub with Azure. Azure remains an open platform that all vendors seem to get fair access to and support from.

    All of this aside though, we are all the real winners here. What a great time to be a developer/DevOps professional. While GitLab and GitHub compete with each other to bring more features to market for less money, as I mentioned other companies are competing to bring end-to-end DevOps solutions to market as well. We benefit from all of this competition by getting better tools and solutions at better prices. That’s true market dynamics at work.

    It should get only better in the months and years ahead as well. In spite of COVID19 and the rest, it is a great time to be alive.

    — Alan Shimel

  • DevOps Chats: Plugins Extend Spinnaker for the Enterprise

    DevOps Chats: Plugins Extend Spinnaker for the Enterprise

    Spinnaker Summit 2019 Preview: Secrets management is vital to any vibrant DevOps and GitOps toolchain. As part of its open source maturation and thanks to the contribution of our DevOps Chat guest, Spinnaker now has a secure secrets management capability enabling GitOps, taking non-application secrets out of plaintext in hal config files.

    Cameron Motevasselani, software engineer at Armory, is giving his talk “Spinnaker Plugins: Extending Spinnaker for the Enterprise” on Sunday, Nov. 17, at 10:45 AM PT.

    In addition to his contributions to Spinnaker’s new secrets management facility, Cameron shares the work in progress to create an extensible Spinnaker plugin system. The current work is an early MVP to be followed by the implementation of PF4J and concrete extension points as part of Spinnaker stages.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley with staging-devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Cameron Motevasselani—Motevasselani, thank you [Laughter]—a software engineer. He’s also a speaker at Armory. He has a couple of talks that are at the upcoming Spinnaker Summit 2019 in San Diego. First one—I guess this first one is on the plugin system and the second one is on secrets management.

    So, Cameron—welcome to DevOps Chat.

    Cameron Motevasselani: Hi. Thanks for having me.

    Ashley: Glad to have you on. Well, tell us a little bit about yourself. Introduce yourself and tell us a little bit about what you do at Armory and what Armory does.

    Motevasselani: Oh, totally. Yeah. So, I’m Cameron Motevasselani. Thanks for the quick introduction. Let’s see, I’ve been at Armory for about a year now. I joined and hopped feet first and started working on this secrets management project. So, that was pretty cool. And then, now, recently, I’ve been working on this plug-ins system. Yeah, that, I think, about sums it up.

    Ashley: Great. What does Armory do? Yeah.

    Motevasselani: Yeah, Armory, we basically have an enterprise offering for Spinnaker. So, we have some extensions that we’ve written on top of Spinnaker, so we don’t fork and have to maintain all that, we just—we extend Spinnaker and provide some extra features that way.

    Ashley: Very nice. Now, the way you phrased that, you’ve been working on secret management and the plugin. Does that mean you’re actually contributing, writing code and contributing it to the open source, or are you primarily an implementer of what’s already been built?

    Motevasselani: Oh, no, that’s a great question. Yeah, for the secrets management as well as plugins, we both, we’re contributing directly to open source for both of those projects.

    Ashley: Awesome. Excellent. Well, let’s start with secrets management. I mean, I think we all kinda have the idea of where we’re gonna keep our keys, our passwords, certificates, all that good kinda stuff. We don’t want that heading into the source code management system or somewhere in the cloud or in someone’s software. Tell us a little bit about the secrets management part of Spinnaker and what you’ve been doing, what you’re gonna talk about.

    Motevasselani: Yeah, totally. So, secrets management really came up as we started talking with customers about their Spinnaker setups and how they deploy and manage the configurations for Spinnaker.

    As you know, Spinnaker has the keys to the kingdom, essentially. It has your cluster keys and your credentials in order to deploy cloud resources that cost you money, right? And those are running—it runs the code that your organization arrives on. You can’t have that in source control. That is not, not good to have.

    Ashley: No-no—a big no-no, though a common mistake. [Laughter]

    Motevasselani: That’s right. Right. [Laughter] I think GitHub even yells at you now, if you have keys—

    Ashley: Oh, does it? [Laughter] Nice.

    Motevasselani: – in there. So, they’ve been adding nice little security features here and there. People would like to move towards this idea of GitOps so that you can manage your configuration via pull requests. It’s a great idea, and a lot of people can’t do that, because the keys are quite literally in the Spinnaker configurations.

    So, we pull those keys out and are essentially referring to them with our secrets management solution. So, you can use different backing stores such as S3 buckets or Vault and store your secrets there and then refer to them in the Spinnaker configuration that way.

    Ashley: Mm-hmm. Excellent, great. So, in your talk, you’re gonna be walking through what you’ve been doing, the functionality of it, how to implement it via GitOps?

    Motevasselani: Yeah, so—that’s right. The functionality, how it differs from, there are other solutions coming into open source now that tackle a slightly different use case. So, discussing the differences there as well as the future, essentially, of secrets management.

    Ashley: Okay. Very good. Great. Anything else to tell us about that before we move into the plug-in system?

    Motevasselani: Yeah. You know, secrets management, it is about the secrets for Spinnaker in particular. It’s not actually tackling the application secrets themselves.

    Ashley: Oh, okay.

    Motevasselani: So, I just wanted to make that clarification. And that’s at the current time. It’s possible that we might have a story for that in the future, but the talk that I’ll be giving is around Spinnaker secrets, not application secrets.

    Ashley: Okay. So, this is just what’s required to run, operate, manage the Spinnaker environment, not your application secrets?

    Motevasselani: That’s correct.

    Ashley: Okay, great. Well, that’s an important clarification. Great. Well, let’s talk about the new plug-in system. What is new about it, other than being new code?

    Motevasselani: Yeah. So, the plug-in system is, we’ve been developing it as a very—it’s been a very alpha, MVP type feature. So, right now in open source, we do have a method for users to create custom stages in Orca. There is quite a bit of knowledge and expertise that you have to have in order to do that, so I don’t quite recommend doing it right now. But we’re building on this plug-in system and we’ll be testing it out with users hopefully in the near future.

    So, right now, there’s currently no UI, but we’re working on a UI and then that should be getting open sourced as well in the future.

    Ashley: Now, that sounds like kind of a tough assignment. How do you create a plug-in system that anybody can do anything they want with, because that’s probably one of the requirements is, you want a lot of flexibility. How do you go about architecting and designing that so what you’re building can be extensible and you’re not gonna have to re-do it in a year?

    Motevasselani: Yeah, that’s such a great question. Because we are going with this MVP model of just getting something working and then getting feedback on it to iterate, we actually are already planning on deprecating this first, let’s say, method of loading plugins into Spinnaker. We’ve already been doing some internal revs on it and we’ve been working with the community, Google and Netflix in particular, on this project. So, we are going to be moving away from our current implementation into another full-fledged plug-in framework, and we’ve chosen PF4J for that.

    Ashley: Okay. Now, I’m not familiar with that framework. Can you tell us a little bit about that?

    Motevasselani: Yeah, so the way we currently did it—and hopefully, this isn’t giving too much of my talk away [Laughter]—but the way we’re doing it right now is essentially shoving JARs into a ClassLoader for Orca. Well, via Quark. So, these are different Spinnaker services and libraries that make up Spinnaker.

    Ashley: Mm-hmm.

    Motevasselani: Right now, it’s a pretty dumb way of doing it, just adding JARs onto a Classpath in order to load it onto the Spinnaker spring application context.

    Ashley: Makes sense. Pretty easy way to do it.

    Motevasselani: Yeah, exactly. But like you’re saying, there’s no—it’s very open ended right now. We are going to, as we move to PF4J, define concrete extension points within Spinnaker so that there’s actually not a sprawl of extension points, there’s clearly defined extension points throughout the code.

    Ashley: Mm-hmm.

    Motevasselani: That will help us iterate on this feature and make sure it’s a good solution as we continue developing it.

    Ashley: Okay, and this is the PF4J that’s on GitHub? I think it’s an Apache license, right?

    Motevasselani: Yeah, that’s correct. I believe it’s Apache. That’s correct. And so, moving into PF4J will give us a lot of really nice features that our current implementation doesn’t have, such as using a different ClassLoader for every plug-in so that it can have its own dependencies, et cetera.

    Ashley: That makes a lot of sense. Are there any unique challenges for implementing a plug-in system in an environment like Spinnaker? You know, this is software to create software, software to deploy software. You know, it’s not an application in and of itself, it’s something that you’re gonna make a key part of your kinda tool chain, your workflow pipeline. I wonder if there’s any unique challenges that come about in trying to build this.

    Motevasselani: Yeah, it’s interesting, because we have been looking at, you know, as you develop something new, you look at prior art in order to determine how to build what you’re building, I guess. [Laughter]

    Ashley: Mm-hmm.

    Motevasselani: For lack of a better word.

    Ashley: Technical speak, I know. [Laughter]

    Motevasselani: That’s correct. [Laughter] So, looking at something like Jenkins or Eclipse that both have plug-in systems, same with WordPress, those are all kind of monoliths, right?

    Ashley: Mm-hmm.

    Motevasselani: Spinnaker is definitely many different microservices composed into one application. Essentially, we’re just kind of turning it into a platform, kind of, by making it extensible and pluggable.

    But that is, to answer your question, a major challenge is, you have all these different microservices. You know, depending on how you deploy and update your Spinnaker installation, they might be on different—I don’t wanna say different versions, but if you’re deploying master all the time, you might have a different set of microservices in production compared to if you’re all running the same release version.

    So, deploying plug-ins into that environment is not an easy task and how you get the versioning done is important, as well as rollbacks.

    Ashley: You kinda have a recursive problem here, right? Because you have to version control the plug-in manager, which then version controls of what plug-ins can work with it, c?

    Motevasselani: Yeah, exactly. Plugins might rely on some functionality that is in one version of a microservice that’s not in another version, and if you need to do a rollback, how does that work, et cetera. That’s correct.

    Ashley: Well, you kinda took my breath away for a moment. You scared me when you said, you mentioned the WordPress plug-in system.

    Motevasselani: [Laughter]

    Ashley: Please, don’t do that! [Laughter]

    Motevasselani: I do think, though, that WordPress is an example of a project that has done very well—

    Ashley: They have.

    Motevasselani:—because it has such as good ecosystem of plugins.

    Ashley: It’s come a long way. It has come a long way. It’s much more, I don’t know, not self-sustaining, but kinda auto updating much better than it used to be. [Laughter]

    Motevasselani: Right, right. And we do hope to take learnings, right, from past projects, let’s say, as well. [Laughter]

    Ashley: Absolutely. I don’t mean to dis WordPress, you know? You gotta every once in a while. Well, tell us a little bit about more about your talk. What are you gonna cover, then? Is this more how to use it, or you’re gonna lay out kinda where you’re going in this next version and you’re looking for feedback? What are you trying to accomplish or get out of it? What would you like to have happen in the talk?

    Motevasselani: Yeah, you know, that’s a really good question. I think there’s a lot of stuff to cover, all the way from our journey running and creating this project, working with the community and those efforts, to showing users, “Hey, this is actually a nice and easy way of modifying or extending Spinnaker’s functionality.”

    The idea here is to—there’s kind of a few ideas here with this project, because we really want to lower the barrier of entry for users, particularly in enterprises, to be able to create extensions for Spinnaker. The method we chose to do this at first was a way that most users interact with Spinnaker, and that’s creating pipelines and defining stages.

    So, let’s say an enterprise has some custom infrastructure at their business running their data centers, running their cloud. If they want to, let’s say, interact with that in a native—in a Spinnaker native way, you would want to have a stage that their users can just choose. So, rather than having to learn how Spinnaker works on a very deep level, you can implement this nice, simple interface and get it going.

    So, at the end of the talk, it would be great for the audience to have an understanding of how to create and implement their plugin on their own.

    Ashley: Oh, excellent. Well, then, hopefully, you can, you’re creating an audience and a community to go out and try your new plug-in system and the variations of it.

    Now, you talked about using plug-ins as extensions to Spinnaker. Do you also see this plug-in system being kind of an integration interface to third party tools, maybe other open source, other commercial tools, or is it more things that just extend the functionality of Spinnaker?

    Motevasselani: Oh, that’s a really good question. So, there is a push to move Spinnaker to be a lean core and an expansive ecosystem, I believe, is the term being used, and this goes directly towards that goal. There’s certain functionality in Spinnaker, the core, Spinnaker core, that doesn’t quite make sense.

    For instance, there’s some stages that are specific to companies. Don’t wanna call Gremlin out, I think they do great work. There’s a Gremlin stage in Spinnaker that should probably be a plug-in. So, hey, Gremlin guys, hit me up. [Laughter] But not quite yet, maybe for the end plug-in system.

    Ashley: It’s that evolution of software, right?

    Motevasselani: Exactly.

    Ashley: I mean, that’s how you get to this point where you need to do that, you need to spin things out, so it’s part of its growth.

    Motevasselani: That’s right, that’s right. Yes. It would be really cool if you could have a Spinnaker installation where you can essentially pick and choose which cloud providers you want to have installed and running. If you only—you know, if you interact with, let’s say, both Google and Amazon’s cloud, maybe you don’t need Oracle’s cloud software to be on your cloud driver. Or maybe you want to have a cloud driver in each of those data centers—sorry, in each of those cloud accounts that only has the code necessary to deploy to that cloud environment.

    Ashley: Mm-hmm.

    Motevasselani: So, then you have a smaller attack surface, just leaner and smaller binaries, et cetera, et cetera.

    Ashley: Great. Well, I think, unless there’s anything you wanna add, I think you’ve given a really comprehensive look to kinda what that talk, both talks are gonna be about.

    Motevasselani: Yeah, that’s—you know, that’s hopefully, just getting the community excited and get some ideas flowing, I think, would be great with those talks.

    Ashley: Well, and I also wanted to just throw in my little thanks just to appreciate what you do and all the other contributors to the projects in software. And I always encourage people who are just using open source, and there are folks at the Spinnaker Summit who are implementing it, not writing code for Spinnaker, but talking about it at a summit like this is another way to contribute to the community. So, great to talk with you who are actually writing code as well.

    Motevasselani: Yeah, thanks. Nice talking with you, too, Mitch.

    Ashley: Great. Well, it’s been my pleasure. You’ve listened to another DevOps Chat podcast. I’d like to thank today’s guest, it’s Cameron Motevasselani, software engineer at Armory, and he is speaking at Spinnaker Summit 2019. The dates for the conference are November 15th through 19th in San Diego, and Cameron has two talks. His talk on the plugins is Saturday, November 16th, at 2:30 p.m. And then he’s also talking bright and early about secrets management—boy, you’re really gonna wake ‘em up here—Sunday morning at 9 a.m., Cameron, so. [Laughter]

    Motevasselani: [Laughter]

    Ashley: So, you know, maybe you serve mimosas at the morning talk. [Laughter] So, it’s been my pleasure to have Cameron on, and thank you to all of our listeners today for joining us. This is Mitch Ashley with staging-devopsy.kinsta.cloud. You’ve listened to another DevOps Chat podcast. Be careful out there.

    — Mitchell Ashley

  • Anaxi Adds Reporting Capabilities to ALM Tool

    Anaxi Adds Reporting Capabilities to ALM Tool

    Anaxi today announced it has added reporting capabilities to its namesake application lifecycle management (ALM) tool that make it possible to update stakeholders about the status of software development projects residing in repositories such as GitHub and Bitbucket Cloud as well as project management applications such as Jira.

    Company CEO Marc Verstaen said reporting capabilities will make it easier to employ Anaxi to, for example, keep business leaders apprised of updates to software development initiatives by enabling IT leaders to generate a report similar to how business leaders today employ a business intelligence (BI) application to share sales forecasts.

    The Anaxi tool is designed to provide IT leaders with a single tool for tracking progress being made across multiple DevOps platforms. Verstaen said as more organizations begin to realize they are really software companies, interest in software delivery management tools is on the rise. The reporting challenge IT leaders face is the information they need to create a holistic report lies in multiple repositories because of the inherently fragmented nature of the DevOps tool chain, he said.

    To make it easier to adopt Anaxi, the ALM tool Data employs the same credentials organizations have created to access GitHub, Bitbucket and Jira. The Anaxi app connects directly to a user’s GitHub or Bitbucket repositories and Jira projects to ensure data privacy and security. Any action performed on the Anaxi applications is written back on GitHub, Bitbucket and Jira to maintain consistency across projects involving multiple team members.

    At its core, Anaxi is pulling metadata from DevOps tools to apply analytics to track individual developer productivity and team performance. IT leaders can, for example, analyze how much code has been added and removed, refactoring and code churn on a weekly basis. Anaxi can be used either in place of a project management application or as a complement to an existing project management tool to make analytics more accessible.

    The primary goal is to make it easier for IT leaders to identify DevOps bottlenecks and prioritize projects in a way that advances business goals. Too many organizations are writing more code than ever only to discover projects are being held up because a single component on which every other module depends is behind schedule. Many of the developers writing that code could have been working on other projects if IT leaders had been made aware of changes that needed to be made to the schedule based on the anticipated delay to another project. Anaxi essentially applies predictive analytics to software development projects to determine based on past histories the likelihood of a deadline being met, Verstaen said.

    Armed with that intelligence, IT leaders can either proactively reallocate how resources or allocated or inform business stakeholders to changes in delivery schedules. In either case, Versaten says the goal is to enable IT leaders to avert any software development crisis that might arise.

    The Anaxi app is free to use by teams of up to 10 members. Teams of more than 10 users will be required to adopt a premium plan priced at $19 per month per user.

    — Mike Vizard

  • GitHub Enterprise Server Update Extends Enterprise Push

    GitHub Enterprise Server Update Extends Enterprise Push

    GitHub has expanded its push into the enterprise with the 2.18 release of GitHub Enterprise Server, which includes a bevy of updates intended to make administrators’ lives easier.

    Mario Rodriguez, head of product for GitHub Enterprise, said the enterprise edition of GitHub is seeing triple-digit growth as large companies more aggressively embrace DevOps tools and processes that already have proven themselves to be effective when building and deploying large-scale web applications.

    To make it easier for administrators of those environments accessing either an on-premises edition or software-as-a-service (SaaS) version of GitHub Enterprise Server, the latest edition enables administrators to employ an issue-transfer capability to delete an issue in one repository and move it along with its associated metadata to a new repository in a single step.

    Other additions to GitHub Enterprise Server include an assignable commenters capability that allows maintainers with write access to assign an issue or pull request to anyone who has commented on it, regardless of their organization membership or repository permissions.

    If an issue or pull request belongs to a milestone, the name of the milestone now also will display on the project card and in the project card details sidebar. An issue or pull request from milestones can be added or removed using the details sidebar, and project cards can be organized by milestones using the search bar.

    GitHub is now also providing administrators with repository templates that allow them to own or have write access to a template repository. That capability allows anyone with access to the repository to generate a new repository with the same directory structure and files. If an administrator creates a user-owned repository, they also now will be able to watch it for updates automatically. However, forks no longer will be automatically watched, even for those granted push access.

    Rodriguez said GitHub is also starting to extend the scope of its platform to address best DevSecOps processes. Expanded dependency graph support adds security alerts to projects that rely on “yarn.lock” files. Those alerts help developers stay on top of vulnerabilities that impact their dependencies, which Rodriguez said is critical because security issues these days can wipe out all the productivity gains previously made in a DevOps process.

    An expanded audit logs capability allows administrators to see changes to settings for organizations and repositories, in addition to seeing when PAT and SSH are being used to access information and when there’s been a change in organization and repository membership.

    In general, Rodriguez said GitHub Enterprise Server, which gets updated once a quarter, provides 95% of the GitHub repository capabilities accessed by more than 40 million developers to share code and download open source software. Enterprise IT organizations clearly want to replicate the GitHub developer experience behind a firewall to ensure no one is inadvertently accessing proprietary software that provides them with a competitive advantage. The challenge, of course, is not so much setting up the repository as much as it is defining all the DevOps processes that need to revolve around it.

    — Mike Vizard

  • DOES London 2019: Give Repos the Respect They Deserve

    DOES London 2019: Give Repos the Respect They Deserve

    Think about it. could we have a DevOps or even agile without code repositories (repos)? Repos allow for version control, team collaboration, testing on check in and more. So much of what we do today around software development and DevOps is based on the repo.

    For a long time and even today, the repo was sort of the Rodney Dangerfield of software tools. In spite of how important it is, it didn’t get the respect it deserved. Of course that changed a bit when Microsoft laid out all those billions of dollars for GitHub. But even then, the narrative was Microsoft paid that much to reach all those millions of developers that used GitHub. Not for all of the great features and functionality GitHub delivered to its million users.

    Also, in the case of GitHub, they had done a masterful job of weaving together a fantastic free, open source tool with enterprise features and SaaS delivery models to build a legitimate business for everyone from single developers to small groups and all the way up to large enterprises.

    Nigel Abbott, GitHub

    In this interview from the Digital Anarchist news room at DevOps Enterprise Summit London, 2019 we spoke with Nigel Abbott, director at GitHub for EMEA. After leading GitHub’s efforts for the enterprise in the UK, Nigel is now leading enterprise efforts for all of Northern Europe.

    This was a great interview with Nigel and hope you will enjoy it, too.

    Nigel Abbott, GitHub | DOES London 2019

    Don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening from October 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already and join us for a premier event for the technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    — Alan Shimel

  • GitHub Actions Advances Automation Strategy

    GitHub Actions Advances Automation Strategy

    GitHub Actions, a set of application programming interfaces (APIs) through which DevOps tools can automate workflows, is now available in beta.

    Previewed last year at the GitHub Universe event, GitHub Actions is intended to provide not only a way to automate responses to events occurring within a GitHub Repository but also share those workflows across multiple DevOps teams, said Max Schoening, senior director of product design for GitHub.

    Actions are based on YAML files, which makes it possible to write them in JavaScript or other programming languages or package them up as a set of containers. In either instance, they are designed to interact with the full GitHub API and any other public API.

    In addition, higher levels of automation enabled by GitHub Actions should make it more feasible for DevOps teams to test multiple versions of a project in parallel as workflows written in code replace manual processes, said Schoening.

    As more manual processes become automated, the number of IT teams who are intimidated by DevOps processes today should begin to decline. Organizations also should be able to apply best DevOps practices more consistently across multiple teams. Too often today the DevOps practices within the same organization tend to vary widely. Schoening also noted that given the open source history of GitHub, organizations will be able to see how workflows have been created for popular open source projects and then copy them.

    In addition, Schoening said the arm of Microsoft will continue to invest in analytics that will surface workflow recommendations that can be applied to any project regardless of the language employed or the platform on which it’s destined to be deployed.

    On one level, DevOps is all about a ruthless commitment to automation. But when automation goes wrong at scale, it can be extremely problematic. Rather than relying on “black box” approaches to automating processes, a truly open source approach to automation makes it possible for DevOps teams to see how a process is being automated and then extend it if they so choose, said Schoening. To help address the concern, GitHub Actions also provides access to live logs to provide real-time feedback as builds run, which Schoening said makes it easier for DevOps teams to debug automations created using GitHub Actions.

    It’s too early to say just how automated DevOps processes will get. There’s an emerging school of thought that contends the goal is to make it feasible for developers to spend 100% of their time writing business logic. It’s not clear whether that goal is achievable anytime soon, but progress is made with each update to continuous integration/continuous development (CD/CD) platforms. As complementary advances in machine learning algorithms and other forms of artificial intelligence (AI)—otherwise known as AIOps—occur, it’s apparent many manual DevOps processes will fall by the wayside.

    In the meantime, the workflows that make up any DevOps process should become increasingly sophisticated as advances in automation span everything from hybrid cloud computing environment to internet of things (IoT) deployments. The issue soon may not be how cumbersome any DevOps workflow is, but rather the potential limits of the imagination applied to automating them.

    — Mike Vizard

  • TypeFox Ties Cloud-Based IDE to GitHub

    TypeFox Ties Cloud-Based IDE to GitHub

    TypeFox has launched a GitPod.io service that melds the integrated development environment (IDE) based in the cloud from TypeFox with the open source GitHub repository.

    Sven Efftinge, co-founder of TypeFox, said this level of integration will make it easier for developers to navigate multiple projects from which they pull code from GitHub into an Eclipse-based IDE.

    In addition, when developers open a Gitpod.io workspace, they will find that any build involving an update to an artifact housed in GitHub will have been automatically completed, said Efftinge. That will reduce substantially the amount of time developers spend waiting for build to finish, he noted.

    TypeFox collaborated with Google, Ericsson, Arm and Red Hat to develop the open source Eclipse Theia project, which provides a foundation for building IDEs in the cloud using TypeScript, CSS and HTML for a desktop-like user experience. At the highest level, Theia consists of a front end running in a browser or in the local desktop application and a back end running on any host or locally within the desktop application. Both the front end and back end communicate through JSON RPC over WebSockets. TypeFox then leveraged that project to build its own cloud-based IDE.

    Gitpod.io further advances the collaboration capabilities that are inherent of cloud-based IDE by adding the ability to capture and share snapshots of the development environment.

    Efftinge said following initial support for GitLab, the next effort will be focused on integrating Gitpod.io with the GitLab repository, which is used widely in traditional enterprise IT organizations.

    Regardless of the repository employed, more attention needs to be paid to reducing the daily friction developers encounter when developing applications. While best DevOps practices go a long way to accelerating application development and deployment, there a lot of wasted steps during the development process that, if eliminated, would increase developer productivity substantially. Of course, the more productive developers become, the more applications there are moving through the continuous integration/continuous development (CI/CD) pipeline.

    It’s still a bit unclear to what degree application development will move to the cloud. It’s certainly easier to streamline development process in the cloud. But many developers remain attached to individual workstations because they may not always be in a location that has reliable access to the internet. However, as application development—especially in the age of microservices—becomes more of a team sport, it’s clear that more application development is being pushed into the cloud. Pushing application development into the cloud also provides the benefit of reducing the number of high-end PCs and workstations an organization may need to acquire for its developers.

    Whatever the path chosen, it’s clear repositories such as GitHub and GitLab are now at the center of application development. Very few developers these days are writing raw code. Most of them are combining artifacts stored in repository to build their applications. The challenge organizations now face is bringing some consistency to what otherwise could easily become a chaotic process.

    — Mike Vizard

  • ‘DevOoops’ Moves: SCM Conflicts

    ‘DevOoops’ Moves: SCM Conflicts

    DevOps’ ultimate aim is to create efficiencies in the software delivery process. But it doesn’t always work out that way. Sometimes DevOps initiatives lead to mistakes—something we lovingly call a “DevOoops.” CloudBees recently polled some colleagues and came up with five examples of a DevOoops in action. Following is a discussion submitted by solution architect Will Refvem about siloed departments.

    Scenario:

    One of the biggest challenges in DevOps is SCM. Early in my career, being given access to Git repositories was a bit like handing a belt-fed machine gun to a drunken toddler. My biggest DevOoops moment came when I was trying to master the basics of Git in a project that used Git submodules—don’t, just don’t—and had a series of bash scripts that implemented a primitive CI/CD workflow by running in the environments we were deploying to (seriously). I can’t tell you how many merge conflicts and detached HEADs I encountered, or how I got out of them. Fortunately, we were using the fork-PR model, so I did no real damage.

    Software configuration management (SCM) is key not only for versioning, but also for providing a shared view of code and other assets, from development through to production. Giving proper consideration to your SCM structure, branching and merging model, access controls, etc., will support collaboration, reliability and traceability—all key for DevOps success.

    In the 2019 DevOps and Jenkins Community Report, 66 percent of organizations respondents reported the use of modern solutions SCMs, specifically GIT-based solutions GitHub or BitBucket. But the older SCM solutions aren’t going away completely—45 percent of all organizations still use pre-GIT, pre-DVCS (distributed version control systems) such as Perforce, Subversion and CVS. While it’s possible to apply DevOps practices using these legacy solutions, it is important (and more challenging) to design a branching/merging model and surrounding workflow, which supports the key aspects of DevOps such as peer review, collaboration and short-lived branches.

    Modern SCMs such as GitHub have features that inherently support collaboration, including the game-changing Pull Request, making it much easier to implement processes that best support CD and DevOps.

    Poorly designed CD workflows or inadequate CD systems create friction multiple ways. If the interactions are too cumbersome, users will not commit code to the pipeline frequently enough. If it’s difficult to access the pipeline and create visibility into the process, it can lead to unresolved conflicts.

    You need to pick the right tool. If you don’t have the option to get the modern tool, you need to take the time to design a legacy tool.

    It’s also important to consider two other issues in relation to this DevOoops example: branching and acquiring the appropriate level of DevOps skills.

    • Branching: A proper branching and merging model is required to ensure you are feeding the appropriate inputs into your DevOps pipeline, such that you are able to continuously integrate, test and ultimately deploy changes. A simple guide here is encapsulated in the KISS (keep it simple, stupid) principle. If you need a full-wall whiteboard or a spreadsheet fit for an accountant to list your active branches, you need to rethink things. Get as close to the ideal of mainline trunk development as possible, with short-lived feature branches, minimal application versions, etc.
    • Skills: As organizations seek to implement DevOps, most likely new tools and practices will be implemented simultaneously. It’s important to understand and accommodate the fact that there will be bumps and bruises as you learn to use these new tools and practices. For instance, shifting from centralized version control such as Apache Subversion (SVN) to distributed version control such as Git is a paradigm shift that can be difficult to fully grasp and result in destructive mistakes, such as deletion of nodes from the change history, overwriting changes or misconfiguration access control. Consider hiring for these new skills and/or account for time and training.

    Takeaways

    • A proper branching and merging model are required to ensure that you are feeding the appropriate inputs into your DevOps pipeline to let you continuously integrate, test and ultimately deploy changes.
    • If you are using a pre-Git legacy SCM solution, develop a branching and merging strategy within the legacy solution to achieve appropriate velocity in your DevOps model.
    • Consider that you will need to develop new skills to adopt new SCM tools and practice and account for this in your plan.

    — Brian Dawson