Podcast Episode 13 – GitHub Ecosystem Developments

Podcast Ep 13 - GitHub Ecosystem Developments

Ira Bell: Today we meet with Colin Dembovsky, a Cloud Solution Architect at 10th Magnitude. In this discussion, we talk about GitHub and some of the recent growth areas within their ecosystem that might be meaningful for you to take a strong look at.

Ira Bell: Hey Colin, really great to be chatting with you again, particularly on such an interesting topic.

Colin Dembovsky: Hey Ira. It’s good to be back on the podcast and happy new year and yeah, this year is going to be a great year for GitHub and for organizations that are considering moving over to GitHub. So, I’m excited about this discussion.

Colin Dembovsky: So, before I jump in with some of my thoughts, I wanted to hear a little bit about what you know about GitHub.

Ira Bell: Well, first and foremost, happy new year to you as well Colin. And I totally agree with you that 2020 looks like it’s going to be a pretty promising year for GitHub and all that’s to come. So great question. I’ve done a bit of reading to prepare for this podcast and this is what I’ve learned so far. So, kind of taking it back a bit from a history perspective, we kind of got to go way back but not so far back that we’re talking about punch cards and programming because that’s a bit too old to talk about today.

Ira Bell: Let’s think though about kind of back in the times when people had a, a single computer in which they would sort of take turns on to write some codes. So, somebody might be kind of banging away typing in code, you know, stand up, walk away, and their buddy might sit down and kind of continue with that thought process. Potentially even kind of looking back and asking their friend or colleague, Hey, you know, how does this look? Is this the right approach? It’s a very small minded, but with the technology at the time that is probably what made sense. And then this evolution happened toward client host, which you kind of had this model in which people could put changes or you know, so on and so forth or grab it at least said source code that they were working on from a developer perspective from a central server and sort of do their work.

Ira Bell: And so anyway, as I was reading more about this, just over time there was kind of this centralized and decentralized model and trying to figure out which is better and along that journey with the combination of open source and so on and so forth. I read about how Linus Torvalds, the gentleman who founded Linux obviously, founded Git, I believe that was in 2005 and so what was interesting about that is it sort of, it sort of gave the ability for people to easily sort of contribute and such to open source and, and then many of the major companies ended up, I think, actually going with Git as their source repository and sort of methodology for source code. And then I also read that sort of how GitHub was formed was because I think someone just had this aha moment where they said, Hey, why don’t we kind of like bring the social hub into, you know, this, this code idea such that there’s a central place for people who are contributing to sort of communicate on these, you know, projects that they’re working on, the wikis are, are right there and everything else, which, which is kind of interesting.

Ira Bell: So, it took this like text-based code thing, push poll and commit and all those things like that and Git to still having that functionality. But it added a mechanism for people to kind of have centralized chat and all those things, which is kind of interesting. So, what I also read about GitHub from the business perspective that I thought was really interesting is that they obtained a big, big funding round from Anderson Horowitz for, I think they got $100 million at a $750 million valuation. And they had about a hundred people working at GitHub , which is just, it’s incredible. And I don’t think they were really doing too much in the way of revenue at that point. They would later on to go get another round of funding from, or at least led by Sequoia for $250 million at a $2 billion valuation. So you can see this just immense scale happening.

Ira Bell: And then of course, you know the most amazing day for Microsoft and for the founders of GitHub was it Microsoft acquired them for $7.5 billion. So why did they do that? Well I, you know, this is part of where I’d like to get your feedback Colin, but you know, my interpretation is look, this is where all the developers hang out at. Not all of them, but the lion’s share of them. It’s a really big ecosystem. One might think that of course, you know, Microsoft could have perhaps recreated or written something similar to this and in some ways there is functionality within, you know, a lot of the Microsoft tooling that might represent something similar but, but really they’re probably buying in addition to the, you know, functionality and all that. A complete ecosystem. And so, that that’s quite interesting and I’ll just kind of close with one last thing that I read about it as I was geeking out within GitHub was, if you go to the website right now, it says that as of August, 2019 GitHub actually serves 2.1 million businesses and organizations. I find that absolutely incredible. Yeah, so, I guess here’s the question I would pose to you Colin, from a developer’s perspective, what do you think all the fuss about GitHub is actually all about?

Colin Dembovsky: Yup. That’s a great overview of that history, Ira. When I look back on my history, I come from an AppDev background. When I started working with a professional software development, we used an old program called CVS. I was doing Linux development and C++ and core ran. We were using CVS. I joined a company, it was my second job ever. They were at Microsoft shop and they were using zip files for source control, which even though I didn’t know much about source control, I figured that was not a good idea. And so I got that team onto Team Foundation Server, which had a source control system called Team Foundation Version Control (TFVC), which still exists today. And the TFVC is very similar to something like subversion, which is this idea of a centralized source control server where I would check out some files and I’d be working on those files.

Colin Dembovsky: And when I’m finished with those files, I check them in and then other developers can check those files out. And they have mechanisms of dealing with conflicts and so on. But you know, you alluded to where, where the industry was, drove how the source control systems worked, and back in those days, you know, having three or four releases a year was pretty standard for a lot of organizations. And so, you could have these very long lived branches, right? So it was very typical to have dev, UAT and prod branches, right? So you would do all your dev on the dev branch, then you would promote to UAT where you do your testing, and then you’d promote to prod when you release to production. And if you’ve got three or four releases a year, that’s somewhat manageable and there’s a lot of teams that still operate with TFVC very successfully.

Colin Dembovsky: But with the rise of DevOps and CICD or continuous integration, continuous deployment, teams are getting into this mode where they were releasing weekly, even daily, some teams even hourly. And when you’ve got these long live branches and you’re trying to release hourly or daily, it becomes very challenging to manage what code is ready for deployment, what’s not ready for deployment. And this is, I think what gave rise to the need for Git, where Git is a decentralized source control system. So when you clone a repository, you get the entire history of that repository and you can create branches locally and you can do all the source control operations that you want to branch, merge, rebase, all of these operations you can do locally. But to share those changes you would need to push and pull somewhere where the repository that you have can be synchronized with someone else’s repository.

Colin Dembovsky: And that’s really where we’re GitHub came into play, was a place where people could collaborate, and synchronize their repositories. So, there was this trend in the industry with the CICD and continuous deployment giving rise to this need for something that can better handle branching. And so the fundamental way that get handles branching is very different to how TFVC or subversion handles branching. The branches are just pointers are very lightweight. So it encourages a lot of branching, a lot of experimentation. And that lends itself to the CICD rapid deployment mechanism that was starting to become more and more prevalent in the industry. And then with GitHub that gave rise to a very popular way of developing, which was this open source development, right? Where I put my source code up where the whole world can see it and anyone in the world can actually contribute and push their changes to this repository.

Colin Dembovsky: And so, I don’t just have the three or four people on my team working on it, but potentially all of anyone in the world can work on, on my source code base. And this was again in that time in the industry circa 2007, 2008, 2010, somewhere around that, that sort of late part of the first decade of the 2000, open source it wasn’t something that a lot of enterprises engaged in. And one interesting story around this is when you consider Wikipedia versus Encarta. So, Encarta was the encyclopedia that Microsoft’s released, I remember actually owning Microsoft Encarta 2003 or something like that. It was, it was way back in the day. And that was how you got your encyclopedia right. And then Microsoft had a big team that worked on this encyclopedia and that released this encyclopedia on a bunch of CDs or DVDs and they were funded and they were competing against this open source platform called Wikipedia where people contributed to Wikipedia in their spare time without any salary or money or any recompense.

Colin Dembovsky: You know, if you had to look at those from a business perspective, you would have said that Encarta would have kicked Wikipedia out of the industry. But what actually happened was over time Wikipedia became more and more popular and more and more prevalent and eventually Encarta closed down because it just couldn’t compete with Wikipedia. And so, we’ve seen this happen from time to time where people who are contributing out of their passion and not even being paid for it necessarily are creating these programs and platforms that are taking the world by storm. Like Kubernetes is another example. Kubernetes is really hot at the moment and that’s an open source project, right? The code is on GitHub and you can contribute to it and you can download it and you can add your own changes to it. But it’s become all the rage and even in a lot of enterprises.

Colin Dembovsky: So, we’re seeing this open source take the world by storm. In fact, there was an open source security and risk analysis report. And in that 2019 report, they showed that 99% of large enterprise applications are leveraging open source software. So even if your company or the development you’re doing is not specifically open source, there’s a 99% chance that you have some open source in the applications that you’re writing. And deploying. That same report also showed that 90% of new code bases have some open source in them. So, even new development, 90% of new development is starting with some open source libraries right from the get-go. So, the open sources has kind of won, right? And we’re seeing that it’s almost impossible to do any sort of development now a-day without using open source code. And this is where it get hope is becoming more and more important because as enterprises start embracing this methodology of open source, even if they’re not open sourcing their software, they’re still developing in an open source style. That’s where GitHub is becoming more and more relevant in today’s industry.

Ira Bell: Well that’s great Colin. I couldn’t agree with you more. And by the way, you took me way back when you were talking about Encarta and that’s a great example. I still remember getting my first PC and having the actual CD that I would put in just to try to go find any type of video I could, whether it be like lion running through the jungle or whatever it might be. You know, as a child it was just content that I couldn’t otherwise get. So, that’s a great analogy though when you kind of think about that in terms of how it actually compared to a Wikipedia and sort of doing what, what I’d call brain sourcing if you will. So that’s really incredible. And then, you know, in terms of the open source stuff, I think what’s interesting is in a lot of meetings I’ve had with executives when we, when we talk to them about GitHub and they say, well that’s open source and you know, I don’t want all of our stuff to be able to be contributed and can they see our code and so on and so forth.

Ira Bell: And what I found interesting when I was learning about GitHub was that it was exactly as you identified it. And also the companies are encouraged to have private repos as well. So you know, just like you said, if you’re going to start a new development project or perhaps modernize an existing app, you’re not going to go out and reinvent the wheel and spend the, you know, first in number of months writing a solution that that’s already been adopted and is used by many for kind of the standard for things, you know, whether it’s bootstrap stuff or whatever. And so the idea being that you can, you know, have your private repo for that of which, which is kind of your, your protected IP, but also just have a, a place where you can get the latest and greatest with respect to those open source pieces is really important.

Ira Bell: And so that, that was a critical part that I didn’t, I didn’t quite understand it when someone explained it to me. It all made sense, because then I understood that companies could actually be protected but also take advantage of this amazing sort of brain shark community and contribute so that they can kind of give back, which I think is really neat. So I guess, I mean that kinda goes to the topic of like if GitHub isn’t just for sort of open source developers and hobbyists, maybe Colin, you could kind of talk a little bit about what it does look like in the enterprise and you know, of course ironically GitHub has now released their GitHub enterprise offering and is working toward this Microsoft integration and coupling.

Colin Dembovsky: Yup. That’s, that’s a really great question. I already, you know, my start to get herb was really for, for open sourcing some of the projects that I was working on part time or working on out of work. Again, just it started for me as, as a hobbyist place where I could put some of my hobby code. I think a lot of, a lot of developers now that are working for enterprises have some form of hobby code or, or some form of code that’s not part of their business, part of their day to day that they’re using on GitHub. And so, GitHub has just over 40 million users and just over a hundred million repos. About a third of that, nearly 30 million of those repos are public. And so, there’s just this massive collection of just great programming and code and people’s time and pension that that is available there.

Colin Dembovsky: And as you said, there’s going to be this mix I think for enterprises for utilizing the plumbing, if you can call it that, the sort of low-level things like cues and transport protocols and those things. You don’t want to write your own things. So, it’s not what your business needs you to do. You know, your business needs you to build on the shoulders of giants and build what is unique to your business on top of all of their plumbing. Right? And so that’s where you get the power of really leveraging 40 million developers and building on top of what those 40 million developers have already built. And that’s what makes GitHub so compelling in this modern, modern world of software delivery. Where we are, we, we’re trying to figure out how can I build on the, on the shoulders of giants in a way that’s secure and that there’s actually workable.

Colin Dembovsky: And so, the point is that most developers now have some kind of interaction with GitHub and so they’re used to working with GitHub. So, if you can bring that workflow into the enterprise, it’s going to add to the developer satisfaction because they’re, they’re used to working in that. And most people that work with GitHub just love the way that the interaction works. And GitHub talks about this thing called inner sourcing, which is really this collaboration and this community around the code. So, it’s not just about the code, but it’s around this community, around the code. And bringing that into the enterprise is good for developers and it’s, it’s just good for innovation in the enterprise. The other thing, as you rightly mentioned, Microsoft paid $7.5 billion for GitHub. So, Microsoft themselves recognize that there’s something about GitHub, which is special.

Colin Dembovsky: And really, I think if you’ve listened to Satya Nadella over the last few years, almost every time he does some kind of keynote that’s involved with developers, he talks about winning the heart of the developer, right? And I think he’s doubled down on the fact that if he can win the heart of the developer, then that’s going to ultimately lead to revenue for Microsoft, right? Because if the platform that I’m delivering my software on is giving me joy and I’m actually enjoying the work that I’m doing, I’m more likely to use more products from that company that’s giving me that platform. So, the acquisition of GitHub I think was very shrewd but it also was very insightful. I think that ultimately Microsoft wants to drive to Azure and you’ll see, GitHub talk about code to cloud. And that’s a very big theme that’s coming from GitHub now under Microsoft is code to cloud.

Colin Dembovsky: How can we quickly get our code from GitHub and from these repos into production in the cloud? And of course, they’re, while GitHub itself is, is cloud neutral. There’s some vested interest to get into Azure from the Microsoft folks.

Ira Bell: Sure. Well that makes a ton of sense. And I was going to ask you, you did touch on it though, but is it sort of just as easy to push items into, for the second example, Azure as it is AWS or GCE or do you think it’s easier because Microsoft wholly owns GitHub now to sort of deploy things into Azure?

Colin Dembovsky: Yeah, this has been something really interesting to watch. Microsoft wants to remain vendor neutral on GitHub of course, because they have a very large customer base. There are a lot of people are using the platform and a lot of the users on that platform are not targeting Azure as a, as a cloud service.

Colin Dembovsky: Right. So, they have to remain a little bit neutral there. But again, there, there is some vested interest in them getting developers to deploy into Azure. So, I think it’s probably fair to say that it’s almost as easy to get onto any of the platforms. There’s not that much difference to it, but I think, um, I think there’s a little bit more investment from Microsoft specifically onto the Azure platform, right? So, I think those integrations from GitHub onto Azure as a cloud target, they tend to evolve a little bit more rapidly, right? That brings up something which has been a bit of a hot topic in GitHub recently, which is actions, right? So there’s this mechanism where you can create workflows, you can automate workflows using GitHub actions, and those actions will run either on GetHub’s compute, which I think in the back end runs on Azure or somewhere, if I’m not mistaken.

Colin Dembovsky: And you can automate these workflows. And one scenario is continuous integration. So if you’ve got some source code and you want to build and test that source code, maybe whenever someone does a pull request, you want to run it through your, your compilation makes sure that at least compiles, and then maybe a battery of unit tests to make sure that the code hasn’t broken anything. You can automate that kind of workflow using actions. So the idea of automating this, automating some of these workflows that are, that are very common day to day GitHub actions really allows organizations and allows the source code developers to automate and to codify some of these workflows, right? So it’s not just CI but it’s also CD. So deploying, and that’s that code to cloud where you can actually get your repo to automatically deploy it to a UAT environment.

Colin Dembovsky: So, every time someone pushes code to that repository, it’s running this workflow to go and deploy the code. So then you can test it that you always have your latest code in a test environment. So, these kinds of workflows are being built in using actions and actions goes further than just the CICD. You may want to automate things like closing stale issues or, or tagging issues based on certain keywords. And the, the, the scenarios are really endless and this is where GitHub actions becomes very powerful, is that you can automate many, many aspects of the workflow that are typically done manually. And if things are manual, you know, from the DevOps world, we try to automate as much as we can because we don’t want things to be tribal knowledge. We want to be codified, we want things to be in source control so that anyone from the team is capable of having these workflows run or, or managing the workflows. We make sure that they’re part of the process day to day. And that leads just to better quality software for everyone.

Ira Bell: Well, thanks for that overview Colin. I mean the entire GitHub actions arena sounds pretty sweet. I certainly learned a lot today already. Why don’t we pivot for a moment and talk about what is always a hot or dreaded topic but necessary, security, right? So, we at 10th Magnitude take on a lot of projects where we help companies establish a secure landing zone and essentially a home in, in Azure in order to begin deploying, you know, workloads and apps and things like that and their data. And while we take all those steps we often encounter and have to justify what, you know, what we’re doing with a, what I’ll say, “security people”, you know, whether it’s the CSO office or whatever. And then, you know, unfortunately sometimes what happens is, you know, deployments will get blocked at the last second by these “security people” within a company and so that can slow down release cycles and things like that. So, I guess my question with respect to GitHub, is GitHub doing anything to, to kind of change this dilemma that occurs?

Colin Dembovsky: Yup. Great question. Security is something that’s very high on the list of priorities for GitHub. And in fact, my reading of it is that GitHub is trying to differentiate itself specifically in the area of security. So, most organizations have some form of siloed security that you mentioned. You know, it’s, it’s often too little, too late. So the, the security pros are this kind of strange group of people that live off to the side and, and they, from a developer perspective, it feels like their entire job is to block your deployments, right? And that doesn’t lead to a healthy development and collaboration. And we can see the impact of some of security breaches recently, like Equifax, right? Equifax was, was a huge breach that could have been mitigated or could have been prevented if there was a, a shift left of the security.

Colin Dembovsky: Right? So what do we mean by shift left? Well, I’ll look at testing. Testing is something that more and more is shifting left today where teams are not, not leaving testing up until the last minute for a QA team, but there they’re integrating testing into the development cycle early on. So they’re shifting at lift and into making unit tests and integration tests part of delivering code, right? And so, teams are starting to do the same thing and we’re seeing this trend in the industry to do the same thing with security. So, instead of leaving it till the end of the cycle and getting blocked from deployment the last second, or having to go with a deployment that we know is vulnerable because we don’t have time to fix it. Instead of doing that, we want to secure the software supply chain. So, we want security testing to be done at every stage of the development cycle.

Colin Dembovsky: We want security pros to be able to share their expertise and awareness across all the teams. And we want to try and again automate some of that knowledge, right? So last year get herb acquired a company called Semmle and Semmle had a very interesting product where they were able to scan your code base and create a graph out of your code base. And then, because they got it into the graph structure, they were able to then write these queries that would allow them to flag certain vulnerabilities, right? And this draft language that they have is for more than just security. So can actually look at semantic and syntactic vulnerabilities or patterns. So, when you run it against your, your repo, it can tell you if you’ve got unused variables and these sorts of things, some, some coding standards and practices that can also pick up.

Colin Dembovsky: But really what the key value prop of Semmle is this graph query for security vulnerabilities. So what that gives teams the abilities to do is for the security professionals, and we’re talking about these data scientists who are specifically insecurity. So, we’re talking about really deep expertise. These are the guys that are finding CVEs and discovering these vulnerabilities that we then have to act on to, to go and close. So, we’re talking about really deep security professionals. They’re able to write these queries against this graph language of Semmle. And so, they can automate these queries that can find vulnerabilities. And then when you’re, whenever you’re pushing code to your repo, Semmle can scan that repo and flag any vulnerabilities, right? So that, that allows the developers and the security pros to collaborate much more effectively with one another. It’s built into the everyday workflow. And this is going to mean that there’s more code security for everyone.

Colin Dembovsky: And not only can the security pros write their queries, but a lot of those queries are, are then uploaded to GitHub so that GitHub runs them automatically. And I’ve had this on a couple of my repos recently, where I’ve received a notification as I’ve pushed code to my GitHub repo to say that some vulnerability has been discovered. And so Semmle is automatically working against open source repos, at least at a basic level, there are, there are paid subscriptions for more advanced capabilities, but not only does does GitHub and Semmle that integration find vulnerabilities, but it actually creates a pull request to mitigate that vulnerability, right. So, it’ll flag to say that there’s this vulnerability, maybe there’s a library that you’re using that that has a vulnerability, and then it’ll create a pull request that actually updates the library to the most recent version or to the version where the vulnerability was fixed so that you don’t even go and find that yourself, right?

Colin Dembovsky: One of the demos I saw at GitHub universe, which is a GitHub conference in San Francisco last year in December, I saw Ed Thompson who, who came from the Microsoft engineering team from the Azure DevOps team, now works at GitHub  and he showed a demo where he created a GitHub action that said if Dependabot, which is the user that creates these vulnerability PR fixes. If Dependabot on what creates a PR, then I want you to run it through my CII to compile and taste my application. And if everything succeeds, I want you to automatically go and merge that pull request in. So, there’s this great combination of using the security scanning and the advanced security features of GitHub with actions to actually automatically integrate the fixes for vulnerabilities using those advanced securities and actions. So, this is becoming more and more compelling for enterprises because again, they don’t have to build their own security automation framework. They can just tap into what GitHub is already created.

Ira Bell: That’s really neat. I mean and I think, it’s really interesting to think about all the automated security stuff that that is coming out now. I think that was a really brilliant acquisition by GitHub. And just kind of talking through this, I bet there’s just tons of these InfoSec folks who really don’t know the capabilities and so I’m just thinking bringing them into the conversation earlier is probably wise so they can understand what the kind of core features are and then also have an ability to contribute to some of those processes like within actions or whatever so that they can feel comfortable that each piece of or set of code or whatever is actually going through the scrutiny of the process that the organization is, has agreed upon. So that’s a, that’s a really great outline. Well I’m feeling a lot more confident in my understanding of GitHub. Hopefully our listeners are as well. I’ve got one last question for you Colin. Cause this, this does come up a lot when I get a chance to meet with, you know CTOs and CIOs and so on and so forth. If a customer is already using Bitbucket or, or they’ve, you know, recently adopted Azure DevOps, which we use internally, what should those teams do that are already on those platforms or otherwise?

Colin Dembovsky: Yep. Another great question, Ira. So, I think with a, with Bitbucket or Mercurial, if, if there’s any team still using Mercurial, I think Microsoft and GitHub of course they, they want everyone to, to migrate their source code over to GitHub. So I think, with the additional capabilities that they’re building in with the inner sourcing, with security, it becomes more and more compelling to move your, Git repos to GitHub get repurposed because you have the entire history of the repo. Whenever you clone it are easy to migrate. Unlike subversion or TFVC, which can be very challenging to migrate because they’re centralized but Git repos, generally migrate very easily. So, it’s really not that hard to migrate a repository. And as I said, when you do that, that migration over you’re, you’re going to be tapping into some of these advanced security features and the whole inner sourcing structure and open source delivery style that get up offers.

Colin Dembovsky: The line becomes a little bit more blurred with Azure DevOps. So Azure, Azure DevOps. It was interesting seeing how Microsoft approached the GitHub acquisition because they had essentially a competing tool in Azure DevOps, right? So, if you look at Azure DevOps, you can put get repositories into Azure, DevOps and it has a as Azure pipelines, which is a full CI CD system. Very, there’s one of my favorite features of Azure DevOps is, is the automation that you get with Azure pipelines. There’s also test management for managing manual testing. There’s boards for it for doing work on tracking. So, in a lot of senses there is a compete between Azure DevOps and GitHub . So it was interesting watching Microsoft and how Microsoft first approached that dichotomy between these two competing products that they owned right now, because I’m an Azure MVP or an ALM MVP, I’ve been working with the Azure DevOps team for many years since about 2011 so I know a lot of the folks on that team in Microsoft and it was kind of interesting watching, watching them figure out what the message should be.

Colin Dembovsky: I mean, they spent $7.5 billion on GitHub so there was going to be some kind of shift. Right. So we were just kind of watching what the shift would be. A lot of those engineers have actually moved from Azure DevOps and are now working on GitHub. Right. So a lot of the engineering resources are moving over there so that that tells some sort of story in some sort of, gives us some indication of where the focus is from Microsoft. That. I know that was a little bit, a little bit roundabout, but I think where it ends up being with Azure DevOps is I think for now Azure DevOps is, is really where you should be doing portfolio management for your work item tracking. So using Azure Boards to do your product planning and product tracking GitHub does have issues and there are some boards as well that you can use, but it’s a little bit difficult to do portfolio planning and the kind of planning that a lot of enterprises will want to do cross team planning.

Colin Dembovsky: So, if you’re just one team, you could use issues and some of the boards to track your work and plan your work. But as soon as you start getting multiple teams and you start managing a portfolio of teams and you’re doing kind of scrum of scrums or safe or anything where there’s multiple teams, it becomes very challenging to manage in using GitHub issues. So, you probably want to stick with boards for it, for doing your product planning and portfolio management. Then put your source code into GitHub. The integration between GitHub and Azure DevOps from the source code perspective is fairly deep. So, you can go and create pipelines, Azure pipelines against code that’s inside of GitHub repos very easily. So, that integration is great. There’s even some integration between boards and issues. So, you could actually use both boards and issues.

Colin Dembovsky: You can still use the test management capabilities and Azure DevOps, cause again GitHub doesn’t really have anything for managing manual testing. So, if you’re still doing any kind of manual testing, you can still manage that in Azure DevOps. Package management, there’s great package management in both products. So if you’re already using Azure packages, you could leave them there. Otherwise you could start releasing your packages using GitHub packages. So again, there’s, there’s some options there. And so, I think what our recommendation would be, and this is kind of a generalization that it’s going to differ from team to team depending on where that team is and what challenges the team is facing is to use GitHub for source control. Because you get all the great scanning and security capabilities. Maybe use actions for doing your builds. The CD capabilities, continuous deployment capabilities are still evolving with actions.

Colin Dembovsky: So there’s, there’s some features I’d like to see in actions before I recommend it as a deployment tool. Things like environments and multi environment values for your variables and so on. So, approvals, these sorts of things are exist in Azure pipelines but are still in development in, in GitHub actions. So, I think the best of both is to really use GitHub for your source control and for the security scanning and for CI to use actions for CI and then to use Azure pipelines for your deployment, use Azure boards for your portfolio management, and then really either packages, Azure packages or GitHub packages for package management. So, I think at this point in time, our recommendation really is to kind of use the best of both as things evolve in GitHub. So, it’ll be interesting to see how GitHub evolves in the product planning space and in the CD space. So, that recommendation may change over time, but I think that’s where we as 10th Magnitude, I think that’s our recommendation currently is to use the best of both, have your source code and GitHub and your, your a CI and GitHub, have CD and in Azure pipelines. And that would probably be our recommendation.

Ira Bell: Colin, that makes a ton of sense. I think I understand a lot more now about the integration between GitHub and Azure DevOps. And I gotta tell you, I had a bit of a chuckle when you said GitHub as issues and then paused clearly, you were talking about the feature called issues in which inside GitHub you can use that to keep track of bugs and enhancements and those sorts of things. And for our listeners who aren’t familiar with Azure DevOps boards, that’s really, really neat tool. Kind of think of it as Post-It notes in which you can move from one to another to kind of track your progress and maybe some of your agile projects or whatever for development or otherwise and manage that portfolio.

Ira Bell: So, with that, I think we can conclude for today. I just wanted to thank you calling every time you come on the show, I always learn something. And so for that I’m thankful and it’s a pleasure to work with you as always. So, thank you, sir.

Colin Dembovsky: Thanks, Ira. It’s been a pleasure.

Ira Bell: Thanks for listening to The Art of Digital Disruption. At 10th Magnitude, we’re proud to create the path for organizations to stay competitive and disrupt their industries.

Ira Bell: Learn more about establishing GitHub fundamentals for modern source control management and enterprise-grade InnerSourcing by checking out 10th Magnitude’s GitHub Adoption Quickstart. Visit www.10thmagnitude.com/GitHub-adoption-quickstart.

By |2020-01-16T00:55:22+00:00January 16th, 2020|

Leave A Comment