Create templates to quickly answer FAQs or store snippets for re-use.
I think that what you say is what DevOps was intended to be, but to be honest, most developers I met have zero interest in the Ops part and they don't care. So, it kinda morphed into a position for individuals with skills at Ops and Dev trying to get some value from the original idea.
"...most developers I met have zero interest in the Ops part and they don't care..."
This is a tough one. Some do, some don't, some move from Dev To Ops, some Ops move into Dev. IMO, everyone in an organization should care about the product/service the organization exists for. A dev who does not care about the output of their labor is, honestly, not someone I would want to work with. The laissez-faire attitude spreads and the next thing you know no one cares and people start leaving.
This has been my experience as well. It is true that not all developers want to do operations things and it's even more true in the vice versa. However, I believe that is a trend that is going to change and must change if folks want a face paced, quick iterations, and effective CI/CD environment.
I'm with you in the idea that you should care about the complete lifecycle of what you do. The problem is that reality is what it is and in more or less 10 years I have found 3 kinds of attitudes towards Ops from developers:
They don't care as long as the build is green. (most of them)
They have zero interest in Ops but they don't want to depend on other teams and so they learn DevOps to have freedom. (usually, highly skilled developers that pursue feedback as quickly as possible)
They care about Ops and eagerly learn about it. (I have met about 3 or 4)
I kinda get the feeling that DevOps is similar to the organisational transformation or culture that a lot of business management talks about.
Just that we focus on a different term to talk about it in the tech context, we focus on it exclusively to ship software.
This is reinforced further while I was reading some chapters of the DevOps Handbook.
Absolutely agree. The DevOps culture is largely a business transformation but taken from the point of view of developers. DevOps Handbook is a fantastic book to read on this topic.
"...To me, this is missing the entire point of DevOps..." You and me both. I was recently at a client site and over heard a manager use the phrase "...if we are implementing agile devops we need X product...". It made me sad.
Exactly. I did a bit of consulting and this was a very common answer. I have seen how this plays out with Agile and I see folks taking the same approach when it comes to DevOps.
Hey Kyle, I can completely resonate with what you're saying. I think the issue is that while people rush towards developing their skills with new trends, they often neglect to develop their mindset to align with them. In order to build that DevOps culture, it's necessary for organizations to look beyond the technical skills of the development and operations professionals. Otherwise, as you said, there is no meaning as the point of DevOps is completely missed. I would like to know your views on this blog here that explains what it takes for organizations to match their pace with DevOps. Check it out here - cigniti.com/blog/key-aspects-to-co...
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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.