> Engineers should be able to deploy with minimal manual steps and it should be easy to see if the deploy is successful
We took this a step further. Our developers are actually disallowed from running builds & deploying the software to QA or customer environments. We built a tool that exposes all of this through a web dashboard that our project managers use. Building and deploying our software to a customer's production environment requires ~20 seconds of interaction in this web tool and then the process completes automatically.
This works out so much better for us because project managers can have total control over what gets included in each build and handle all coordination with each customer. The direct ownership of issue status labels + build/deploy gives comprehensive control over all inbound+deliverable concerns.
We also have feature flags that we use to decouple concerns like "this build has to wait because of experimental feature XYZ". Developers communicate feature flags up to the project team in relevant issues so that they understand how to control that functionality if it goes out in a build. Effectively, we never merge code to master that would break production. If its something deemed risky, we put a FF around it just in case.
Note that feature flags can also be a huge PITA if you keep them around too long. Clean these up as soon as humanly possible.
Seems super annoying, so I develop something and I can't even test what I've done because it's impossible to deploy to a QA environment?
Wouldn't want to work there. Worst case scenario I leave. Best case scenario I become totally disinvested in the project/company because I can't work anyway so why care about anything? Take the salary and do as little as possible, bet every project is de facto late anyway.
By the way, what happens when the manager is away for a day or on holiday? Nobody can deploy anything?
I take a more charitable approach in job interviews than in HN messages :)
I consider unlimited free access to a QA environment a requirement to develop (critical) software. Local development does not reflect the production environment. Testing/Mocking is not representative of a real database or any dependency the software relies on.
Do you have QA people to test the software integration in QA or is it the developer/manager who's expected to QA after the release?
We took this a step further. Our developers are actually disallowed from running builds & deploying the software to QA or customer environments. We built a tool that exposes all of this through a web dashboard that our project managers use. Building and deploying our software to a customer's production environment requires ~20 seconds of interaction in this web tool and then the process completes automatically.
This works out so much better for us because project managers can have total control over what gets included in each build and handle all coordination with each customer. The direct ownership of issue status labels + build/deploy gives comprehensive control over all inbound+deliverable concerns.
We also have feature flags that we use to decouple concerns like "this build has to wait because of experimental feature XYZ". Developers communicate feature flags up to the project team in relevant issues so that they understand how to control that functionality if it goes out in a build. Effectively, we never merge code to master that would break production. If its something deemed risky, we put a FF around it just in case.
Note that feature flags can also be a huge PITA if you keep them around too long. Clean these up as soon as humanly possible.