Réponses:
Le but de DevOps est que le développement ne doit pas s'opposer aux opérations, mais plutôt se soutenir mutuellement.
Traditionnellement, en raison des déploiements en cascade et des mises à jour à grande échelle, le développement causait aux opérations une variété de problèmes lors du déploiement en raison de tests inadéquats, de la modification des environnements de serveur, la liste s'allonge encore et encore. Essentiellement, les mises à jour étaient trop importantes pour que l'équipe des opérations puisse les déployer efficacement sans que des problèmes ne surviennent au cours du processus. Ces problèmes pourraient expliquer pourquoi vous pensez que le développement s'oppose aux opérations .
D'un autre côté, DevOps travaille à réduire la taille des mises à jour, à diminuer les environnements rigides et à améliorer généralement le transfert de l'application entre le développement et les opérations en augmentant le nombre de fois où le transfert se produit chaque année. L'augmentation du nombre de déploiements entraîne moins de maux de tête pour les opérations, car ils ont automatisé une grande quantité de travail nécessaire pour mettre à jour les produits ou mieux anticiper et préparer les mises à jour.
Tldr: DevOps vise à annuler la théorie selon laquelle le développement s'oppose aux opérations en créant un état d'esprit où les opérations et le développement travaillent ensemble pour déployer fréquemment des produits de manière opportune et facilement reproductible.
Je pense que vous avez déjà reçu des réponses complètes, mais vous avez dit que votre anglais n'est pas excellent, alors je vais essayer de fournir une réponse très brève et compréhensible:
Ces deux choses sont en conflit. Cela dit, le développement et les opérations ne doivent pas s’opposer. Ils devraient travailler ensemble pour s'assurer que les deux objectifs peuvent être atteints. C'est le but de DevOps.
La tension entre le développement et les opérations est souvent causée par un mauvais alignement des incitations et des tentatives d'optimisation au sein de l'équipe.
Les développeurs sont souvent jugés par la vitesse et la quantité de problèmes qu'ils peuvent résoudre et fusionnés dans le référentiel de code et leur récompense n'est souvent pas liée au fait que le code fonctionne ou fonctionne correctement. Beaucoup moins d'évolutivité, de performances et d'autres facteurs.
Les opérations sont souvent jugées sur la stabilité de l'environnement et la qualité du fonctionnement du code en production, mais rarement sur la qualité du processus permettant d'apporter rapidement des changements.
Cela crée le problème où les développeurs sont incités à créer beaucoup de code et à le jeter par-dessus le mur à l'équipe des opérations et l'équipe des opérations est incitée à accepter le moins de changements possible pour assurer la stabilité de l'environnement.
DevOps est en quelque sorte l'ensemble de solutions à ce problème:
La plupart des organisations gèrent la complexité en décomposant leur organisation en parties fonctionnelles et en exigeant que chaque partie comprenne comment s'améliorer. C'est ce qu'on appelle souvent l'approche du «silo».
Il est important de comprendre pourquoi cette approche en silo bloque le succès de l'entreprise et échoue souvent à améliorer l'organisation dans son ensemble. Et cela n'affecte pas uniquement le développement et les opérations - il affecte tous les autres silos fonctionnels au sein d'une grande organisation tels que l'équipe d'assurance qualité, les finances, la gestion des produits et des projets.
Comme les gestionnaires de chaque silo fonctionnel doivent s'améliorer en réduisant les coûts ou en augmentant la vitesse, leur réaction est souvent:
Avec ces réactions typiques, tout cadre qui lance un effort d'amélioration mineur est rarement accueilli avec enthousiasme. Les gestionnaires se retrouvent en concurrence féroce avec d'autres domaines fonctionnels sur les ressources nécessaires pour exécuter leurs améliorations. Donc, pas étonnant que la commande pour améliorer intensifie les batailles interfonctionnelles!
Même lorsqu'un manager achève sa partie d'un projet d'amélioration, il rencontre alors d'autres domaines fonctionnels et d'autres organisations (fournisseurs, entrepreneurs, etc ...) qui n'ont pas fait leur travail. Cela diminue ou annule totalement les résultats.
Cette tension interfonctionnelle ne se limite pas aux efforts d'amélioration. Elle est au cœur même de la prise de décision quotidienne et du jugement sur l'efficacité de la gestion dans une organisation. Voici un exemple concret:
Un directeur financier a été invité à "s'améliorer". Il a décidé de bloquer l'embauche d'entrepreneurs qui coûtaient plus cher que le prix nominal accepté sur le marché. Il a mis en œuvre la nouvelle politique et a déclaré avoir économisé 1 million de dollars cette année. Les développeurs et les services informatiques ne pouvant pas embaucher des sous-traitants pour les aider à utiliser les conteneurs et l'orchestration de conteneurs, car ces sous-traitants sont chers. Le directeur des opérations informatiques de la même entreprise a calculé que le fait de ne pas améliorer son infrastructure coûtait à l'entreprise bien plus de 100 000 $ de dépenses supplémentaires chaque mois. À ce rythme, les économies annuelles liées à l'embauche d'entrepreneurs ont été rongées avant la fin de l'année.
Vous pouvez imaginer que la relation entre ces deux domaines fonctionnels n'était pas exactement lovey-dovey.
Ces conflits interfonctionnels sont motivés par l'approche en silo, où l'organisation mesure chaque silo en amélioration de manière indépendante. Si vous êtes un centre de coûts, l'amélioration signifie naturellement une plus grande efficacité ou une réduction des coûts au sein de votre silo.
Dans ce cadre de référence, les coûts sont considérés comme obéissant à la règle "additive". Les coûts de chaque silo additionnés sont égaux au coût total de l'organisation. Par conséquent, les gestionnaires considèrent que toute réduction des coûts dans leur domaine est «bonne», car ils voient une traduction directe en économies pour l'entreprise dans son ensemble. Dans ce cadre de référence, les efforts d'amélioration sont répartis partout pour attaquer les coûts et les gaspillages dans toute l'organisation.
Un excellent exemple lorsque les équipes de développement commencent à travailler Agile et à pousser le code vers le contrôle qualité et les opérations toutes les deux semaines au lieu de chaque trimestre comme elles le faisaient auparavant. Le contrôle qualité et les opérations ne sont pas prêts pour un tel changement et sont blâmés pour avoir ralenti. Encore une fois, cela ne contribue pas beaucoup à l'amour entre les gens dans le développement et les opérations.