1) If Dev 1 and Dev 2 are working on code that is THAT intertwined, maybe they should be in the same branch. Conversely, if using git, super easy for them to sync with each other without needing to go back to master or a long living dev branch. But really, do what makes sense for you.
2) Wait... absence of unit tests???? Does... not... compute... null pointer... Lol. I get it, a lot of projects have mountains of legacy code. I will just say that if you truly want to move at DevOps speed and still maintain quality, you NEED unit tests. Lots of them. I'm not saying go back and write unit tests for everything, but I am saying moving forward, any new feature or bug fix, WRITE UNIT TESTS.
Ok, had to get that off my chest.
There is nothing stopping you from having a build queueing off of a PR or branch that just deploys to an integration environment, runs automated smoke tests (or manual integration tests) and after it's verified, then the code merges to master. I like triggering this off of a PR for 2 reasons. PR's are another step that really help ensure quality in your code. That's assuming the team takes PR's seriously (which they should) and don't let them stack up and never looking at PR's. Another thing, having a build and automated integration tests run against a PR in a dedicated environment is awesome. The PR won't even pass until the code builds, ALL UNIT TESTS PASS, and the app is deployed successfully and automated smoke tests are run. If you must do manual tests, that's ok too. Sometimes it is necessary to do manual integration tests. But automated REALLY rocks. Faster, not prone to user/tester error etc. And all of this will just be part of a PR. In fact, the team (humans) will never even need to look at a PR until at the very least, the app builds, unit tests pass and automated integration tests pass. cool
3) Feature Flags. At the user story level. And these should be done regardless if you are building and deploying and testing at the PR level. PR seems like a more advanced DevOps technique but again, to be truly successful and move at DevOps speed... I won't go so far as to say it's impossible without feature flags but it is SO MUCH NICER with feature flags. Feature flags are also WAY easier than people think. There are a bunch of tools (some free, so paid) that do a great job with implementing feature flags. Granted, adding feature flags and maintaining feature flags is a tax. It adds complexity and work. But from my point of view, this is a tax worth paying as the benefits seriously out way the pain and complexity of maintaining feature flags.
I could spend 2 hours talking JUST about unit testing and feature flagging but I'll save that for a live talk :)
Self hosted agents at a bare minimum only need the agent. You will also need to install any software you need to do your build or release. If you are doing things that require VS, then you will need to install VS (things like Visual Studio build task).
I am not a licensing person so I have no idea what rules are. Ping me on twitter @abelsquidhead and I can hook you up with some licensing people that can answer this question (I'm pretty sure you do not need another license but again, not a licensing person so don't quote me on that).
I use yo team for existing applications all the time. I use yo team to scaffold everything out, then I stick my source code in the repo and I'm done. Well, i do need to make sure my project is laid out correctly. Or, if you want to, create your build pipeline by hand yourself. Nothing stopping you from doing that.
Hi Shy Agam, we would love to hear all your feedback on what makes the vs team tools feel uncomfortable and what you would love to see in the vs team tools. Tweet or dm @danhellem or me @abelsquidhead on twitter (easiest way to get ahold of me since i'm super slow reading my emails :) )
To go on prem you have to install an agent behind your firewall. The only requirement is that the agent needs to be able to reach out to Azure DevOps (formerly known as VSTS) and the agent needs to be able to reach whatever machine it is deploying to. You can even install the agent on the machine you want to deploy to, but that is not required.
Independent of the tools you end up using, your changes to your DB should sit alongside your code changes so everything gets PR'ed together and versioned together. SSDT uses state/model based to manage db changes. Some other tools, like RedGate uses migrations based (from one version to the next). Either one of these approaches work. I'm kind of a fan of migrations based changes as it gives me finer grained control over how I manage my data from one version change to the next.