4 ms·

And such confusing naming yet again. Makes it sound like a cross between Visual Studio IDE (the heavyweight version) and the god awful Team Foundation Services.

snuxoll 9y ago
It's a rebranding of Team Foundation Services, tbh. They've done a lot to improve it over the years, but as someone who is forced to work with it daily I'd still take just about anything else - better than it used to be doesn't make it a "good" product by far.
- scarface74 9y ago
  As a CI/CD tool, what do you feel is missing?
  - snuxoll 9y ago
    There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool. Beyond that, the new build tooling isn’t half bad - leaps and bounds ahead of the nasty XML nightmare which is why our team has been moving back to it from out TeamCity deployment. Most of my gripes with VSTS are around the rest of it, everything under “Work” has barely been touched since TFS 2012 - it got a coat of paint but it’s still the same enterprise-grade turd that makes me yearn for JetBrains YouTrack every day. They’ve had adequate git support for a while but the web-based repository browser is such a chore to use that I end up cloning a repository to do a quick search more often than I should need, the admin interface is still a mess to navigate, the list goes on.
    - scarface74 9y ago
      There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool. Your build and deployments are just a JSON file that you can export and import either from the web or the API. The other parts of VSTS are obtuse. But since my chosen workflow is Kanban, it's quite easy to setup a Kanban board with WIP Limits. What I really hate is the Wiki. It supports basic Markdown without all of the bells and whistles of Atlassian but its okay.
      - snuxoll 9y ago
        Being able to quickly export and import build configurations isn’t where the value of having them stored in a human-editable format comes from - your build tooling is part of your project and evolves with it, being able to arbitrarily build any commit regardless of whether your current build pipeline can support it or not is invaluable, as is being able to change the pipeline on a WIP branch while not breaking master. The Wiki is pretty terrible too, but I’ve never found a wiki that makes me go “wow, this is AWESOME” either - dokuwiki got reasonably close though because it gets the hell out of the way and offers just enough formatting without letting me choke on markup like MediaWiki or the WYSINWYG hell of Confluence.
        scarface74 9y ago
        JSON isn't human editable? The build supports anything - by virtue of the fact that you can run executables, Powershell scripts, batch files, etc.
        sitepodmatt 9y ago
        I believe referring to it should be in the repository along with code, versioned, and sycned with the repository - like travis.yml. I actually think he/she made that pretty clear with the use case of referring to previous commits and previous build steps. Most non clicknext developers will forget the extra step of uploading it in the web ui, and/or won't care to version the microsftvisualstudioteamfoundationservices.json seperately
        scarface74 9y ago
        It's not about "should", it's s preference. I hardly ever need to redo my builds once they are created. Releases on the other hand, I could see a need to change more frequently. If that's your desire, there is nothing stopping you from having one release step that runs a Powershell script, Cake script, etc that is run from your repo.

snuxoll 9y ago

It's a rebranding of Team Foundation Services, tbh. They've done a lot to improve it over the years, but as someone who is forced to work with it daily I'd still take just about anything else - better than it used to be doesn't make it a "good" product by far.

scarface74 9y ago
As a CI/CD tool, what do you feel is missing?
- snuxoll 9y ago
  There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool. Beyond that, the new build tooling isn’t half bad - leaps and bounds ahead of the nasty XML nightmare which is why our team has been moving back to it from out TeamCity deployment. Most of my gripes with VSTS are around the rest of it, everything under “Work” has barely been touched since TFS 2012 - it got a coat of paint but it’s still the same enterprise-grade turd that makes me yearn for JetBrains YouTrack every day. They’ve had adequate git support for a while but the web-based repository browser is such a chore to use that I end up cloning a repository to do a quick search more often than I should need, the admin interface is still a mess to navigate, the list goes on.
  - scarface74 9y ago
    There’s still no way to describe your build as code or configuration in your source repository like travis.yml, Jenkinsfile, etc. which I consider a key feature of a relatively modern CI/CD tool. Your build and deployments are just a JSON file that you can export and import either from the web or the API. The other parts of VSTS are obtuse. But since my chosen workflow is Kanban, it's quite easy to setup a Kanban board with WIP Limits. What I really hate is the Wiki. It supports basic Markdown without all of the bells and whistles of Atlassian but its okay.
    - snuxoll 9y ago
      Being able to quickly export and import build configurations isn’t where the value of having them stored in a human-editable format comes from - your build tooling is part of your project and evolves with it, being able to arbitrarily build any commit regardless of whether your current build pipeline can support it or not is invaluable, as is being able to change the pipeline on a WIP branch while not breaking master. The Wiki is pretty terrible too, but I’ve never found a wiki that makes me go “wow, this is AWESOME” either - dokuwiki got reasonably close though because it gets the hell out of the way and offers just enough formatting without letting me choke on markup like MediaWiki or the WYSINWYG hell of Confluence.
      - scarface74 9y ago
        JSON isn't human editable? The build supports anything - by virtue of the fact that you can run executables, Powershell scripts, batch files, etc.
        sitepodmatt 9y ago
        I believe referring to it should be in the repository along with code, versioned, and sycned with the repository - like travis.yml. I actually think he/she made that pretty clear with the use case of referring to previous commits and previous build steps. Most non clicknext developers will forget the extra step of uploading it in the web ui, and/or won't care to version the microsftvisualstudioteamfoundationservices.json seperately
        scarface74 9y ago
        It's not about "should", it's s preference. I hardly ever need to redo my builds once they are created. Releases on the other hand, I could see a need to change more frequently. If that's your desire, there is nothing stopping you from having one release step that runs a Powershell script, Cake script, etc that is run from your repo.