Salut,
J’aurais une approche plus haut niveau du DevOps, qui de base est la contraction des mots Developments et Operations, donc de 2 étapes, et non pas de 2 métiers. Par conséquent, le but étant de rapprocher 2 étapes dans la conception d’un produit, de la réflexion de celui-ci jusqu’à sa production, et que peux importe dans laquel tu agis, tu es inclus du plus tôt possible, au plus tard possible.
Sachant cela, nous pourrions donc appliquer la culture DevOps à tout métier, même hors tech en fait. En informatique, on aime bien comparé à l’automobile, et on pourrais très bien utiliser cette culture. Nous avons les bureau R&D (Developments), qui pensent la voiture, et ensuite nous avons les chaines de production (Operations), qui la construise. Le but c’est que le gars en fin de chaine, ai pu se préparer, POCé, comprendre ce qu’il fera le plus tôt possible afin de pouvoir sécurisé sa partie au mieux. Mais également la R&D va devoir suivre tout ce qui se passe jusqu’au montage de la dernière pièce. Après nous avons l’itération, car nous avons un client final qui remontera des problèmes, qu’il faudra corrigé pour la prochaine série, et on recommence la boucle.
Tout ça pour dire, que tu peux avoir une culture DevOps sans développeur, car tu as même dans ta partie qui sera automatisation, tu as la partie Development, la partie Operation. Sauf dans le cas où toi tu crée l’automatisation, et que c’est une autre équipe qui clique sur le bouton sans vraiment savoir ce qu’ils font, car là tu n’aurais pas de relation entre le Development et l’**Operation".
ça reste ma vision et ma compréhension de la culture DevOps.