Azure DevOps vs. GNU Make

Azure DevOps works well when you’ve got larger delivery efforts with multiple teams and a lot of moving parts, and you need one place to plan work, track it properly, and see how everything links together. It’s especially useful when delivery and development are closely tied and you want backlog items, code and releases connected rather than spread across tools. Where it’s less of a fit is for small teams or simple pieces of work, as it can feel like more setup and process than you really need, and non-technical users often struggle with the interface. It also isn’t great if you want instant, easy programme-level views or a very visual planning experience without putting time into configuration.

Incentivized

GNU Make is a great tool for simple builds where language-specific options are not available, or to provide shortcuts for common commands (e.g., "make build" as shorthand for "go build ..." with a bunch of flags). However, it is complementary to other build systems. It does not replace them, which is perhaps one of its greatest strengths as well (works with existing ecosystem instead of trying to do everything). GMU Make it simple to get started with, and the philosophy of understanding how sources map to outputs, as well as the dependency graph, are beneficial.

Incentivized

• Utilize Git as a repository to share work between multiple users
• Ability to configure Pipelines to build containers to run virtual deployments and testing scripts.
• Split individual tasks and relate to master documents for quick navigation and ability to see overall picture of project.
• Track status of each task
• Integrate with Git to utilize branches, merging, approvals, history, etc.

Incentivized

• Performance and accuracy of cross-module dependencies.
• Simple to write and easy to understand.

Incentivized

• I did mention it has good visibility in terms of linking, but sometimes items do get lost, so if there was a better way to manage that, that would be great.
• The wiki is not the prettiest thing to look at, so it could have refinements there.
• It could improve the search slightly better.

• No dependency management tools (but there are no cross-platform tools of this type anyway)
• Tedious to do cross-compilation (Debug & Release builds, 32- and 64-bit builds, x86/ARM builds)

Incentivized

I don't think our organization will stray from using VSTS/TFS as we are now looking to upgrade to the 2012 version. Since our business is software development and we want to meet the requirements of CMMI to deliver consistent and high quality software, this SDLC management tool is here to stay. In addition, our company uses a lot of Microsoft products, such as Office 365, Asp.net, etc, and since VSTS/TFS has proved itself invaluable to our own processes and is within the Microsoft family of products, we will continue to use VSTS/TFS for a long, long time.

Incentivized

It's a great help to get more information about new feature release and stay updated on what the dev team is working on. I like how easy it is to just login and read through the work items. Each work item has basic details: Title, Description, Assigned to, State, Area (what it belongs to), and iteration (when it’s worked on). See image above.They move through different states (New → Discovery → Ready for Prod → etc.).

Incentivized

When we've had issues, both Microsoft support and the user community have been very responsive. DevOps has an active developer community and frankly, you can find most of your questions already asked and answered there. Microsoft also does a better job than most software vendors I've worked with creating detailed and frequently updated documentation.

Incentivized

In general, it is fair to say the support is sufficient although we do not deal with support directly. There are a lot of forum people chiming in with suggestions or recommendations of particular usage or issues we run into. Since it is open software, patch and fixes will be available from time to time. A lot of information is available in the web now for knowing GNU Make from learning, example, teaching, etc.

Incentivized

Was not part of the process.

Incentivized

Microsoft Planner is used by project managers and IT service managers across our organization for task tracking and running their team meetings. Azure DevOps works better than Planner for software development teams but might possibly be too complex for non-software teams or more business-focused projects. We also use ServiceNow for IT service management and this tool provides better analysis and tracking of IT incidents, as Azure DevOps is more suited to development and project work for dev teams.

Incentivized

I'm a full-stack developer that has used various build tools, including Maven, Gradle, and NPM/yarn. For our C projects, I also investigated CMake and Ninja, but they seemed more difficult to learn and more tedious to work with. GNU Make is a single binary that can be easily downloaded, even for Windows under MingW32, is straightforward to learn, and works pretty well despite its age.

Incentivized

• We have saved a ton of time not calculating metrics by hand.
• We no longer spend time writing out cards during planning, it goes straight to the board.
• We no longer track separate documents to track overall department goals. We were able to create customized icons at the department level that lets us track each team's progress against our dept goals.

Incentivized

• Streamline the build based on a lot of existing component being done, reusable.
• Commonly understandable, therefore, rampup effort is small.

Incentivized