As a long time user of VSTS, I am failing to see how Azure DevOps is different from VSTS. Boards, CI/CD, testing - that's already part of VSTS, and has been for quite some time. Is Microsoft just rebranding for keyword searching or something? Or are there actual technical changes / new features that are being introduced?
This is a rebranding yes.
VSTS was a bad name that confused potential customers because they thought of the IDE, and so no one really knew what the product was from the name alone.
Hah, long time TFS and VSTS user here - I recently got so annoyed with colleagues mis-using these acronymns that I sent out an email with a glossary of terms for TFS, VSTS, TFVC, VSO etc :)
PM for Azure DevOps here (formerly VSTS). It is a rebranding, but it's more than merely a rebranding. We're breaking out the individual services so that they're easier to adopt. For example, if you're just interested in pipelines, you can adopt only pipelines.
We've got some neat new features launching today and more coming soon. My favorite new feature is the Azure Pipelines app the the GitHub Marketplace. It makes it one-click to build a continuous integration and pull request validation pipeline right from your GitHub repository, you don't even need an Azure DevOps account to get started.
If the point of the rebranding is to help drive adoption of the individual components of what used to make up VSTS, then it seems to me like the strategy is to try and get people to switch from pre-existing toolsets to Azure tooling.
Maybe it would be more persuasive if you could show some kind of comparison or case study for switching? For instance, if you want to make it easier for people to adopt Azure Boards, then why should they adopt Azure Boards over the myriad other agile planning products out there?
More importantly, if you're trying to make individual services easier to adopt, why is there only unified Azure DevOps pricing and not pricing solely for the individualized products (excepting Azure Pipelines pricing, which is a per-agent pricing model)?
You're right that we need to provide some better comparisons here, but the big reason that I'm excited about making individual components easier to adopt isn't for competition, it's to help people round out what they're missing in a dev tools stack.
There's a lot of shops that are happy with their git hosting provider and their agile planning tool and go looking for a CI/CD tool and may have been turned off by VSTS because it looked like a monolith. Making it clear that you can just use Azure Pipelines without having to use the entire stack was a priority for us, but you're absolutely right that we need to round this out with some better case studies. Thanks for the feedback.
Yeah that would be a good start. There's clear value-add here for on-prem teams which are starting to move to the cloud, by making it easier to run builds both on Azure and on-prem (seeing the $15/month pricing per agent) from the same cloud-based product, which I don't think anybody else is doing yet? But there doesn't seem to be any documentation about how to get that set up?
It would definitely help to see comparisons against competition, e.g. GitLab, CircleCI
Yeah - the hybrid cloud and on-premises build agents is actually one of my favorite features. The open source project that I help maintain (libgit2) uses VSTS's hosted Linux, Windows and macOS build agents, but add support for some other platforms (like ARM) with on-premises build agents.
("On-premises build agents" makes it sound fancier than it is, it's actually Raspberry Pi's on my desk, but hey, whatever works, right?)
As a mostly very satisfied user, I gotta say, y'all have a great product. The CI/CD part of VSTS (I like the old name better :P) is killer and by far my favorite platform to use now. However, I've had my builds break twice out of nowhere with no recourse other than submitting a forum post and hoping someone gets back to me in a reasonable amount of time. I can't imagine going back to another platform, but its really frustrating when your production release process for a client is completely down and you have no way to fix it. Is there a way to get better support in those scenarios?
I'm sorry to hear that - without knowing more about how it broke, it's hard for me to say. Can you give me some more information about how it's broken in the past? Links to the forums posts would be great. Probably the best way to get them to me is by email, it's my HN name @microsoft.com.
Another (mostly) happy VSTS user here, also loving the CI/CD functionality.
I too have had builds break recently out of nowhere:
1. Related to NPM being upgraded on the hosted agent, which was fixed easily enough (after trawling through logs) by forcing the task to use an older version
2. SQL LocalDB connections stopped working, so integration tests couldn't run - this lasted for around 2 weeks!
I also ended up on the Microsoft support forums... unfortunately, responses on those forums from Microsoft staff are invariably late and of infuriatingly poor quality.
I ended up on the VSTS Agent image GitHub site instead, and raising an issue there was far more helpful.
VSTS is a great product, I just really wish there was a decent support option for when things go wrong.
I also wish Microsoft would actively communicate with impacted customers to notify them where there are outages.
Oh, and I wish the hosted build agents ran on better hardware - they are slow, even compared to the smaller Azure VMs. For example, we have a build that takes 14 minutes on the (paid) hosted agent, or 3 minutes on a B2ms Azure VM. Some of that is down to NPM and Nuget package caching, but even the actual msbuild and test stages are much slower.
I'm glad you're mostly happy, but I'm sorry it's only mostly. I hope that we'll improve this. Honestly, the lowest latency mechanism is to hit @AzureDevOps up on twitter (or me personally) and we'll make sure that your problems get routed to the right person.
For outages, you can subscribe at https://blogs.msdn.microsoft.com/vsoservice (in the toolbar on the right hand side). We don't send out email notifications without you opting in, nor will we, but we do have some ideas to improve the way we notify people that we're working on.
And as for build agents, we're working on that, especially around the caching. Appreciate all the feedback.
Azure Boards is a powerful work management service designed especially for engineering teams that allows you to not only plan work in a backlog or board view but also link across all your artifacts such as commits, pull requests, builds, even other work items. Yes, it's also integrated into Visual Studio and Visual Studio Code. [Program Manager on the Azure Boards team.]
We are considering using TFS (now Azure DevOps Server) for CI/CD of database related projects. Curious, how does DevOps handle SQL Database, SSIS, SSRS and SSAS visual studio projects when it comes to CI/CD? We have a custom solution currently in place, but would like to simplify this if possible.
They try to keep me away from the SQL, so I don't have the most enlightened answer, to be honest. But smart people that I trust tell me that Redgate's tools are really excellent for SQL Server and SSRS projects. And that they integrate nicely into a CI/CD pipeline for "Database DevOps".
The term "DevOps" is now meaningless. The search for a new short term to describe "operations and development teams working together using high quality software tools to define, automate and distribute configuration and management information, integrating QA, release management and security" has begun.
It makes almost no sense for a tech platform to be a DevOps tool. It's like saying saying a programming language is better at supporting agile. DevOps is a matter of how you assign responsibility to people in your org. Not how they get there.
Some languages are better at supporting agile development. The idea behind agile is that things change, so your language needs to help rather than hinder those changes. It should make separation of concerns / single-responsibility easy, rather than something you have to fight the language for.
The idea behind DevOps is integration between development and operations, in a way that eases automation of tasks where they interact. A platform absolutely can provide a structured way to do that integration, or can interfere with it.
> "operations and development teams working together using high quality software tools to define, automate and distribute configuration and management information, integrating QA, release management and security"
This description has enough wiggle room that you could sail an aircraft carrier through it. I don't think there can be a short term to describe all that and stay meaningful; the term "devops" itself has always been quite fuzzy, and every person you'd ask would explain it differently.
The discipline broadly described as "DevOps engineering" is just a way for employers to get senior staff to do the work that really should be handled by multiple, narrower disciplines (e.g., security engineers, automation engineers, tooling engineers, etc.) for a lower cost.
Perhaps you would re-read what I wrote? I didn't suggest that people should add more hats -- I suggested that people should cooperate more, and learn from each other.
It makes no sense to have a security policy and an implementation of that policy and not have it be automatically distributed and applied, for instance. And security implementations should be tested just as much as any other code.
DevOps is not a role, it's a culture and set of processes to improve speed of delivery through interaction and teamwork between development and operations.
I gave myself a title at my last job that more accurately reflected the nature of the work - Senior Software Therapist. You get what you put into it, hopefully you don’t need the person for long, but most people that start it will probably not listen to the therapist and stay in treatment for longer. If your software and organization building and running it works 100% fine then you don’t need the therapist.
Perhaps because of mental illness stigmas? Also, if you're a therapist, then you're more of a software engineering organizational therapist - it isn't the software that needs therapy, it's the organization building and maintaining it.
Eh, not a big fan of this, but if it's a just a rebrand no big deal I guess. But what happens when if the DevOps concept turns out to be a fad? Visual Studio has such a positive and strong brand association among .Net developers it seems a shame to jettison it but I suppose it's necessary as MS is trying to convince other stacks to use the Azure DevOps(VSTS) CI/CD pipelines.
[PM on the Azure Pipelines team] The primary focus here is making the individual services easier for teams to adopt. Azure pipelines for CI/CD, Azure Boards for planning, etc. Those services support the overall goal of improving your DevOps practices.
I love Visual Studio, but the product currently known as Azure DevOps (formerly known as VSTS) really has nothing to do with Visual Studio.
The name made a lot more sense back in the day when the premier client was actually the Visual Studio IDE. But today, most people interact with Azure DevOps with their browser and too many people think "Visual Studio Team Services" is a web-based IDE.
The name change is bittersweet. We've been "Visual Studio <something>" since the first release of our on-premises product, well over a decade ago. But I'm confident about this next phase of Azure DevOps.
VSTS naming was a complaint I heard all the way back at Build 2016. Everyone at the Build booth was confused, and even the people manning the booth said the name was confusing. So...it took long enough.
Still no Mercurial. yawn Really sucks to see Microsoft giving up on us Hg users, considering it was the only viable DVCS on windows for years until people finally got git working with a bunch of issues.
Considering how comparatively rare it is, it's unlikely to ever be supported natively. Microsoft has invested a lot into git and now uses it for the Windows codebase, which is the largest repo by several magnitudes.
Azure DevOps has been built with an open eco-system that enables other to plug-in their products in our stack, for example AWS has their tools for VSTS (our former name): https://aws.amazon.com/vsts/
I've been impressed by the ease of use for VSTS. We've adopted it for our team, and it has really reduced the friction in our CI/CD pipeline. We've been able to automate the entire process. It seemed to be easy to setup because there is a Task for just about anything you want to do. Shout out to the Azure DevOps (VSTS/TFS) team. Keep it up, nice work!
There are a bunch of CI tools (Jenkins, Travis, etc.) that offer either hosted service that work everywhere, or on-prem which can be installed on every major platform.
I wonder if Azure DevOps will have a day long outage like VSTS had last week? That had a legitimately productivity cost to a lot of companies, and the more vested in the VSTS toolchain you were the harder hit you were.
I'm legitimately surprised they're launching this so soon after that, particularly considering there's been no real post-mortem, and no update on how they'll stop this happening again.
"It is Azure's fault" isn't an answer, and re-branding this Azure DevOps makes that excuse almost hilarious. I'm well aware that Azure AD was down, and that VSTS has a strong dependency on it, but ultimately we're still talking about a single data center bringing down VSTS for all of North America for an entire work-day.
It has been a week and now they're trying to encourage you to push your whole deployment toolchain (manage, build, test) into their cloud.
I certainly hope not. I'm not going to argue that this was anything but a disappointment to our customers - and one that we're eager to prevent from happening again.
But we have never said that this was Azure's fault. It wasn't. We've put the blame where it belongs: on us. We're nearly done writing up the root cause analysis and an analysis of our next steps to prevent this from happening in the future.
3 weeks ago there was a different outage that meant no hosted build agents were working in the west europe region, and it lasted for more than 24 hours.
Now, what I hated the most about this was the communication - there wasn't any. Why not email impacted users to let them know you're aware and working on a fix?
PM for Azure DevOps here. The team is really excited about this launch, and many of us are here to answer questions on Azure DevOps, or any of the individual services like Azure Pipelines, the new GitHub Marketplace app, or our free build offer for open source projects.
I'm sorry to hear that - can you contact our support directly through the method of your choice? https://azure.microsoft.com/en-us/support/devops/ has the options. (Sorry, our team hangs out most places, but we don't do support on HN).
The VM based build agents are slow, especially compared to more modern CI/CD systems that today use a Docker/container based approach for each build step, along with a persistent store between each step.
We've just finished building the initial version of container jobs [1]. A job groups up a number of steps -- we haven't yet decided if or how we should implement container-per-step. I'd be interested in your thoughts and use cases. In case I miss you here, my email is mattc@xbox.com.
I've been using VSTS (Visual Studio Team Services) for a few years now, and I think it's great.
But this looks like they've just changed the URL and stuck the name "Azure DevOps" onto the VSTS site? Even the pricing and plans seem to be the same - I really don't get how they're talking like they're launching something new, rather than just having a rebranding exercise after buying GitHub.
There have already been quite a lot of UI/UX updates over the past 6 months of so. TBH, I kind of wish you'd leave it the hell alone for a bit!
In particular, I'm not a fan of the most recent changes to the 'build and release' pages. To edit the build pipeline, the edit link is at the top of the list of builds, rather than at the top of the list of build pipelines... I end up searching for the link every. single. time :(
I don't work on it, you should reply to the PM on this page or reach them via twitter/email to discuss further. Seems they are willing to listen: https://news.ycombinator.com/item?id=17953476
At the risk of sounding philosophical, when you're building a cloud service that gets continuous delivery of features... when is that simply an iteration, versus something new?
Anyway, I'm not a philosopher. But I don't think that this is simply a "rebranding exercise", and it's been in the works for quite a while; it's not related to GitHub (which, for the record, we have not yet acquired).
We've made a huge engineering effort into the individual components that make up Azure DevOps, and those deserve (in my opinion) to be recognized. So, now "Azure Pipelines" gets to shine on its own.
Or is the idea that this is going to be marketed towards Azure users and GitHub will be promoted to the new VSTS once it gets a few more features for project management and PRs?
No, they can't use their free Azure credits towards Azure DevOps.
Azure DevOps is free for teams of up to five users. It's also effectively free for open source use by teams of any size. Larger teams working on private projects would need to be on one of the paid tiers and can't use the free Azure credits to pay for that.
To clarify a bit: _Azure credits_ cannot be used to pay for Azure DevOps subscriptions. So if you want another parallel pipeline, then you cannot use Azure credits to pay for that.
However, Visual Studio subscribers do get licenses for Azure DevOps. If you're a Visual Studio Professional subscriber, then you get a Basic license for Azure DevOps. You get additional benefits if you're a Visual Studio Enterprise subscriber. You can find the details at https://docs.microsoft.com/en-us/visualstudio/subscriptions/...
@ethomson Any word on this long standing feature request with the rebranding - read the comment on the request, a simple update would be super helpful.
91 comments
[ 1.6 ms ] story [ 145 ms ] threadAs a long time user of VSTS, I am failing to see how Azure DevOps is different from VSTS. Boards, CI/CD, testing - that's already part of VSTS, and has been for quite some time. Is Microsoft just rebranding for keyword searching or something? Or are there actual technical changes / new features that are being introduced?
(Work on VSTS team)
https://news.ycombinator.com/item?id=17953823
I'm nitpicking though, and I have to say, 10 concurrent jobs and unlimited build time is really generous.
We've got some neat new features launching today and more coming soon. My favorite new feature is the Azure Pipelines app the the GitHub Marketplace. It makes it one-click to build a continuous integration and pull request validation pipeline right from your GitHub repository, you don't even need an Azure DevOps account to get started.
Maybe it would be more persuasive if you could show some kind of comparison or case study for switching? For instance, if you want to make it easier for people to adopt Azure Boards, then why should they adopt Azure Boards over the myriad other agile planning products out there?
More importantly, if you're trying to make individual services easier to adopt, why is there only unified Azure DevOps pricing and not pricing solely for the individualized products (excepting Azure Pipelines pricing, which is a per-agent pricing model)?
There's a lot of shops that are happy with their git hosting provider and their agile planning tool and go looking for a CI/CD tool and may have been turned off by VSTS because it looked like a monolith. Making it clear that you can just use Azure Pipelines without having to use the entire stack was a priority for us, but you're absolutely right that we need to round this out with some better case studies. Thanks for the feedback.
It would definitely help to see comparisons against competition, e.g. GitLab, CircleCI
("On-premises build agents" makes it sound fancier than it is, it's actually Raspberry Pi's on my desk, but hey, whatever works, right?)
I too have had builds break recently out of nowhere:
1. Related to NPM being upgraded on the hosted agent, which was fixed easily enough (after trawling through logs) by forcing the task to use an older version
2. SQL LocalDB connections stopped working, so integration tests couldn't run - this lasted for around 2 weeks!
I also ended up on the Microsoft support forums... unfortunately, responses on those forums from Microsoft staff are invariably late and of infuriatingly poor quality.
I ended up on the VSTS Agent image GitHub site instead, and raising an issue there was far more helpful.
VSTS is a great product, I just really wish there was a decent support option for when things go wrong.
I also wish Microsoft would actively communicate with impacted customers to notify them where there are outages.
Oh, and I wish the hosted build agents ran on better hardware - they are slow, even compared to the smaller Azure VMs. For example, we have a build that takes 14 minutes on the (paid) hosted agent, or 3 minutes on a B2ms Azure VM. Some of that is down to NPM and Nuget package caching, but even the actual msbuild and test stages are much slower.
For outages, you can subscribe at https://blogs.msdn.microsoft.com/vsoservice (in the toolbar on the right hand side). We don't send out email notifications without you opting in, nor will we, but we do have some ideas to improve the way we notify people that we're working on.
And as for build agents, we're working on that, especially around the caching. Appreciate all the feedback.
Is there any specific changes between the two, like for example can you point a changeset at an Azure Boards item from within Visual Studio?
The idea behind DevOps is integration between development and operations, in a way that eases automation of tasks where they interact. A platform absolutely can provide a structured way to do that integration, or can interfere with it.
This description has enough wiggle room that you could sail an aircraft carrier through it. I don't think there can be a short term to describe all that and stay meaningful; the term "devops" itself has always been quite fuzzy, and every person you'd ask would explain it differently.
"devops: operations and development teams working together."
It makes no sense to have a security policy and an implementation of that policy and not have it be automatically distributed and applied, for instance. And security implementations should be tested just as much as any other code.
In the meantime, interesting work continues to be done developing the ideas of DevOps and extending them.
[1] The Site Reliability Workbook, from Google, 2018 https://books.google.com/books?id=fElmDwAAQBAJ
[2] Securing DevOps, Julien Vehent, 2018 https://www.manning.com/books/securing-devops
I personally dont like the term devops either... I prefer a more specific definition fo a role.
I have not gotten much traction.
Time to re-rebrand
The name made a lot more sense back in the day when the premier client was actually the Visual Studio IDE. But today, most people interact with Azure DevOps with their browser and too many people think "Visual Studio Team Services" is a web-based IDE.
The name change is bittersweet. We've been "Visual Studio <something>" since the first release of our on-premises product, well over a decade ago. But I'm confident about this next phase of Azure DevOps.
"really? it's not enterprise-y enough?"
"fuck no, watch this!"
Interesting move!
There are a bunch of CI tools (Jenkins, Travis, etc.) that offer either hosted service that work everywhere, or on-prem which can be installed on every major platform.
Travis for instance only supports Mac and Linux. Circle CI supports Mac and Linux. Appveyor supports Windows and Linux.
Other tools like Jenkins or Buildkite can be installed anywhere but you have manage the build servers.
I'm legitimately surprised they're launching this so soon after that, particularly considering there's been no real post-mortem, and no update on how they'll stop this happening again.
"It is Azure's fault" isn't an answer, and re-branding this Azure DevOps makes that excuse almost hilarious. I'm well aware that Azure AD was down, and that VSTS has a strong dependency on it, but ultimately we're still talking about a single data center bringing down VSTS for all of North America for an entire work-day.
It has been a week and now they're trying to encourage you to push your whole deployment toolchain (manage, build, test) into their cloud.
But we have never said that this was Azure's fault. It wasn't. We've put the blame where it belongs: on us. We're nearly done writing up the root cause analysis and an analysis of our next steps to prevent this from happening in the future.
Now, what I hated the most about this was the communication - there wasn't any. Why not email impacted users to let them know you're aware and working on a fix?
I do still think it would be better if you proactively sent out emails only to affected customers though.
I own skmexyz.visualstudio.com (under sk@skme.xyz account) and I tried to transfer it to skmexyz@skmexyz.onmicrosoft.com and now:
1. Both accounts are not admins so I can't delete / modify it (it asks me to contact the administrator when I am obviously the administrator)
2. It claims that it's being managed by Default Directory on Azure but I can't appear do anything with it.
I would really appreciate some help with it.
Is something like this going to arrive soon?
We've just finished building the initial version of container jobs [1]. A job groups up a number of steps -- we haven't yet decided if or how we should implement container-per-step. I'd be interested in your thoughts and use cases. In case I miss you here, my email is mattc@xbox.com.
[1] https://docs.microsoft.com/azure/devops/pipelines/process/co...
But this looks like they've just changed the URL and stuck the name "Azure DevOps" onto the VSTS site? Even the pricing and plans seem to be the same - I really don't get how they're talking like they're launching something new, rather than just having a rebranding exercise after buying GitHub.
Although there have been slight tweaks and UI/UX updates.
In particular, I'm not a fan of the most recent changes to the 'build and release' pages. To edit the build pipeline, the edit link is at the top of the list of builds, rather than at the top of the list of build pipelines... I end up searching for the link every. single. time :(
Anyway, I'm not a philosopher. But I don't think that this is simply a "rebranding exercise", and it's been in the works for quite a while; it's not related to GitHub (which, for the record, we have not yet acquired).
We've made a huge engineering effort into the individual components that make up Azure DevOps, and those deserve (in my opinion) to be recognized. So, now "Azure Pipelines" gets to shine on its own.
* Pipelines is a stand-alone service that can be acquired and used separately
* Pipelines can be directly acquired and configured from the GitHub marketplace
* Pipelines is effectively free to use for open source
* Pipelines free limits have been significantly increased for private projects
* Other Azure DevOps services (e.g. Boards) can now be used separately, too
1. Team Foundation Server (TFS)
2. Visual Studio Team Services (VSTS)
3. Azure DevOps
Imagine if GitHub renamed itself every few years?
Or is the idea that this is going to be marketed towards Azure users and GitHub will be promoted to the new VSTS once it gets a few more features for project management and PRs?
https://twitter.com/styfle/status/1032702016064286720
Azure DevOps is free for teams of up to five users. It's also effectively free for open source use by teams of any size. Larger teams working on private projects would need to be on one of the paid tiers and can't use the free Azure credits to pay for that.
However, Visual Studio subscribers do get licenses for Azure DevOps. If you're a Visual Studio Professional subscriber, then you get a Basic license for Azure DevOps. You get additional benefits if you're a Visual Studio Enterprise subscriber. You can find the details at https://docs.microsoft.com/en-us/visualstudio/subscriptions/...
https://visualstudio.uservoice.com/forums/330519-visual-stud...