Absolument pas et c'est précisément le but des pratiques devops, le but c'est de livrer le plus souvent possible pour minimiser le delta entre 2 livrables et donc les possibilités d'erreurs.Envoyé par micka132
La taille de la structure n'a aucun rapport avec la fréquence de livraison.
En revanche la taille de la structure peut avoir un rapport avec le montant de l'investissement attribué aux devops pour aboutir à la réduction de TTM voulue.
Je veux dire, le but de tout ça c'est de réduire le Time To Market, ça veut dire que la matin tu peux avoir un chef dans ton bureau qui te dise je veux ça, il se trouve que ce qu'il veut prend 2h à faire, du coup tu peux le livrer dans la journée, c'est même le but. Aucun rapport avec la taille de la structure.
Non du tout. Le waterfall c'est une manière de développer des logiciels. Il y a une forte adhérence entre la nature du waterfall et la contractualisation du service de développement vendu. En d'autres termes cette méthode répond d'abord à des impératifs commerciaux avant de répondre à des impératifs techniques, et c'est en grande partie pour cette raison qu'elle ne fait pas face à l'épreuve du réel avec le même succès que les méthodes agiles par exemple.
Mouai ... Le manifeste agile c'est une quinzaine de geeks de 40 piges qui voulaient trouver une meilleure manière d'écrire du logiciel (ptet même sur leur temps libre ça m'étonnerait même pas !). C'est absolument pas venu "top to bottom" du management ou d'une direction d'entreprise. Les managers et les chefs d'entreprises sont dans leur extrême majorité des suiveurs sur ces sujets qu'ils ne maitrisent et ne comprennent absolument pas.
Il n'y a aucun lien entre la taille de la structure et l'investissement réalisé dans le tooling autour des développements et de l'opérationnel. Cela dépend du montant investi par ceux qui tiennent les cordons de la bourse. Forcément dans une grosse boite ça va couter beaucoup plus cher que dans une petite. Mais une petite boite a tout intérêt à investir lourdement dans le tooling afin de maximiser la productivité de ses employés.
C'est comme le fait d'écrire ou pas des tests unitaires. Écrire des TU ça coute du temps à très court terme, ça fait gagner 10x le temps investi à court terme sur les moyens et longs termes.
La plupart du temps le dev d'une petite boite il gère comme il peut, et comme il est pas omniscient et que devops c'est une métier à part entière il gère comme il peut et il fait probablement très mal ce qu'un devops spécialisé ferait 100x mieux.
Ou alors il passe 3 mois à monter le tooling auquel cas il a acquis des compétences de devops mais il n'a pas développé du fonctionnel pour ses clients pendant ce temps.
Je pense que je suis en total désaccord avec toi !
Le tooling ça coute une blinde, et c'est pas demain la veille que tout le monde sera devops. Dev d'application et devops c'est pas du tout le même métier, ça ne nécessite pas les mêmes compétences etc ...
Ben c'est ça la compétence, c'est la maitrise des outils + la compréhension des concepts sous-jacents. C'est comme si tu me disais que la POO c'est pas une compétence c'est juste suivre un paradigme de programmation.
Il y a de très nombreuses contraintes qui s'imposent aux développeurs d'applications du fait de l'existence du tooling de devops dans leur environnement.
Le code doit être testable, le code doit être testé, le code doit généralement obéir à de nombreux critères qualités établis automatiquement par divers outils (Sonar, linters, ...), le VCS et la manière de l'utiliser est déterminant dans la capacité à pouvoir livrer n'importe quand, etc ...
Je vais même te dire mieux, il y a des devs d'applications qui ont la compétence pour travailler dans un contexte contenant des devops, et d'autres non.
Répondre avec citation
.
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : 
Partager