You might think about how docker and the "containers paradigm" have contributed to enforce t this kind of recent aproaching between development and IT.
I think is because never like before we have the opportunity to debug the app in a similar context that in production.
I have seen the phenomenon that you describe in one case. The DevOp team did make a lot of stuff with containers in the test and release process but undervaluated the need of setting up some add-ons to the development environment in order to make easier the use of the containers and debug them.
There are some examples in github that make use of a base image that is reused in period or DEV just by adjusting some parameters in docker compose.
As you say, it should be faced from both perspectives, but it should have a responsible DevOp group in charge that take into account all the necessities and not just the release deployments.
Deployment maybe ubiquitous nowadays thanks to containers. The app being developed can be provisioned in every development environment so easily as in prod, and with minimal differences.
That is not only good for new developers that come to the dev team. It is also good so that they can quickly reproduce situations that happen in prod. They're was a time where I could not reproduce some error in proof and it was because some dependency was different in prod. Those times are gone. 😉
The dev image can also include some automation scripts that handle the extra components (like orm operations with the database, running some tests, etc..)
So those kind of advantages are the ones that dev and IT teams can profit from when working together and shaping the DevOp culture that you say.
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.
You might think about how docker and the "containers paradigm" have contributed to enforce t this kind of recent aproaching between development and IT.
I think is because never like before we have the opportunity to debug the app in a similar context that in production.
I have seen the phenomenon that you describe in one case. The DevOp team did make a lot of stuff with containers in the test and release process but undervaluated the need of setting up some add-ons to the development environment in order to make easier the use of the containers and debug them.
There are some examples in github that make use of a base image that is reused in period or DEV just by adjusting some parameters in docker compose.
As you say, it should be faced from both perspectives, but it should have a responsible DevOp group in charge that take into account all the necessities and not just the release deployments.
Deployment maybe ubiquitous nowadays thanks to containers. The app being developed can be provisioned in every development environment so easily as in prod, and with minimal differences.
That is not only good for new developers that come to the dev team. It is also good so that they can quickly reproduce situations that happen in prod. They're was a time where I could not reproduce some error in proof and it was because some dependency was different in prod. Those times are gone. 😉
The dev image can also include some automation scripts that handle the extra components (like orm operations with the database, running some tests, etc..)
So those kind of advantages are the ones that dev and IT teams can profit from when working together and shaping the DevOp culture that you say.