DevOps est-il réservé aux entreprises proposant des produits SaaS?

Les pratiques décrivant DevOps, telles que la livraison continue, l'automatisation, etc. sont pertinentes pour les produits qui fournissent un service continu, tels que les produits SaaS.

Par exemple, une entreprise de développement de logiciels qui réalise principalement des projets pour d'autres clients pourrait ne jamais les gérer une fois le projet terminé. Et les projets clients ne sont pas partagés avec d'autres clients, car non pertinents.

DevOps s'applique-t-il même aux entreprises qui développent plusieurs projets ponctuels? Quelles pratiques DevOps s'appliquent dans ce cas, le cas échéant?

Absolument pas!

DevOps consiste à briser les silos (départements) traditionnels afin d'être plus efficace.

Une meilleure communication entre les équipes, une visibilité améliorée et un processus fiable et automatisé sont des moyens d'obtenir un meilleur produit.

Je travaillais pour une grande entreprise de médias où nous soutenions un outil interne et développions des sites Web destinés au public.

Les avantages de DevOps dans notre cas étaient les suivants:

• Grâce à la construction continue, nous informons l'équipe de développement plus tôt que tard s'il y a des problèmes d'intégration ou de génération avec leur code. Ils peuvent résoudre les problèmes alors que leur esprit est toujours sur le morceau de code qu'ils viennent de commettre.
• Grâce à des tests et à une livraison continus (dans le cadre de l'assurance qualité), nous avons permis à l'équipe AQ ​​de détecter les problèmes plus tôt et de les signaler plus tôt. Cela a réduit le temps nécessaire à la recherche et à la correction des bogues ainsi que la complexité de ces investigations.
• Avec nos outils de collecte et d'agrégation de journaux, nous avons donné aux développeurs l'accès à quelque chose qu'ils ne regardaient pas habituellement (ils étaient très intéressés par les débogueurs :) - comprendre comment les journaux sont vus et utilisés par d'autres équipes a amélioré la qualité globale des journaux
• Nous avons souvent partagé des informations et créé de la documentation pour partager les connaissances entre les équipes, en essayant de briser les murs. En comprenant les besoins des Ops, nous créons quelques guides pour ce qui doit toujours être gardé à l'esprit lors du démarrage d'une application (où / comment gérer les propriétés, etc.). En comprenant la réalité du développeur (codez plus de fonctionnalités, plus vite, gogogogo!), Nous avons pu faire en sorte que les opérateurs créent des serveurs et des clusters mieux adaptés aux besoins du développeur.
• La qualité globale des déploiements a également été considérablement améliorée. Les déploiements ont été pris en charge par notre équipe, nous avions donc une visibilité parfaite sur les opérations et les développeurs. Cela a éliminé de nombreux problèmes liés au "transfert de code" où le développeur remettait un package et un document d'une page aux opérateurs disant "Installer ceci!".

Dans l'ensemble, je dirais que peu importe si vous mettez à jour votre environnement de production une fois par jour ou une fois par mois et quel que soit le nombre de clients que vous avez ou votre modèle d'entreprise, chaque entreprise peut utiliser une meilleure communication, de meilleurs outils, une meilleure visibilité, une rétroaction plus rapide, etc.

Mon équipe et moi sommes responsables du développement des "one-offs", des produits qui une fois finis sont remis au client pour l'entretien ou dans certains cas gérés par nous moyennant des frais.

Nous devons encore maintenir un pipeline de développement solide pour gérer les commentaires constants de nos clients afin de nous assurer que nous leur expédions quelque chose de fiable et éprouvé pour fonctionner.

Bien que le client ne se soucie pas de DevOps (dans la plupart des cas), cela nous est toujours utile. Avec DevOps, nous pouvons rapidement pousser de nouvelles versions, afin que les clients puissent voir les commentaires en quelques minutes et non en quelques heures, et nous sommes également en mesure de détecter toute erreur / bogue avec nos tests via Jenkins / Travis.

Pour garantir que nos stratégies de déploiement sont les mêmes pour tous les projets, nous nous concentrons sur la conteneurisation de nos applications. En utilisant Docker, nous pouvons facilement transmettre l'application à nos clients.

Le coût économisé par DevOps est difficile à déterminer. Nous avons des coûts supplémentaires sous la forme de logiciels que nous choisissons d'utiliser pour le pipeline (Travis, Jenkins, Puppet, etc.), mais nous économisons également du temps et de l'argent en corrigeant des bogues / en donnant rapidement aux clients des commentaires. Notre temps de réponse rapide maintient nos clients satisfaits, ce qui maintient nos portefeuilles heureux.

J'ai travaillé pour des entreprises produisant des logiciels en tant que produits sous film rétractable, en tant que déploiements entièrement installés et pris en charge et en tant que code intégré dans les appareils. Dans toutes ces entreprises, DevOps fournit un support essentiel au développement:

• Constructions de logiciels automatisées et reproductibles, avec des configurations connues et contrôlées de compilateurs, de bibliothèques et d'autres outils de construction.
• Tests système automatisés et reproductibles pour les tests de régression et pour les nouveaux tests de fonctionnalité.
• Autres actions automatisées et régulières (par exemple, des exemples de captures d'écran mises à jour en permanence disponibles dans toutes les langues prises en charge, à vérifier par les traducteurs et à intégrer par les auteurs techniques dans les manuels d'utilisation).

Dans tous les cas, ce sont des choses que les développeurs individuels pourraient faire ponctuellement, mais ce ne serait pas une bonne utilisation du temps du développeur, ni la même assurance de contrôle de configuration que les versions automatisées.

Les activités de développement et de mise en œuvre de logiciels ne nécessitaient pas auparavant une profonde intégration entre les départements. Mais pour aujourd'hui, il est nécessaire de coopérer étroitement avec tous les services (développement, opérations informatiques, assurance qualité, etc.).

Pour les développeurs, le changement est ce pour quoi ils sont payés. Les entreprises ont toujours besoin de changements pour s'adapter au monde moderne. Cette compréhension pousse les développeurs à produire le maximum de modifications possibles. Les informaticiens ont une compréhension différente, dans laquelle le changement est néfaste. Chacun pense que cela fonctionne correctement et profite à l'entreprise. En effet, si nous les considérons séparément, ils ont tous les deux raison.

Tous les employés doivent comprendre qu'ils font partie d'un même processus. DevOps cultive la réflexion, ce qui permet de réaliser que les décisions et actions personnelles de chacun doivent être orientées vers la réalisation d'un objectif unique. Et le succès doit être mesuré par rapport à l'ensemble du cycle de développement à la livraison, et non à partir du succès des rôles individuels. Grâce à une coopération étroite entre les développeurs et les spécialistes de la maintenance, une nouvelle génération d'ingénieurs est formée, qui tire les meilleures réalisations des deux disciplines et les combine au profit de l'utilisateur. Cela se manifeste par l'apparition d'équipes interfonctionnelles ayant une expérience en développement, gestion de configuration, gestion de base de données, tests et gestion d'infrastructure.

La méthodologie n'est donc pas seulement utile en SaaS.

Pas du tout. Bien qu'il existe déjà d'excellents exemples sur ce sujet, je voudrais partager une anecdote à moi. En 2001, j'ai hérité d'un projet logiciel avec une version qui impliquait la création d'un CD. La documentation du processus de publication comprenait 40 (!) Étapes documentées par un ingénieur précédent, qui comprenaient des instructions manuscrites ridicules comme "ouvrez ce fichier de configuration et changez le nom du fichier .jar à la ligne 41 pour inclure le numéro de version de la nouvelle version ".

Nous avons agressivement automatisé chaque étape de ce processus de construction, en remplaçant les instructions manuscrites comme celle-ci par des choses comme «patch» scriptées avec bash. Nous avons même dû ouvrir des tickets avec notre fournisseur d'outils d'installation tiers pour rendre leurs fichiers de projet patchables.

Une fois ce processus automatisé, nous avons acheté un «CD Jukebox». Chaque nuit après la réussite des tests, la machine de création créait automatiquement un nouveau CD d'installation. Nos testeurs pouvaient venir le lendemain matin, saisir un disque et s'assurer que tout était installable.

Nous avons certainement des boucles de rétroaction plus serrées lorsque nous pouvons déployer un logiciel en tant que service, mais les principes fondamentaux de l'automatisation, du retour d'informations, du temps de cycle, des petites versions, etc. s'appliquent tous.