I have been managing team servers for a while, in most of the cases, a server was required to:
1. Running experiments, like trying tools before committing to integrating them in our project.
2. Run a tool that would simplify local development setup, in most cases, running a backend or a database.
3. Try a preview from our applications in a cloud environment.
For the 1st case a single shared server for experiments has worked fine, I guess this would depend on each team.
For the 2nd case, we'd usually create a server specific for the tool and share the access with devs requiring it.
For the 3rd case, it got a bit more complicated because there are times where many devs what to push a preview, requiring coordination between devs which is tedious and error-prone. At the end, we took your route and we ended up building our own service to provide fullstack preview environments automatically when pushing code to our repository, so far, it has removed the need to share servers with devs for most scenarios.
Comments
I have been managing team servers for a while, in most of the cases, a server was required to:
1. Running experiments, like trying tools before committing to integrating them in our project.
2. Run a tool that would simplify local development setup, in most cases, running a backend or a database.
3. Try a preview from our applications in a cloud environment.
For the 1st case a single shared server for experiments has worked fine, I guess this would depend on each team.
For the 2nd case, we'd usually create a server specific for the tool and share the access with devs requiring it.
For the 3rd case, it got a bit more complicated because there are times where many devs what to push a preview, requiring coordination between devs which is tedious and error-prone. At the end, we took your route and we ended up building our own service to provide fullstack preview environments automatically when pushing code to our repository, so far, it has removed the need to share servers with devs for most scenarios.