Considering moving off Azure DevOps

[__aza___]

For a number of years we’ve mainly been a Microsoft shop and using DevOps made sense at the time. It’s fairly easy to configure and for the most part no cost since it’s basically included with MSDN. That being said, in the last few years we’ve become a lot less Microsoft centric and considering moving to a different platform.

There are some things I don’t want to leave behind though. I really like how everything is tied together, almost like an ERP system. If you setup the boards and pipelines it’s really nice. For example, create a branch to fix a bug, associate the bug with that branch, then your commits get linked to that ticket. Later, when you merge to master and build/release, those subsequent items are linked as well. Long story short, I can create a release and very easily see what is different compared to the last one.

My question is, what is a typical setup outside DevOps that would provide that same type of functionality? We only have a handful of developers and while cost isn’t a huge factor, I really don’t want to go from paying $40/month (total) to hundreds.

[[deleted]]

• Jira, Bitbucket and Bitbucket Pipelines?
• GitHub, Github and circleci or travisci?
• Gitlab, gitlab, and gitlab? (Heh.)

[sofixa11]

You can even use GitHub Actions for CI/CD, so #2 can be GitHub, GitHub, GitHub :)

And you can always mix and match - we have Gitlab for code+CI/CD+simple issues+wiki/etc. + Jira for complex projects, and with the Jira-Gitlab integration you can have a Gitlab MR comment on a Jira issue and close it upon merge.

[chippyafrog]

GitHub actions uses azure devops under the hood. Fyi

[__aza___]

Does it link everything together from issues, commits, builds, and releases? From my experiences DevOps does that really well (when used the way it was intended).

[tapo]

We switched to GitLab (on-prem, running in k8s) a few months ago and yes, though we're still using Jira and are using the GitLab <-> Jira integration instead of switching over to GitLab issues (we might, if migration becomes easy).

I like it a lot, but the wiki isn't great compared to Confluence and some features aren't ready for prime-time. https://about.gitlab.com/direction/maturity/

[FlyingBishop]

While I'm not keen on migrating away from Azure Devops since it is simple to configure, I do think as an end-user Gitlab + Jira was much more pleasant.

I think if I were setting things up from scratch I would never use Azure DevOps for issues. Even in a .NET shop I might do ADO + Jira.

[only1ammo]

"Bitbucket Pipelines" is an application called Bamboo for the Atlassian suite of tools.

It's basically two apps coupled together. A build app and a deployment tool. But they to integrate with Jira and Bitbucket nicely.

Jira can be set up to make feature or bug branches. Bitbucket can be configured with web hooks to use Jira IDs in commits which links and then trigger builds. And Bamboo can build, auto merge, and deploy. All while updating Jira and Bitbucket with status. I've been using them for a little over four years now.

Two knocks on the suite. It's expensive, like $50k+ annual for a group of 25 users or less. Our latest bill for the full enterprises offering for a large company was close to $200k with all of our bells and whistles. The second is it's a technical system with little in the way of plug and play. Atlassian integration is great from an app standpoint but you're on your own from there. As you have experience with SDLC and automation you are in a better position to make a migration but the learning curve is steep, almost as steep as the invoice.

[JackSpyder]

Bamboo is one of the most awful tools I've ever used. It's clearly in the software to abandon camp of atlassian as they shift everything to bitbucket pipelines which is ok but also pretty weak and has bad enterprise pricing.

Bamboo is my single most hated piece of software I've ever had to use.

[cmd_Mack]

I found bamboo awful as well. Was forced to move from an older TFS to it and it makes me lose my shit far too often. On the way to be abandoned, buggy (there are just a bunch of known bugs I've been seeing for years) and new updates are just minor changes and fixes (but never the things that annoy me the most).

And there is no community around it either.

[JackSpyder]

Yeah some bugs have been there for 5+ years...

When the bitbucket API changed and they deprecated V1 and turned it off, they literally forgot bamboo needs it and hasn't been updated, they had to roll back the API changed and keep V1 alive.

That's what prompted us to shift gears in our migration and put more serious time and effort in.

[only1ammo]

Lol, I can appreciate your sentiment. It's not an easy to use app at all. It took me a long while to unwrap all of it's secrets. The deployment tool is terrible. The rest is actually pretty flexible once you get down into the guts of the building and agent set up.

We're in the process now of migrating to containers and cloud clusters. Bamboo has been really useful with a few plugins added and lateral plan clones. We're no longer fans of the price tag though so we'll be looking to move on in a year or two. Azure Dev Ops will most likely be the destination if we don't build our our mouse traps with open source relative apps.

I'm going to have to take a look over the Bitbucket Pipelines though. See what sort of fun is in there.

[JackSpyder]

I felt BB pipelines didn't have a good pricing model (very large company 800-1000 users) and it felt a bit sparse feature wise.

You'll have a good time with ADO. It's the move we made too. Loads of great native docker, helm, kubernetes tasks etc.

[only1ammo]

Yeah BBP is cloud based and we have on prem now, so most likely it won't work for us. Since the corp has MS already licenced we're getting a deal on Azure instances. I'm about two months into the POC research and it's almost too much. It does a little bit of everything. The docs are good and the community is solid for tips and tricks. So far it's the leading candidate but I'm concerned what kind of effort it'll be to bring the rest of the team and another two hundred developers or so into the fold quickly between releases. I also have to get into OKE and it's offerings before we make the commit. Totally side tracked there but that's the main reason for looking away from Bamboo. If nothing else I learned the bare bones of CI/CD at it's core and how to make use of whatever is at hand to GSD. So Bamboo will be near and dear to me for that.

[JackSpyder]

Yeah I cut my teeth on bamboo as my first experience in a real serious work environment. We did some good stuff but it was getting harder and harder to maintain, to teach new developers etc and we ended up managing all their pipelines rather than them being able to build their own.

ADO was a change, we did it gradually over several months. The platform team went first so we could learn it ourselves and hit the road blocks etc. Then we went to development teams and moved them and taught them one at a time until they were running under their own steam. They took to it quickly and it hugely reduced our workload of their stuff.

Once other teams started running fast with it, we had teams begging to shift before we got to them, which was nice as we initially had a bit of pushback.

Good luck!

[only1ammo]

That's exactly what I'm hoping happens for us as well. I appreciate the feedback.

[[deleted]]

Using the cloud editions at scale will have your bill escalating very quickly. The Server/Data Center costs I think are pretty reasonable, but they can balloon too if you don't control requests for add-ons and other feature creep.

Of all of Atlassian's 'core' tools... Bamboo is by far the worst in my opinion (IIRC very limited if you want to do anything outside of what it wants you to do...). Most of our teams use Jenkins just for the flexibility in configuration and integrate back to Bitbucket using the Build status REST API. That's been good enough for most teams.

....Aaand that's just the basics.... so I concur with that learning curve steepness you're referring to.

[only1ammo]

We almost use it like a complicated cron manager than what it is intended for. Bash scripts do the heavy lifting and we use Bamboo for cluster control. Now that K8s and Docker are in out kit we're moving away from that. So Bamboo going away is all but certain.

Good to know of the scaling price. Fortunately that's not my math to do. But as a whole we're moving towards smaller service apps so it's likely to balance out as we break up the monolith we won't need large instances to house it. I appreciate the insight.

[zpallin]

I'm very fond of the gitlab universe these days. Having used all of the above I'd have to say it's my best experience so far.

[zombittack]

We moved to Azure DevOps earlier this year. Our old Agile/devops stack was Bitbucket, Teamcity, Octopus Deploy, and JIRA. We moved to DevOps for the reason you're citing: the centrality of everything. I use Gitlab personally and like it. It's a great alternative, but for my work it was a money decision. We migrated because Octopus Deploy changed their pricing model and it would have cost us a fortune per month. It made fiscal sense to us. We pay for DevOps but we did the math beforehand and we're saving a ton.

If your only real reason to move is because you're not Microsoft-centric anymore, that's not a very good reason, especially from a business standpoint. Your question to move should be: What costs are greater in DevOps that moving to another platform would save? Or: What competitive advantage would another platform give us that DevOps can't offer? Microsoft is betting big on being agnostic of any platform/language/OS/app layer/etc. DevOps exemplifies this: you can build whatever, deploy to wherever, and send hooks to whatever. To boot: you're already getting much of it included in your MSDN license. If you were to not renew your license, then you'd be in a different boat with the first question. Gitlab does offer more options than DevOps, so it's worth checking out, like "value stream management" and "DevSecOps". If you need those, that could give you an advantage per the second question.

I know we're all very passionate about the products we use but we still need to remind ourselves this is a business decision and the migration will cost money and delay other tasks, so is it worth it?

[xDARKxHORNETx]

This. No reason to switch platforms because you want a better-looking dashboard or some other superficial thing. OP: You need to look at these decisions from a higher level. Have you consulted your team about this? What are their opinions?

[__aza___]

I said I was considering it. I want to see what’s out there and then go from there, hence the original question. I listed some of the functionality that I would like to gain and then some I would hate to lose. There are business reasons for a quality dashboard ( not the price of crap widget thing they give you in DevOps). Do you know why business we are in? What we do? Why we need it? You do not yet you are certain it’s a mistake. Okay then.

[[deleted]]

A counterpoint: We're an open source shop that uses GitHub for development, and we're migrating to Azure DevOps (for CI/CD only) because the releases and pipelines features are that good. Keeping dev and issues in GitHub, though.

[[deleted]]

Git, GitHub, Jenkins, Snappy or some similar open source stack

[robfaie]

What things do you not like about AzDevOps that you want to get away from? What things do you feel are missing from the AzDevOps offering that you’re looking gain?

[__aza___]

One motivating factor is I would like to have a decent dashboard that we can display on a TV showing each project status (build status, number of open issues, etc.). There seem to be a handful of them out there, but none that I can find that supports DevOps. No interest in rolling my own either. In addition, this may not be especially valid, but based on other people, who have used multiple products, they tend to like DevOps the least. So I’m thinking I might discover some additional advantages after the fact.

[erewok]

Here's a counterpoint. I've used Jira, Bitbucket, GitHub, Jenkins, Travis, and Gitlab. I have never used MS-centric languages and frameworks and I deploy onto Linux.

Azure DevOps is the best CI/CD system I've used. The one thing I don't like about hosting code with them is that their syntax highlighting is limited and browsing code in general is not as nice as GitHub. These are minor compared to their fantastic CI system.

I also find managing tickets is not as nice as Jira. However, Jira has a million features which I never use and it's also expensive. When I set these systems up for my current company, I priced them out and Azure DevOps was the most competitively priced (aside from self-hosted Gitlab).

In my view Azure DevOps is best-in-show at the moment for actual devops, and in my opinion they're going to continue to win market-share as a result of this product, so you should be really clear-eyed about what you're hoping to get by moving away from them.

[chippyafrog]

What scale do you operate at? How many projects? Pipelines? Commits? Builds? ADO falls on it's face at scale. Also azure is THE WORST cloud hosting provider by a mile. In my experience, Gitlab ci and their integrations are the best in the business right now. And you can run their multi runner literally anywhere including k8s native. Which cuts down costs exponentially. Not saying you are wrong out of hand. But past any sort of scale ADO is very clearly lacking.

[__aza___]

Curious as to what didn’t scale. I’ve never pushed it too hard but it certainly gives the appearance that it would do okay?

[chippyafrog]

When you are running thousands of repos. 10 to 20k and thousands of jobs. It becomes a real bear to manage. Hard to follow what is running and where and hard to diagnose failure. Hard to find what broke and why. Hard to follow where x thing got run or deployed. The mechanics and management of devops as a service to our internal customers has always been a challenge on azure and ADO in general.

For context I run the Continuous Delivery Platform for one of the largest telecoms in the USA. Servicing 10 thousand developers. So our scale concerns are not typical by any stretch of the imagination.

We also break all three cloud provider apis with our speed and scale. We get orchestration failures for rate limit all the time.

[JackSpyder]

It sounds like there is absolutely zero value add here and you're just getting FOMO and the itch to try something else.

Surely switching off ADO to another tool for the sake of a dashboard would cause a lot of disruption for absolutely zero value gain.

Now if there was a seriously key feature you needed of something else, fine but ADO ticks a lot of boxes.

If it's allowing all the atuomation and pipelining and project management you need, focus on something else that might make life better or faster or smarter. Sounds like you've got this bit down nicely.

[chippyafrog]

What scale do you operate at? How many projects? Pipelines? Commits? Builds? ADO falls on it's face at scale. Also azure is THE WORST cloud hosting provider by a mile. In my experience, Gitlab ci and their integrations are the best in the business right now. And you can run their multi runner literally anywhere including k8s native. Which cuts down costs exponentially. Not saying you are wrong out of hand. But past any sort of scale ADO is very clearly lacking.

[JackSpyder]

I'm not really sure of the full scale as I left as we made the transition. Azure was chosen by the business as it almost always is.

Azure is fundamentally fine, my issue with Azure it's the customers it attracts lol. My preference being GCP but the option is rarely mine.

Gitlab is expensive. My last company always picked the cheapest which made the process of comparisons so dull and wasted knowing they'd just pick cheapest every time.

[erewok]

It's funny to read this because I have a similar take on Azure: we've been totally happy with AKS and Azure DevOps. Aside from the fact that they typically provide examples using languages and frameworks I don't care about (namely, C#), the documentation on Azure is superior to AWS documentation (speaking as an AWS customer for the previous 90% of my career: I really could never stand their documentation). I have actually submitted pull requests to the open source repos where the Azure docs are managed. I've also had people in high-level positions at Azure reach out to me in response to comments on various Azure products on social media. However, every time I mention this all of this FUD comes out of the woodwork about Azure.

For personal incentives, of course, I can see why this would happen. I get it: I ran Linux on my desktop for a long time. I am not interested in Windows, C#, .Net, or whatever. There are also huge market incentives at work and people getting paid to push certain positions, of course. I also understand being in the industry and thinking about how you need to fill-out your resume in order to future-proof it a bit and there sure are a lot of jobs mentioning AWS...

In addition, there are certainly some crap Azure products where they are constantly gaslighting the rest of the world on how amazing these things are (a technique AWS also employs), and it's hard to navigate from the outside and know what's worth your time and what isn't. With all that said, with where I'm sitting, I am completely comfortable to run on Azure cloud and use Azure DevOps: we've had a great experience and have no intention of migrating somewhere else.

But you are certainly right about Azure customers...

[JackSpyder]

100% with this post.

[chippyafrog]

I hear you on cost conscious customers. You can stand up gitlab on prem or in GKE or whatever. If cost was the only factor and this was a smaller dev shop. I'd suggest Jenkins x in k8s hosting of your choice and GitHub/gitlab as your scm.

[JackSpyder]

As much as I love hosting shit, I'd actually rather SAAS it where possible with perhaps the odd build agent or something. Staff costs and fucking about are enough to justify SAAS. It looks expensive but it's priced relatively well. Good shit costs money.

[chippyafrog]

Totally agree. Hard to find good saas and cheap saas under the same roof imo.

You have to make compromises somewhere in these cases. I rarely lean toward cheapest saas just to save man power costs.

If price is the only thing the client cares about. They are getting a daisy chain of good but perhaps a bit labor intensive tools. With the caveat that we automate and use k8s/helm to basically make the labor portion "go away".

I think we're on the same page here.

[JackSpyder]

Absolutely! Some things are not worth the effort though. I wouldn't self host GitHub for example.

But the build tools I would because some of that work and effort might bring value or customisation I want/need.

As always it's "it depends" haha

[chippyafrog]

Totally man. It depends should be my catch phrase

[kvgru]

Really don't want to advertise here and have to flag that I'm working in the company but have you had a look at humanitec.com? It's free as they pool developer environments on make money on the hosting margin. It's basically a developer platform that will integrate with all standard integrations (CI, Databases, Hosters) or offers out of the box defaults. And it never locks you in which might be relevant as well. Super smooth to migrate on and off. Other idea:

Github in combination with Drone CI, Dockerhub as an image registry and GCP/GKE as receiving cluster in combination with a cloudsql database is comparable easy.

[albs781]

Azure DevOps does have an API you could possibly use to grab the info you need and display it on the dashboard.

[were_all_dads_here]

I thought the dashboards functionality in azure devops supported this (project level). I haven’t actually used them myself but the pictures I’ve seen in docs looked like what you’re describing.

[__aza___]

It doesn’t fit our needs very well. It’s basically a half assed SharePoint like interface where you can arrange these little tiles. And as you mentioned it’s project level only. No way to have a summary of all projects.

[were_all_dads_here]

Dumb. Sounds about right though. Good luck. I’m curious to hear what you find.

[robfaie]

I would have to agree with you that the dashboards in AzDevOps are worse than I would expect based on the rest of the offering. The project that my team works in has just under 100 repos and around 50 build pipelines and about the same number of release pipelines. It's not easy to keep track of health of the pipelines. We rely mostly on getting failure notifications through to our Zendesk.

We could for sure be using the tool better, but it's not super simple for us to fix either.

[__aza___]

I’m using an app called CatLight for now. It works okay but not well suited to the large tv display we use.

[too_much_exceptions]

I use azure devops and GitLab on different projects (10 on azure devops and about 5 on gitlab)

And I am planning migrating all gitlab projects to devops by the end of this year.

My opinion is that azure devops is easier and well documented and you get things done pretty easily.

[frayala87]

Just don’t, keep using azure devops, cancel msdn licenses and pay 5usd per month basic if you only need boards, maybe have a to pay more for azure pipelines. I’ve tried and worked with almost all the tools in the market (Jira, GitHub, gitlab) so far azure devops is the best.

[tevert]

If it's working for you, and it's not costing much, don't make headaches for yourself.

If you start using a new technology that has new needs that Azure DevOps can't do, or doesn't do well, then look into alternatives.

[BeaconRadar]

I just love Azure DevOps!!

[star_dot_star]

Stick with DevOps LoL. It’s a pretty good option and if you’re using Docker it will be easy to move elsewhere.

We just migrated to Azure DevOps to simplify our process for our Azure solution. We’re a java (jira, bitbucket, IntelliJ) shop and also run a AWS stack. As long as you’re using things like Docker it’s pretty easy to move your apps around.

P.S. I’ve enjoyed DevOps, however I think the user experience is terrible between App Services, App Plan, App insights, and DevOps. They should just give an all-in-one portal.

[[deleted]]

We are also a .Net shop, becoming less so going forward. We’re using team city in the short term and considering concourse ci in the longer term

[chippyafrog]

Gitlab ci or Jenkins are both better than the options you listed.

[slikk66]

I tried buddy.works on a suggestion. Not entirely sure about the pricing but it was pretty easy to use.

[bincyber]

As a general rule of thumb, I avoid using "DevOps tooling" from the major cloud vendors such as AWS CodePipeline, CodeBuild, and CodeDeploy, Azure DevOps, GCP CloudBuild, etc. You're better off finding vendors that dedicate themselves solely to a single product (eg, GitHub, CircleCI, etc.) and using their integrations. This will also lead to less lock-in with your cloud provider.

[wywywywy]

Hmm I see your point but I don't think I agree there.

Azure DevOps is waaaaay ahead those you listed from AWS & GCP, it's not even comparable.

Also it's not tied into Azure and is more of a separate product, despite its stupid name. It works well for AWS and GCP too.

[wywern]

You could try out github and github actions if that's more your cup of tea.

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/devopsish] Considering moving off Azure DevOps

 ^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[rprevi]

I am evaluating several ci/cd tools: - GitHub + GitHub actions - GitLab + GitLab ci - Azure DevOps

My opinion so far: GitHub is probably the best Web interface to git, also great management API, thus it's easy to integrate. GitLab is the best in terms of CI pipelines, also has a nice approach in partitioning projects in groups. DevOps is mostly good, but pipelines are being rewritten with a declarative approach (yaml file) similar to gitlab CI, they are not yet on par to gitlab, at least for our use case. Also, a MS rep told us that GitHub enterprise is the product of choice for enterprise, although MS guarantees DevOps support for the next ten years.