Introducing Azure DevOps
azure.microsoft.com
azure.microsoft.com
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.
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?
(Work on VSTS team)
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.
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.
Interesting move!
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?
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
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...
https://visualstudio.uservoice.com/forums/330519-visual-stud...
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/...