Thats not 1080p
I'm not sure what you mean by this but a few other people have asked me about the described screen size problem so I decided to add some clarification.
Microsoft’s Azure DevOps: An Unsatisfying Adventure
151–160 of 197 posts
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#152PM for Azure DevOps here. We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here. Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the…
I was pretty excited to see steadily improving GitHub integration. Unlike the others here, DevOps has been my most positive experience compared to a few others like Travis and AppVeyor. However, this confidence was seriously undermined when I noticed recently that my GitHub pull request validation build stopped working when I closed the DevOps tab. Yes, seriously. I have to keep the DevOps tab open for my builds to a…
I'm an engineer on Azure DevOps. GitHub PR build triggers are based on notifications our service gets from GitHub (purely service to service), and is unrelated to any state of the UI. Can you reach out to me on email so we can investigate? Use my HK name at microsoft.com.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#153PM for Azure DevOps here. We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here. Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the…
Often when I click Releases it is completly blank. All our releases are missing. I have to refresh 2-3 times before they show up.
The UI has so far changed five times in the past three months. It is insane. The current iteration is at least fine. Before it was a big blob of round circle that showed that the steps that succeeded succeeded. And then a big text saying it failed. It was worthless.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#154Earlier quoted context omitted.
pretty much it, also azure is slightly better at pricing in asia
This mimics the mac vs windows argument I had with my brother-in-law where it boiled down to the fact that you could run windows on something cheaper than a macbook. Even though in order to remap caps lock to something reasonable you have to edit the registry. In 2019. The best answer I think involves windows server 2003 resource kit and its UI, which is so old it could get a driver's license. You save money but what…
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#155PM for Azure DevOps here. We've been investing heavily in our user experience and our CI/CD experience, so I'm sad to see that we've disappointed here. Some of these complaints I would agree with - in particularly, we're not (yet) caching build resources - though we're working on this now. But most of these complaints I was quite surprised to hear; not an experience I would want someone to have or what I see from the…
I've migrated my Boost builds from Travis and Appveyor to your CI offering recently. It wasn't super smooth, but I got it to work quite fast and I like it a lot. So sure, I'm missing caching that I've had on Travis. But honestly, it builds reliably fast anyway. On Travis, I always needed to wait a LONG time to get macOS agents, on Appveyor, we were limited to 2 parallel builds. Here, everything starts all at once, co…
You can add as many additional parallel builds as you want to AppVeyor for $50/m each - is Azure CI pricing comparable to AppVeyor with only two concurrent builds?
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#156How do all of you people get on this broken stuff on Azure with GCP and AWS (I think) being so good? Is it like free credits?
My current job has various .NET/Windows-based software products that can run as PaaS projects in Azure - from what I've seen it wouldn't be practical to run them on AWS/GCP without managing VMs.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#157Earlier quoted context omitted.
(Former Azure DevOps PM here) That's not quite true - did you hear that from someone? When I was there, I had pretty much full freedom to talk with customers, as long as they hadn't opted out of contact. Never had to talk to PR or have emails looked at. Sorry that you didn't hear back though :(
What does "opted out of contact" mean? I wonder if I am missing some communications because I unchecked some "don't send me spam" checkbox now!
That usually means the "unsubscribe" link at the bottom of your email. Clicking that is usually quite permanent.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#158Tangential: Reading this _really_ makes me appreciate the extremely stable system my team has build internally with GitLab and TeamCity. Azure DevOps sounds extremely frustrating (besides the point that I cannot stand the name they gave this product, and GitLab made that same mistake with the Auto DevOps feature name).
Thanks for using GitLab! We're open to a better name for Auto DevOps https://docs.gitlab.com/ee/topics/autodevops/ but we haven't been able to find one. Suggestions are very welcome. BTW We're planning to add per per minute for the CI runners and add shared MacOS and Windows runners so people that don't want to manage their own no longer need to.
That's awesome. We have so much customization around TeamCity that moving away from it doesn't make sense, but we're starting to look at the CI runners for other things, along with the k8s integration, all great stuff in GitLab. Yeah, the DevOps name though, it's unfortunate. DevOps is a culture, not a thing, product, tool, or process. Seems more like calling it Auto CI/CD is more appropriate, maybe? Anyways, thanks for the response!
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#159Earlier quoted context omitted.
Thanks for using GitLab! We're open to a better name for Auto DevOps https://docs.gitlab.com/ee/topics/autodevops/ but we haven't been able to find one. Suggestions are very welcome. BTW We're planning to add per per minute for the CI runners and add shared MacOS and Windows runners so people that don't want to manage their own no longer need to.
That's awesome. We have so much customization around TeamCity that moving away from it doesn't make sense, but we're starting to look at the CI runners for other things, along with the k8s integration, all great stuff in GitLab. Yeah, the DevOps name though, it's unfortunate. DevOps is a culture, not a thing, product, tool, or process. Seems more like calling it Auto CI/CD is more appropriate, maybe? Anyways, thanks…
Thanks for the Auto CI/CD suggestion. I struggle with it since it doesn't cover things like license management and monitoring.
I agree DevOps is a culture foremost. But at the same time it is starting to turn into a product category (DevOps tools).
Hope you are able to adopt GitLab with ease.
Re: Microsoft’s Azure DevOps: An Unsatisfying Adventure
#160Earlier quoted context omitted.
I've migrated my Boost builds from Travis and Appveyor to your CI offering recently. It wasn't super smooth, but I got it to work quite fast and I like it a lot. So sure, I'm missing caching that I've had on Travis. But honestly, it builds reliably fast anyway. On Travis, I always needed to wait a LONG time to get macOS agents, on Appveyor, we were limited to 2 parallel builds. Here, everything starts all at once, co…
You can add as many additional parallel builds as you want to AppVeyor for $50/m each - is Azure CI pricing comparable to AppVeyor with only two concurrent builds?
Last time I checked, the free offering was 2 CI builds in parallel on AppVeyor, which is just too low and slow for feedback on my project.
Also, considering I make exactly $0 per month from it, it's either be patient or use another service that had more capacity and faster builders.
I believe that Travis-CI had a higher limit for parallel jobs, but your builds would most often end up queued because of a low capacity for a certain type of agents. Also, something quite noticeable was their lower limits on build time, which is why for some builds a cache was necessary. It got a bit hairy when you needed a full successful build to properly populate the cache but they would never finish in time. And of course, the biggest drawback from Travis-CI back then was the lack of Windows support.
As for Azure CI, I believe there's something like a 10 parallel builds limit. And I've got exactly 10 configurations!