SQLServerCentral Editorial

GitHub vs. Azure DevOps

,

I work often with Azure DevOps. I have enjoyed the platform and it does what I need. I also work regularly with GitHub and GitHub Actions. Those rebuild SQL Saturday and SQL Memorial when I need to make changes. It also works very well.

This week I saw a post on choosing between Azure DevOps and GitHub, which is something I get asked at times. The post goes into some of the differences and provides a lot of links that you can use to read about features. There also are plenty of links on using the two products together, which is something I see regularly. Code in GitHub and the build/test/release in Azure DevOps.

On the question of which one, the author doesn't give a recommendation, but rather some questions on things you might think about. The author asks about the features you use or think you will need and using that information to help guide your decision. I think that's fair, but here's what I'd say.

If you have no automated version control or build/test/release tool in your organization, then choose Azure DevOps. It has a lot built in that I like and it's simple to use. I think it's visually pleasing and I think it is easier to teach people how to use it for this reason. GitHub is fine, but I find it slightly more confusing to move around in, though to be clear, I spend more time in Azure DevOps, so I'm likely biased.

I'll also separate out version control. I assume your organization has someone using version control. Whatever system they use is the one to adopt. There's no reason to argue or get them to change. Most people use Git and all Git host services are essentially the same. We could argue some small thing you want, but really Git is Git. Use what others use.

I would say the same thing for build, test, and release. Use what software developers use. These systems are all good, and they all have pros and cons. They all do some things well and have some disadvantages, but they are really interchangeable. I wouldn't move build systems or release systems without a really good set of reasons to do so. Just because the new lead or CTO likes another system or has experience there isn't a good reason. If you don't have any system in your organization, then see my recommendation above.

Modern software development needs a team, and for teams to work well and efficiently, you need version control and an automated build/release system. Use what others use, or have some people conduct a few pilots and then take vote and go with the results. Really, all these systems are similar enough that it's not worth more than a few minutes of discussion.

Rate

Share

Share

Rate