Les meilleures pratiques de contrôle d’accès au sein de la communauté des développeurs ne profitent à personne. S’il existe une meilleure façon de déployer du code, nous devrions la partager. Pourquoi? Parce qu’une communauté de développeurs n’est que cela : une communauté. Ce qui profite à une équipe en aidera une autre, en créant des processus plus efficaces, en réduisant les tracas et en améliorant la qualité et les performances des logiciels à tous les niveaux. Nous assistons à une collaboration accrue dans l’espace DevOps, une tendance que nous devrions encourager.
Qu’est-ce que le contrôle d’accès ?
Les développeurs seniors ont appris de nombreuses leçons au cours de leur carrière et beaucoup ont développé des solutions innovantes aux défis du cycle de développement. Dans le passé, ils n’ont peut-être pas partagé ouvertement leur expérience et leurs connaissances ; que ce soit intentionnel ou non, ils contrôlaient essentiellement leurs pratiques.
Pourquoi les développeurs devraient-ils éliminer le contrôle d’accès ?
Lorsque le contrôle d’accès se produit, la prochaine génération doit passer des années à comprendre et à développer ses propres stratégies. Ce n’est pas nécessaire – les connaissances existent déjà avec des développeurs expérimentés. Partager la sagesse élimine les essais et les erreurs. Lorsque tous les membres de l’équipe connaissent les meilleures façons de faire les choses, toute l’équipe peut être plus efficace. Et ils peuvent innover encore plus, en créant de nouvelles stratégies qui aident tout le monde.
Quel est l’avantage de partager les pratiques de déploiement ?
L’avantage concurrentiel d’une entreprise réside dans son logiciel, et non dans son processus de déploiement. Un déploiement rationalisé contribue à un logiciel de qualité supérieure. Cette approche permet aux équipes de développement de passer leur temps à écrire un excellent code et à le valider en production sans le stress lié à la complexité de Kubernetes et au besoin de ressources supplémentaires.
L’activation de ces meilleures pratiques est essentielle car les processus de développement de logiciels deviennent de plus en plus complexes et les équipes innovent constamment pour les améliorer et les simplifier. La multitude d’options d’exécution crée des combinaisons de tâches infinies, et lorsque les équipes travaillent en silos, chacune développera sa propre stratégie. Pourquoi c’est un problème? Les équipes fourniront des logiciels à des rythmes d’innovation différents, ce qui rendra extrêmement difficile la prévision de l’orientation à long terme de l’entreprise. À l’inverse, ordonner le chaos permet des attentes plus précises. Lorsque tout le monde partage ses secrets, cela réduit la complexité car les développeurs ne créent pas de nouvelles solutions à des problèmes qui ont déjà une réponse.
Comment les équipes peuvent-elles partager les meilleures pratiques ?
L’une des façons dont les équipes de développement peuvent normaliser les meilleures pratiques de déploiement consiste à effectuer un déploiement continu. Ce processus s’appuie sur l’intégration et la livraison continues (CI/CD), poussant le code en production et automatisant l’ensemble du processus de publication. Le déploiement continu rend la livraison de logiciels simple, fiable, prévisible et reproductible et élimine la plupart des dépannages liés à la publication de code.
Considérez cet exemple : l’analyse Canary automatisée (livraison de code à des audiences itératives) peut sembler étrangère et sophistiquée aux équipes de développement qui se concentrent sur des tâches de base telles que la livraison de fichiers au serveur. Ces développeurs peuvent être submergés par la perspective de mener une version progressive, mais ils n’ont pas besoin de l’être. Le déploiement continu supprime les étapes manuelles, de sorte que les développeurs et les ingénieurs n’ont pas besoin d’acquérir de nouvelles compétences de déploiement pour profiter des avantages d’un processus de publication efficace, fiable et minimisant les erreurs. Même les équipes pré-élites peuvent utiliser avec succès le déploiement continu pour améliorer la création de logiciels. Les équipes expérimentées comprennent les avantages, mais en raison du contrôle d’accès, cette pratique n’est pas largement utilisée. En tant que communauté de développeurs, nous devons partager ces innovations.
Construisons-nous l’outil nous-mêmes ou utilisons-nous un outil existant ?
Beaucoup d’équipes se demandent : Doit-on construire son propre outil de déploiement ? Bien que l’approche auto-construite puisse sembler rentable, elle crée une vision étroite des tâches et une prise de décision à courte vue. Les équipes se concentrent sur la liste de contrôle rudimentaire plutôt que sur la vue d’ensemble de l’amélioration des mesures de performance.
Oui, la mise à jour est vitale. Mais les équipes doivent également chercher à améliorer la production et la valeur futures en améliorant la fréquence de déploiement, les délais de modification du code, le taux d’échec des modifications et le temps de restauration du service, tout en répondant aux attentes croissantes des utilisateurs. La preuve est dans le pudding : les entreprises avec des taux de publication plus élevés génèrent une croissance des revenus quatre à cinq fois plus élevée que celles qui proposent moins souvent des mises à jour.
Les outils de bricolage n’ont pas l’évolutivité nécessaire pour suivre la complexité croissante des processus, l’élargissement du public et l’augmentation de la demande. Les équipes qui gèrent leurs propres solutions sont souvent distraites de la création de valeur durable pour les utilisateurs. En d’autres termes, le temps consacré à la création et à la maintenance d’outils pourrait être utilisé pour améliorer les logiciels et la vitesse de déploiement.
Au final, adopter une solution existante représente moins de travail que d’en construire une. Quelqu’un a déjà fait l’effort de créer des outils – les équipes devraient sauter sur l’occasion pour sauter ces étapes. Ensuite, les développeurs et les ingénieurs peuvent consacrer leur temps à des activités axées sur la valeur, telles que la création de logiciels. Réinventer la roue ne fournira pas un avantage concurrentiel. Une solution de déploiement continu existante qui maintient le service et les opérations tout en validant automatiquement le code en production optimise le temps et les ressources.
Les équipes créent constamment des moyens d’améliorer les processus et les flux de travail, mais ces solutions ne doivent pas s’arrêter là. Les meilleures pratiques qui font gagner beaucoup de temps et de frustration aux développeurs et aux ingénieurs doivent être diffusées à l’ensemble de la communauté DevOps afin qu’ils puissent créer des méthodes encore meilleures. Le contrôle d’accès inhibe l’innovation. Les solutions supérieures créées en ouvrant les portes de la communication aideront les équipes maintenant et créeront un avenir plus facile et plus productif.