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

26

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?

Evgeny
la source

Réponses:

32

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.

Alexandre
la source
1
En effet, DevOps peut être appliqué à pratiquement n'importe quelle organisation de développement sw, même pour les grands produits intégrés avec seulement une poignée de versions publiques par an - en utilisant la livraison continue dans leur pipeline de développement, ils peuvent toujours bénéficier de certains avantages DevOps: meilleure qualité, réduction des coûts, prévisibilité des versions, etc.
Dan Cornilescu
La réponse rappelle un SaaS, n'explique pas vraiment bien comment un produit ou service non SaaS peut bénéficier de ces pratiques.
Evgeny
Les produits sur lesquels je travaillais n'étaient pas du SaaS (bien au contraire). Mais la logique reste la même, peu importe que vous soyez SaaS ou non, les DevOps essaient d'améliorer le produit de manière non traditionnelle. Je ne pouvais rien savoir de notre modèle de tarification ou de notre offre, cela ne ferait pas tant de différence.
Alexandre
13

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.

Tortue
la source
Pouvez-vous expliquer pourquoi et pourquoi cela est important? Les clients se soucient-ils réellement de votre pipeline, ou simplement du projet fini à la date promise et au prix qu'ils doivent payer? Pourriez-vous réduire les coûts en ne faisant pas toutes ces choses "devops-y"? Pourriez-vous obtenir plus d'heures dans un projet sans faire ces choses et obtenir plus d'argent pour les projets (car c'est plus long)?
Evgeny
1
@Evgeny DevOps aide à terminer le projet dans les délais et le budget pour les raisons expliquées dans ma réponse. En réduisant DevOps, vous réduiriez également les avantages que j'ai expliqués. La construction et les tests permettent souvent de respecter le budget et les délais. Trouver un bug plus tard coûte plus d'argent et prend plus de temps à corriger, il a été prouvé à maintes reprises. Le client ne se soucie pas du pipeline, mais plus vous attendez ses commentaires, plus la réécriture sera coûteuse et longue.
Alexandre
N'est-ce pas juste Agile Software Dev?
Evgeny
@Evgeny J'ai mis à jour ma réponse pour clarifier. Nous utilisons Agile, mais cela ne signifie pas que nous ne pouvons pas avoir une mentalité DevOps ..
Turtle
1
@Evgeny, vous pourriez probablement en économiser en ne mettant pas à jour vos tests unitaires et vos tests d'acceptation, mais cela accumule de la dette technique qui est un anti-modèle DevOps. Vous pourriez vous en tirer pendant quelques semaines ou mois, mais vous vous retrouverez bientôt (probablement) avec un gâchis difficile à entretenir qui est impossible à tester.
Steve Button
3

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.

Toby Speight
la source
L'automatisation n'est pas devops. Mêmes commentaires que la réponse de David Bock ci-dessous finalement (désolé, mon commentaire a été perdu au moment où j'ai rétrogradé, je l'ai juste remarqué)
Tensibai
3

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.

Quarind
la source
0

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.

David Bock
la source
Ceci est lié à l'automatisation, mais pas à une organisation de devops en aucune façon, je ne vois aucune référence à l'équipe de discipline de plury n'importe où, juste des opérations automatisant les choses dont elles héritent
Tensibai
C'était en 2001 ... bien avant que DevOps ne soit une chose. Ce n'était pas seulement de l'automatisation, je pense que cela a rationalisé la gestion du projet exactement de la même manière qui a fini par devenir la «culture» de DevOps. En tant que tel, il s'agit d'un exemple d'attitude DevOps en dehors d'une organisation SaaS.
David Bock
DevOps n'est pas une question d'automatisation ni de gestion de projet. Il s'agit de briser l'organisation basée sur un silo à la racine. Je suis désolé, je ne pense pas que cette réponse se rapporte vraiment à la question (cela ne signifie pas qu'elle est inintéressante, mais tout simplement pas au bon endroit OMI, et je ne vois pas où elle pourrait être en place en fait, peut venir plus tard)
Tensibai
Je vais essayer une fois de plus de clarifier - en ayant le CD coupé de manière si cohérente et rapide, nous pourrions obtenir des commentaires de QA beaucoup plus rapidement qu'auparavant. Cela a réduit un silo. Cela ne l'a pas éliminé, car il a fallu un an ou deux avant que nous désactivions les fiefs autour des budgets centralisés pour les activités, mais c'était certainement une étape critique pour que cela se produise. Nous savions également beaucoup plus tôt quand le processus de sortie a été interrompu. J'attribue beaucoup de petites choses comme celle-ci à mon cheminement personnel vers DevOps.
David Bock
Ce dernier commentaire donne plus de sens à cette réponse sous cette question, vous devez le modifier pour l'inclure, je pense toujours que cela ne correspond pas à ce format, mais il semble que ma position soit erronée lorsque j'observe l'évolution globale de cette bêta privée, donc ... c'est à toi de voir. Je ne peux pas supprimer mon downvote sans une modification pour plus d'informations
Tensibai