Discussion :

[Bill Fassinou]

Les conteneurs du DevOps pr�sentent-ils des risques pour la s�curit� de vos donn�es ?
Oui, selon une �tude

� l�heure o� la m�thode de travail DevOps semble gagner toutes les entreprises technologiques, de nombreux professionnels ont commenc� � s�inqui�ter sur la s�curit� des conteneurs souvent pr�f�r�s pour leur flexibilit� et leur agilit�. L�un des �l�ments cl�s dans la mise en �uvre du DevOps est la technologie des conteneurs. Les conteneurs sont de plus en plus mis en �uvre par les entreprises. Le DevOps est un mouvement en ing�nierie informatique et une pratique technique visant � l'unification du d�veloppement logiciel (dev) et de l'administration des infrastructures informatiques (ops), notamment, l�administration syst�me.

Apparu courant de 2010, le mouvement DevOps se caract�rise principalement par la promotion de l�automation et du suivi (monitoring) de toutes les �tapes de la cr�ation d'un logiciel, depuis le d�veloppement, l'int�gration, les tests, la livraison jusqu'au d�ploiement, l'exploitation et la maintenance des infrastructures. Les principes DevOps soutiennent des cycles de d�veloppement plus courts, une augmentation de la fr�quence des d�ploiements et des livraisons continues pour une meilleure atteinte des objectifs �conomiques de l'entreprise. La virtualisation � base de conteneurs est une m�thode de virtualisation dans laquelle la couche de virtualisation s'ex�cute au sein m�me du syst�me d�exploitation.

Dans cette approche, le noyau du syst�me d'exploitation h�te ex�cute directement plusieurs machines virtuelles invit�es et autonomes sans passer par une couche logicielle suppl�mentaire. Ces machines invit�es s'appellent des conteneurs. Les conteneurs permettent donc de s'affranchir des hyperviseurs et de la gestion qui d�coule de l'ex�cution sur chaque machine virtuelle d'un syst�me d�exploitation invit�. Cette approche permet d'am�liorer les performances, puisqu'un seul et unique syst�me d'exploitation (l'h�te) se charge des appels mat�riels. Elle permet �galement d'h�berger sur un serveur beaucoup plus d'instances virtualis�es que la virtualisation traditionnelle.

Cette technologie est depuis quelques ann�es tr�s utilis�e par de grandes firmes telles que Google, BlaBlacar, etc. L�un des plus connus de ces conteneurs est Docker (il s'agit d'un conteneur Linux). Cette fa�on de faire est tr�s r�pandue aujourd�hui dans le monde technologique. Mais la technologie des conteneurs garantit-elle une s�curit� optimale pour les ressources des entreprises ?

Une r�cente �tude de Tripwire, une agence de cybers�curit�, r�v�le que 60 % des entreprises ont subi un incident li� � la s�curit� des conteneurs en 2018. Les r�sultats de l��tude publi�s le 7 janvier dernier indiquent que les entreprises qui ont adopt� le DevOps feront certainement face � des d�fis importants et des risques li�s � la s�curit� de leurs conteneurs. Pour Tripwire, si ces entreprises veulent minimiser les risques et leur exposition aux menaces num�riques, elles devront penser � des solutions imm�diates pour s�curiser leurs conteneurs.

Tripwire a proc�d� � l�interrogation d�environ 311 professionnels de la s�curit� informatique qui g�rent des environnements avec des conteneurs dans beaucoup d�entreprises et les r�ponses �taient pour la plupart inqui�tantes. D�abord, 60 % ont confirm� avoir subi quelques probl�mes concernant la s�curisation et le d�ploiement de leurs conteneurs. L��tude de Tripwire fait ressortir que pour la majorit� des entreprises dont il est question, plus le nombre de conteneurs en production augmente, plus les risques de s�curit� augmentent.

� 86 % des organisations interrog�es avaient des conteneurs en production au moment de l'�tude. Plus il y avait de conteneurs dans la production, plus il �tait probable qu'ils subissent un incident li� � la s�curit� des conteneurs. Parmi les entreprises comptant plus de 100 conteneurs en production, 75% avaient subi un incident li� � la s�curit�. Il n�est donc pas �tonnant que 94% des r�pondants se disent pr�occup�s par la s�curit� des conteneurs. Soixante et onze pour cent des personnes allaient jusqu'� pr�dire que le nombre d'incidents li�s � la s�curit� des conteneurs augmenterait au cours de la prochaine cette ann�e �, indique Tripwire.

Selon Tripwire, si de tels risques planent sur les installations de ces entreprises, cela peut �tre la cons�quence directe de leur manque d�exp�rience ou leur immaturit� dans la mise en �uvre du DevOps. L��tude rapporte � ce sujet que beaucoup d�entreprises dans le lot tra�nent encore des lacunes dans leurs strat�gies actuelles pour s�curiser leurs conteneurs. Par exemple, lit-on dans le rapport, � peine 12 % des r�pondants au sondage ont d�clar� pouvoir d�tecter un conteneur compromis en quelques minutes. Quarante-cinq pour cent des participants au sondage ont d�clar� que cela prendrait des heures, alors que certains estimaient que cela prendrait encore plus longtemps. Dans le m�me temps, pr�s de la moiti� (47 %) des professionnels de la s�curit� informatique ont d�clar� que leurs entreprises fabriquaient des conteneurs vuln�rables, tandis que presque le m�me nombre (46 %) ont d�clar� ne pas savoir avec certitude si c'�tait le cas.

Bon nombre de ces entreprises limitent pour ce fait leurs d�ploiements de DevOps pour parer certains risques de s�curit�, indiquent les r�sultats de l��tude. Elles veulent toutes pouvoir acqu�rir de nouveaux environnements offrant bien plus de s�curit�. � Avec la croissance et l'adoption de conteneurs, les entreprises sentent la pression pour acc�l�rer leur d�ploiement. Pour faire face � la demande, les �quipes acceptent les risques en ne s�curisant pas les conteneurs. Sur la base de cette �tude, nous pouvons constater que le r�sultat est que la majorit� des organisations sont confront�es � des incidents de s�curit� des conteneurs �, a expliqu� Tim Erlin, vice-pr�sident charg� de la gestion des produits et de la strat�gie chez Tripwire.

Source : Tripwire

Et vous ?

Disposez-vous d�un d�ploiement de conteneurs pour votre entreprise ? Comment assurez-vous leurs s�curit�s ?

Voir aussi

Les cinq �tapes de l'�volution DevOps identifi�es par le state of devops 2018, pr�sent�es par Puppet et Splunk

Azure DevOps : Microsoft annonce le successeur de Visual Studio Team Services et un service d'int�gration et d�ploiement continus int�gr�s � GitHub

Le � DevOps � et le d�veloppeur � FullStack � mettraient en danger le m�tier de d�veloppeur le constat inqui�tant de Jeff Knupp

[gangsoleil]

Bonjour,

Il est �vident que si on int�gre la s�curit� d�s le d�but, celle-ci est moins cher � mettre en �uvre, plus facile � int�grer, et souvent plus robuste.

Apr�s, ce qu'il faut mettre en balance dans cette �tude, c'est que le probl�me de s�curit� n'est pas li� aux conteneurs ou aux processus DevOps, mais � un manque de s�curit� dans les procesus. Autrement dit, si n'importe quoi d'autre aurait �t� utilis� pour faire ce d�ploiement, les probl�mes de s�curit� auraient �t� l� �galement.

On commence de plus en plus � int�grer la s�curit� d�s le d�but des processus, mais on part de tellement bas qu'il reste �norm�ment de chemin � parcourir.

[Bill Fassinou]

DevOps est-il un �chec ? Un ing�nieur logiciel de Pulumi pense que c'est le cas et propose de passer � une nouvelle approche appel�e SoftOps
pour r�soudre les probl�mes que DevOps n'a pu r�soudre

Lee Briggs, ing�nieur logiciel chez Pulumi, une soci�t� d'infrastructure en tant que code (infrastructure-as-code - IaC), a r�cemment publi� un avis personnel selon lequel l'approche DevOps est un �chec. L'approche DevOps vise � supprimer les frictions entre les d�veloppeurs et les op�rations dans toutes les �tapes de la cr�ation d'un logiciel, depuis le d�veloppement, l'int�gration, les tests, la livraison jusqu'au d�ploiement, l'exploitation et la maintenance des infrastructures. Mais Briggs pense que DevOps n'a pas r�ussi cette mission et ajoute que la plupart des outils commercialis�s sous le nom de "DevOps tooling" sont ax�s sur les op�rations.

DevOps est un ensemble de pratiques qui met l�accent sur la collaboration et la communication entre les d�veloppeurs de logiciels et les professionnels des op�rations informatiques, en automatisant le processus de livraison de logiciels et les changements d�infrastructure. L'objectif est de cr�er une culture et un environnement dans lesquels la conception, les tests et la diffusion de logiciels peuvent �tre r�alis�s rapidement, fr�quemment et efficacement. Selon ses partisans, DevOps n�est pas seulement une m�thodologie, c�est une v�ritable philosophie de travail. Cependant, d'autres pensent que DevOps n'a pas su tenir ses promesses.

Lee Briggs est de ceux qui pensent que DevOps a �chou�. � En fin de compte, mon �valuation de DevOps en 2022 est la suivante : DevOps, ce sont des gens du c�t� des op�rations qui essaient de convaincre les d�veloppeurs de faire les choses � leur mani�re. La quasi-totalit� de l'outillage commercialis� sous le nom de "DevOps tooling" est ax�e sur les op�rations. Si vous parcourez /r/devops, vous verrez des messages successifs de personnes parlant d'op�rations et d'outils op�rationnels. Si vous regardez la description de poste d'un ing�nieur DevOps, elle ressemble beaucoup au r�le d'un administrateur syst�me de 2013 �, d�clare Briggs.

Selon lui, si DevOps �tait cens� changer la culture g�n�rale, il ne peut pas �tre consid�r� comme un mouvement r�ussi. L'ing�nieur va plus loin en comparant DevOps � une course de dupes et appelle � un changement. � Les personnes du c�t� des op�rations diront volontiers "Eh bien, nous essayons !", mais ce qu'ils veulent dire par l�, c'est qu'ils essaient d'�tre un joueur de fl�te pour les consid�rations op�rationnelles. Ce n'est pas une voie � double sens. Il est bon de rappeler qu'en tant que personne charg�e des op�rations, nous sommes g�n�ralement en minorit� d'au moins 5/1 dans toute organisation d'ing�nierie donn�e �, a-t-il d�clar�.

� Essayer de convaincre le moindre d�veloppeur de faire les choses "� la mani�re des op�rations" et "d'utiliser les outils des op�rations" est en fin de compte une course de dupes. Nous avons besoin d'un changement. En fin de compte, je pense qu'il est trop tard pour sauver le terme "DevOps". Si les gens vous vendent du DevOps, il est probablement trop tard. Ce que j'aimerais voir voir se produire � partir de maintenant, c'est un changement fondamental dans la fa�on dont les gens de DevOps pensent dans leur r�le quotidien �, a-t-il ajout�. Briggs poursuit en disant que les op�rations en arrivent parfois � oublier leur r�le principal.

� Il est parfois difficile de s'en souvenir, mais, en tant que personnes ax�es sur les op�rations, notre r�le est de permettre et d'aider les d�veloppeurs � mettre les fonctionnalit�s dans les mains des clients (ou tout autre objectif commercial qu'ils pourraient avoir). La cr�ation d'un chemin de moindre r�sistance est une partie essentielle de la cr�ation et du maintien de la vitesse des d�veloppeurs qui livrent des produits et des fonctionnalit�s, et le fait que les d�veloppeurs apprennent et maintiennent toutes les pratiques d'exploitation n'est tout simplement pas r�alisable �, rappelle-t-il.

Eu �gard � tout ce qui pr�c�de, Briggs propose de changer d'approche et de passer � ce qu'il appelle : SoftOps (Operations for Software Developers). � SoftOps est l'id�e que nous allons construire des pratiques op�rationnelles centr�es sur l'am�lioration de la vie des d�veloppeurs. Nous n'allons pas leur dire ce qu'ils doivent faire, nous allons leur demander ce qu'ils veulent faire, d'un point de vue op�rationnel, puis nous allons leur faciliter la t�che autant que possible �, a-t-il d�clar�. Selon lui, l'�poque o� on lisait des pages de manuel de 48 pages et o� l'on disait � son chef de projet que l'on ne respectait pas les d�lais des sprints est r�volue.

Briggs explique que SoftOps est l'id�e que vous allez mettre les d�veloppeurs en premier, en tant que client principal. Pour lui, l'�laboration de pratiques op�rationnelles qui s'adressent � un monde de d�veloppeurs devrait (en th�orie) amener les d�veloppeurs � la table des n�gociations afin de travailler en collaboration. � Peut-�tre que si nous nous concentrons uniquement sur cet objectif, nous finirons par r�soudre les probl�mes que DevOps a essay� de r�soudre depuis 2009 �, a-t-il d�clar�. Briggs n'est pas all� plus loin dans les explications sur la nouvelle m�thodologie qu'il met en avant, mais les avis sur sa proposition sont mitig�s.

En outre, certains mettent en avant une autre approche appel�e NoOps, et qui est pr�sent�e comme une am�lioration du DevOps. NoOps est une �volution de la m�thode DevOps visant � �liminer la n�cessit� d'une �quipe d'exploitation distincte en automatisant enti�rement l'infrastructure informatique. Dans cette approche, toutes les t�ches d'approvisionnement, de maintenance et autres sont automatis�es � un niveau tel qu'aucune intervention manuelle n'est n�cessaire. NoOps et DevOps sont similaires dans un sens, car ils reposent tous deux sur l'automatisation pour rationaliser le d�veloppement et le d�ploiement de logiciels.

Cependant, DevOps vise � cr�er un environnement plus collaboratif tout en utilisant l'automatisation pour simplifier le processus de d�veloppement. D'autre part, NoOps vise � �liminer toute pr�occupation op�rationnelle du processus de d�veloppement. Dans un environnement enti�rement automatis�, les d�veloppeurs peuvent utiliser directement ces outils et processus, m�me sans conna�tre leurs m�canismes sous-jacents. Par ailleurs, une autre proposition est l'ITOps. Dans ce cas, toute t�che informatique peut relever de l'ITOps, quel que soit le domaine d'activit�. ITOps peut s'appliquer � pratiquement tous les domaines.

ITOps (ou TecOps) est l'abr�viation de IT Operations. Dans sa forme la plus fondamentale, l'ITOps est le processus de fourniture et de maintenance de tous les services, applications, technologies et infrastructures n�cessaires au fonctionnement d'un produit ou d'un service bas� sur les technologies de l'information. Par cons�quent, ITOps consid�re le d�veloppement de logiciels et la gestion de l'infrastructure informatique comme une entit� unifi�e faisant partie du m�me processus. La principale diff�rence d'ITOps est la fa�on dont il g�re la livraison et la maintenance.

Les ITOps sont davantage ax�es sur la stabilit� et la fiabilit� � long terme, avec un soutien limit� aux flux de travail agiles et rapides. En g�n�ral, l'agilit� et la rapidit� ne sont pas du tout les pr�occupations principales des ITOps. Ainsi, les ITOps sembleront inflexibles avec des flux de travail rigides. Cette approche est �galement orient�e vers la gestion de l'infrastructure physique avec des produits logiciels hautement test�s et bas�s sur des versions, o� la fiabilit� et la stabilit� sont des facteurs cl�s. Selon les critiques, ce manque de souplesse est �galement le principal inconv�nient des ITOps.

Cependant, les analystes estiment qu'il peut constituer un excellent choix pour les d�veloppements de logiciels monolithiques et � �volution lente, comme dans le secteur des services financiers. En revanche, ils ajoutent que l'approche ITOps devient obsol�te dans les d�veloppements logiciels qui �voluent rapidement. Et comme les d�veloppements logiciels modernes entrent dans cette cat�gorie, ITOps n'est pas un candidat appropri� pour de tels environnements.

Source : Billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'avis de Lee Briggs sur l'approche DevOps ?
Selon vous, la m�thodologie DevOps est-elle une r�ussite ou un �chec ? Pourquoi ?
Que pensez-vous de l'approche SoftOps propos�e par Briggs ? En quoi est-elle meilleure que DevOps ?
Que pensez-vous des autres alternatives au DevOps, telles que l'approche ITOps ou NoOps ?

Voir aussi

Les conteneurs du DevOps pr�sentent-ils des risques pour la s�curit� de vos donn�es ? Oui, selon une �tude

Plus de 60 % des �quipes DevOps sacrifient la s�curit� des conteneurs au profit de la vitesse, selon un rapport de NeuVector

France : le poste administrateur syst�me DevOps officiellement cr��, et class� au niveau 6 du cadre national des certifications professionnelles

[TotoParis]

Mais de quoi parle l'auteur quand il �crit "If you browse /r/devops"...En fait, et je l'avais devin� c'est https://www.reddit.com/r/devops/ ... mais bon sang quelle mani�re d'�crire chez ces am�ricains !
Sinon ce qu'il consid�re comme un �chec peut-il �tre � l'origine de ceci https://emploi.developpez.com/actu/3...-cette-raison/ ?

[redcurve]

Mais de quoi parle l'auteur quand il �crit "If you browse /r/devops"...En fait, et je l'avais devin� c'est https://www.reddit.com/r/devops/ ... mais bon sang quelle mani�re d'�crire chez ces am�ricains !
Sinon ce qu'il consid�re comme un �chec peut-il �tre � l'origine de ceci https://emploi.developpez.com/actu/3...-cette-raison/ ?

Tout le monde sait que /r est reddit sauf les boomers

[Eric80]

le job d un ing�nieur moderne est d automatiser des t�ches, cad de faire travailler des machines plut�t que des humains.
Avec DevOps, il s agit donc de supprimer les �quipes op�rationnelles et de demander aux d�veloppeurs de les remplacer par des outils automatis�s. Sauf que ces outils sont souvent frustrants � utiliser pour les d�veloppeurs car comme dit l auteur, les outils sont d abord penser pour la partie op�rationnelle et sont pas aussi mature que les IDE pour la partie d�veloppement des scripts.
Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour d�ployer automatiquement les composants logiciels �crits par les �quipes de d�veloppeurs. Mais on demande � ces m�mes d�veloppeurs d'�crire aussi les scripts de ces pipelines, qui peuvent vite devenir tr�s complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "co�teuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas d�bugger notre code si facilement.
(bais cognitif du moment: cela fait des semaines que je me prends la t�te sur les "rules" dans des pipelines imbriqu�es sur Gitlab)

[Mingolito]

C'est Devops qui est un �chec, ou alors les baltringues qui sont cens�s faire appliquer cette m�thode ?

T'es nul en programmation ? T'es nul en informatique ? T'es nul en management de projet ? Hop devient "Devops" apr�s quelques semaines de formation merdique dans une �cole priv�e pourrie avec des profs nuls voir absents, ou alors lis un "tuto" sur Youtube, et devient grassement pay� � ne rien foudre en travaillant seulement en vrai 1 h par jour pour pondre des rapports � la con qui servent � rien

La th�orie sur ce que �a devrait �tre :




Le r�sultat sur le terrain en pratique dans les faits :

[grunk]

le job d un ing�nieur moderne est d automatiser des t�ches, cad de faire travailler des machines plut�t que des humains.
Avec DevOps, il s agit donc de supprimer les �quipes op�rationnelles et de demander aux d�veloppeurs de les remplacer par des outils automatis�s. Sauf que ces outils sont souvent frustrants � utiliser pour les d�veloppeurs car comme dit l auteur, les outils sont d abord penser pour la partie op�rationnelle et sont pas aussi mature que les IDE pour la partie d�veloppement des scripts.
Prenez par ex les pipelines CI/CD sur Gitlab ou AzureDevOps: ce sont les outils de base pour d�ployer automatiquement les composants logiciels �crits par les �quipes de d�veloppeurs. Mais on demande � ces m�mes d�veloppeurs d'�crire aussi les scripts de ces pipelines, qui peuvent vite devenir tr�s complexe dans un environnement entreprise: une ligne de code d un script yaml est autrement plus "co�teuse" (en terme de temps) qu'un bloc de code en java, JS ou autre car on ne peut pas d�bugger notre code si facilement.
(bais cognitif du moment: cela fait des semaines que je me prends la t�te sur les "rules" dans des pipelines imbriqu�es sur Gitlab)

Rien ne t'emp�che d'�crire un yaml ultra minimal qui va ensuite aller ex�cuter des scripts �crits dans le langage que tu veux.

Le but de devops c'est pas de supprimer les �quipes op�rationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai m�tier pour lequel les d�v on rarement de l'int�r�t et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
Par contre �crire un script pour mettre en oeuvre ce qu'� pr�parer les ops ca on sait faire , souvent plus efficacement que les ops.

[micka132]

Par contre �crire un script pour mettre en oeuvre ce qu'� pr�parer les ops ca on sait faire , souvent plus efficacement que les ops.

Avec cette phrase tu r�sumes le ph�nom�ne. Les "ops" ne sont que les "sys admin" de la d�cennie pr�c�dente.
Et comme dans la d�cennie pr�c�dente, tu as les gars dans les petites boites qui font tout (dev/exploitation/support/qualit�) et au plus tu vas dans de grosse boite au plus les activit�s sont dissoci�es. Cette mouvance "devops" est initi�e par des gars de grosse structure qui voulait ressentir le cot� touche � tout de la petite boite.
Mais le r�el c'est que passer le fun d'apprendre des trucs avec des tutos, �a reste bien plus efficace d'avoir des "sp�cialistes".

Moralit�: si vous voulez faire du vrai devops il faut aller dans une petite structure.

[smarties]

Le but de devops c'est pas de supprimer les �quipes op�rationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai m�tier pour lequel les d�v on rarement de l'int�r�t et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).

C'est en effet ce qui arrive quand on embauche des d�veloppeurs sur du DevOps.
En tant que d�veloppeur, quand je vois la stack technique sur la partie dev (souvent back-end avec la connaissance du front ) et qu'en plus �a demande des comp�tences CI/CD et Cloud dans les offres d'emploi, ce n'est pas �tonnant que la production soit mal configur�e. Certe, on a des connaissances et des comp�tences sur la partie DevOps mais on deviendra rarement un expert DevOps si on n'est pas � plein temps dessus.
Personnellement, je me contente au quotidien de :
- 1-2 langages de programmation avec 1-2 framework par langage
- docker pour la conteneurisation et effectuer des tests
- un serveur Linux et Ansible pour le d�ploiement de la solution en production
- nginx pour configurer le serveur web

La partie CI/CD je passerais du temps si je dois mettre �a en place

[redcurve]

Rien ne t'emp�che d'�crire un yaml ultra minimal qui va ensuite aller ex�cuter des scripts �crits dans le langage que tu veux.

Le but de devops c'est pas de supprimer les �quipes op�rationnelles , mais de supprimer la friction entre les dev et les ops. L'ops ca reste un vrai m�tier pour lequel les d�v on rarement de l'int�r�t et quand c'est le cas il leur manque souvent de la connaissance pour faire les choses bien (exemple).
Par contre �crire un script pour mettre en oeuvre ce qu'� pr�parer les ops ca on sait faire , souvent plus efficacement que les ops.

Perso mes Yaml ne font que lancer des scripts powershell et ce pour Windows, Linux et Macos grace � Powershell core https://github.com/powershell/powershell .

[Astraya]

Perso mes Yaml ne font que lancer des scripts powershell et ce pour Windows, Linux et Macos grace � Powershell core https://github.com/powershell/powershell .

Je suis heureux de pas �tre le seul pour ma part c'est un ex�cutable. Net Core que je peux aussi tester sur ma machine

[redcurve]

Je suis heureux de pas �tre le seul pour ma part c'est un ex�cutable. Net Core que je peux aussi tester sur ma machine

Franchemen je n'ai pas touch� Bash depuis 3 ans et je dois dire que �a ne me manque pas

[walfrat]

Mon point de vue sur DEVOPS c'�tait surtout de "professionnaliser" ce qui tourne autour du dev sans �tre du dev pur. En effet, le focus �tant souvent mis sur le dev pur que le reste, le reste est mal ma�tris� au sens gestion, mal budg�t�, et en plus mal ma�tris� techniquement par les d�veloppeur, r�sultant plus souvent dans des r�sultats relativement "amateur".

Car le fait est que la plupart des d�veloppeurs peuvent �crire quelques script d'auto d�ploiement qui marcherons a peu pr�s. Mais pour avoir un truc nickel, surtout dans le cas d'un client lourd par exemple, il y a une marche qui distingue bien un truc plus "amateur" qu'un truc "pro" fait par les gens plus du syst�me g�n�ralement.

Dans les exemples :

• Mis � jour automatiques des applications, mais aussi upgrade des composant de serveur/bdd.
• Reg�n�ration des certificats SSL n�cessaires pour avoir une plateforme validation qu'on teste en HTTPS.
• Gestion des comptes utilisateurs, de l'AD, des trucs SSO (kerberos, SAML, CAS, ,...),...
• Pipelines CI (bon j'ai pas chez moi �a )
• ...

Quand on voit �a, j'ai aucun doute qu'une bonne partie peuvent ce dire "bon je vais gal�rer mais �a va globalement passer", ben oui, sauf que r�guli�rement y'a quand m�me un truc qui p�te et le temps de trouv� tu prend deux jours.

[TJ1985]

Probl�mes de riches. "De mon temps", m�me dans des structures importantes, un d�veloppeur �tait responsable de son produit de a..z. Accessoirement, c'�taient les d�veloppeurs internes qui d�veloppaient l'environnement d'exploitation et l'environnement de d�veloppement, afin d'offrir une gestion de sources et de versions homog�nes, une gestion multi-plateformes des mises en production, etc.
�a, c'�tait d�s 1990. Ensuite, on a voulu des sp�cialistes, car un sp�cialiste, c'est sp�cialis� et le "chef de projet consultant" aura toujours beau jeu de le renvoyer � sa sp�cialit� lorsque lui-m�me sera menac� d'avoir d�montr� son inutilit�.
La situation a commenc� � s�rieusement se d�grader lorsque les m�thodes dites agiles sont apparues. L'aspect sectaire et messianique des s�ances �tait frappant, leur inefficacit� aussi. Mais comme on avait pay� tr�s cher le super consultant venu mettre tout �a en place, il n'�tait pas question de revenir en arri�re. Alors on a engag�, car c'est bien connu : Quand un projet prend du retard, doublez les effectifs, �a ira mieux (je plaisante).
Bref. J'ai l'impression qu'aujourd'hui beaucoup de gens d�pensent une �nergie folle � faire une informatique qui ne soit plus de l'informatique mais de la gestion administrative, tout en s'affublant de titres inflationnistes.
Mais dans le fond, si vous voulez livrer quelque chose qui facilite la vie de votre client, un compilateur (multi-plateformes), un SGBDR, de bonnes librairies, du temps, un peu de talent valent beaucoup mieux qu'une �quipe de fashionistas d�versant leur glose r�cemment apprise en prenant l'air d'avoir invent� la poudre qui p�te deux fois.

[smarties]

Probl�mes de riches. "De mon temps", m�me dans des structures importantes, un d�veloppeur �tait responsable de son produit de a..z. Accessoirement, c'�taient les d�veloppeurs internes qui d�veloppaient l'environnement d'exploitation et l'environnement de d�veloppement, afin d'offrir une gestion de sources et de versions homog�nes, une gestion multi-plateformes des mises en production, etc.
�a, c'�tait d�s 1990. Ensuite, on a voulu des sp�cialistes, car un sp�cialiste, c'est sp�cialis� et le "chef de projet consultant" aura toujours beau jeu de le renvoyer � sa sp�cialit� lorsque lui-m�me sera menac� d'avoir d�montr� son inutilit�.
La situation a commenc� � s�rieusement se d�grader lorsque les m�thodes dites agiles sont apparues. L'aspect sectaire et messianique des s�ances �tait frappant, leur inefficacit� aussi. Mais comme on avait pay� tr�s cher le super consultant venu mettre tout �a en place, il n'�tait pas question de revenir en arri�re. Alors on a engag�, car c'est bien connu : Quand un projet prend du retard, doublez les effectifs, �a ira mieux (je plaisante).
Bref. J'ai l'impression qu'aujourd'hui beaucoup de gens d�pensent une �nergie folle � faire une informatique qui ne soit plus de l'informatique mais de la gestion administrative, tout en s'affublant de titres inflationnistes.
Mais dans le fond, si vous voulez livrer quelque chose qui facilite la vie de votre client, un compilateur (multi-plateformes), un SGBDR, de bonnes librairies, du temps, un peu de talent valent beaucoup mieux qu'une �quipe de fashionistas d�versant leur glose r�cemment apprise en prenant l'air d'avoir invent� la poudre qui p�te deux fois.

Dans les ann�es 90 il n'y avait pas autant d'outils qu'aujourd'hui et d'environnements cloud. De plus on voit ce que �a donne le code legacy :
- souvent peu de documentation
- les personnes qui les ont d�velopp�s sont parties
- chacun programmait � sa fa�on
- parfois obliger de coder des fonctionnalit�s qui sont devenues standards dans les autres langages/frameworks
- peu de tests

Quand les outils de gestions de version sont arriv�s cela a apport� un confort et de nouvelles r�gles.
Je trouve que �a s'est complexifi� quand les solutions cloud sont arriv�e : avant on installait un serveur de A � Z mais maintenant on doit apprendre un nouvel environnement � chaque fois que l'on change d�h�bergeur cloud.
Avant on avait des petits scripts pour la compilation et le d�ploiement (ou ce dernier point �tait fait manuellement) mais maintenant on a int�grer des outils d'analyse de code, des automatisation de tests, des r�gles pour les pull requests donc de nouveaux outils � conna�tre.
Enfin, on a des d�lais courts pour le d�veloppement donc il est plus facile de d�l�guer � des sp�cialistes plut�t que de passer plusieurs jours pour automatiser le d�ploiement ou autre.