4 ms·
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 tool
by 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 agoJSON 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 agoI 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 agoIt'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.