Better Together

My second week at Microsoft is on the books now and it is evident that I will be extremely busy in my new role. I don't necessarily intend for this blog to be a weekly journal about my Microsoft employment. However, this is what I have at the forefront of my thoughts these days. I plan for this blog to be about my journey for knowledge, wherever that knowledge comes from or whatever it is about. I imagine the majority of my posts will be about software engineering, but I also like to garden, and operate my HAM radios. Some weeks I may post about my experiences with my two young sons, as becoming a father has taught me a lot.

I've been deliberate in meeting my new teammates this week. I've worked fully remote now since the beginning of the pandemic in March of 2020. I've been able to make it work, but the largest challenge to compensate for is the culture and friendship that comes with working in close proximity to others. This is something that we are all used to happening naturally, but now it is something we must be intentional about. While being respectful of my new friend's time, I try to find 15 minutes where they are free for a call. This call is for time just to get to know each other. We talk about things like where they call home, what their background is, and what they love most about their job. These calls always end up taking over an hour and only end when one of us has another meeting coming up. Throughout these calls I've discovered that the majority of my team members have been with Microsoft for over 20 years. This is a bit intimidating, but not in a threatening way. I hope to leverage the experience and knowledge of my new team as I grow. I am excited to be collaborating with them.

While the leader of my team has made it very clear that Azure Kubernetes Service is the number one priority I should focus on, it seems like there is much more need for Azure DevOps skills as that is what all of my (very few) engagements have been so far. A couple of the customers who I have been helping are in the processes of migrating Azure DevOps organizations, projects, and repositories. Some are migrating from one organization to another, and some are migrating from an on premise solution to the cloud. The "One Project To Rule Them All" series has been very helpful to me through these engagements. However, in June of 2018 Microsoft acquired GitHub a very similar product to Azure DevOps. One of the priorities for other members of my team is onboarding customers to GitHub enterprise. This could conflict with what I am doing with Azure DevOps, and so I couldn't help but ask the question, "What is the future of Azure DevOps?". The official answer is that Azure DevOps isn't going anywhere, and that we are taking a "Better Together" approach when talking about it with customers. This is the idea that GitHub and Azure DevOps play to the others strengths and weaknesses. So what are those strengths and weaknesses?

GitHub Strengths

The best strength that GitHub has to offer is in the area of security. The ability to scan your code for dependency vulnerabilities and automatically create a pull request to fix your issue is huge! GitHub also alerts you when a secret is accidentally committed to your repository. This is great because secrets can easily become an after-thought to a developer when they are in the zone and developing the integration that uses the secret. A developer might have that secret in a local configuration file temporarily while they do some testing, and then forget about it when they commit and push their code. Now all of a sudden this important and sensitive information, such as an API Key is forever a part of your git history. However, GitHub can alert you about it and give you the opportunity to be proactive and disable that secret, or swap it out with the provider, preventing it from being abused before you notice. Of course both GitHub and Azure DevOps have add-ons in the marketplace that can achieve the same results, but GitHub has this capability natively without any extra steps to really set it up.

GitHub has more strengths than just security though. Collaborative Coding is a huge area where GitHub is really mature. Of course, Azure DevOps allows very similar functionality, but GitHub has very intuitive and easy to use controls for managing a collaborative environment amongst developers. GitHub’s approach to Pull Requests has become the gold standard amongst collaborative coding environments, with the multiline comments, and multiple reviewers contributing to feedback. Again, Azure DevOps also have these same features, but the individual contributor experience on GitHub is unmatched. Part of that ties into the next strength I will list for GitHub and that is the community.

GitHub's heritage is centered around community and bringing developers from all walks of life together to build great software together. This mostly comes from the Open Source Community, but if you've downloaded and used any open source software in the last 15 years, there is a very good chance GitHub was involved. Again, this isn't exclusive to GitHub. Azure DevOps also has the ability to make your projects public, however very limited functionality exists to catalog and search for projects and organizations on Azure DevOps. GitHub is built around the ability to search for projects and review the network of forks around them.

Azure DevOps Strengths

While there is still a lot GitHub has to offer, some areas Azure DevOps excel in. One such area is the project management capabilities with Azure Boards. While GitHub has come a long way in recent years with GitHub Projects, Azure DevOps has always been centered around this idea of work items. Even in its past life as Visual Studio Team Services (VSTS), its core aspect was about organizing the work to be done. While GitHub does have Issues and Pull Requests that help track in-flight contributions, they are limited in functionality that would make most project managers more comfortable. However, while this might be the state of things right now, GitHub does have some pretty exciting stuff coming for us very soon.

Azure DevOps is much more mature in its execution on Continuous Integration and Continuous Delivery. There have been 3rd party tools to achieve this for some time now, such as Jenkins, TeamCity, or TravisCI. However, Azure DevOps first brought it into its core feature set in 2016, while GitHub announced GitHub Actions in 2018. I do think that GitHub Actions will eventually become a superior product, currently I believe Azure DevOps has a better solution for teams who do CI/CD at the time being.

The final comparison area is Planned and Exploratory Manual Testing. Azure DevOps offers Azure Test Plans. Azure Test Plans allow you to do end-to-end traceability, it allows you to test across web and desktop applications, and to capture rich scenario data as you execute the test and make discoveries. GitHub does not currently have anything to offer in this area. There are automated tests using GitHub Actions, and there are third party tools to use. However GitHub does not offer manual testing tools as part of its features.

Despite the strengths and weaknesses between GitHub and Azure DevOps, the best part is that you do not have to choose! This brings me back to the "Better Together" story. Azure DevOps integrates nicely with GitHub and so teams can leverage the best of both worlds. GitHub has traditionally always been most focused on the development and execution of the software development journey, where Azure DevOps has devoted more attention to the full Software Development Lifecycle. While GitHub is currently building its strengths in more areas of the SDLC Azure DevOps still has value to offer in others. Teams can easily use both tools for the tasks which best suit their needs, and for payment it all roles under the visual studio licensing structure.

I'm no expert at this yet for sure, not by a long shot. But with the help of my new team mates, I hope to grow as an engineer. Perhaps this "Better Together" story can apply to Microsoft and Myself also. If you have any feedback about my ramblings or feel like I've got something wrong here, please reach out to me on my socials, or by email at me@timothysturm.com. You can even send me a radiogram addressed to N5OXY. I'm still learning and enjoy the process, so any and all feedback is welcome.