Totally agree that you shouldn't be rushing things when tackling CI/CD for the first time. Taking the time to understand the current deployment process (manual documentation, automated scripts, etc) and seeing how an automated pipeline can help is vital.
I like them both, but they have one challenge in common; the sheer amount of potential configurations.
I'm curious as to why this is seen as a negative. If a CI/CD provider doesn't provide a breadth of configuration possibilities then the scope is limited in terms of what can be achieved by that pipeline. I know that I'm not put off by the sheer bulk of possibilities provided by Azure DevOps. There's always a search/filter functionality to identify the tool for your current requirement.
In terms of deploying straight to prod, I'm not sure how many operate in this way. I'd certainly not be using this flow in anything vital that I work with. For me there's always been a benefit of having the dev -> stg -> prod deployment steps. Especially for those new to CI/CD, without the safety net of testing on at least one environment other than prod, it would be a fairly stressful process. Maybe once you've been using CI/CD for a period of time, you've got confidence in the repetitive and consistent process, that you'd be comfortable in deploying straight to prod and applying the patch strategy.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Totally agree that you shouldn't be rushing things when tackling CI/CD for the first time. Taking the time to understand the current deployment process (manual documentation, automated scripts, etc) and seeing how an automated pipeline can help is vital.
I'm curious as to why this is seen as a negative. If a CI/CD provider doesn't provide a breadth of configuration possibilities then the scope is limited in terms of what can be achieved by that pipeline. I know that I'm not put off by the sheer bulk of possibilities provided by Azure DevOps. There's always a search/filter functionality to identify the tool for your current requirement.
In terms of deploying straight to prod, I'm not sure how many operate in this way. I'd certainly not be using this flow in anything vital that I work with. For me there's always been a benefit of having the dev -> stg -> prod deployment steps. Especially for those new to CI/CD, without the safety net of testing on at least one environment other than prod, it would be a fairly stressful process. Maybe once you've been using CI/CD for a period of time, you've got confidence in the repetitive and consistent process, that you'd be comfortable in deploying straight to prod and applying the patch strategy.