![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-lukas-928199-1024x678.jpg\")
<\/figure>\n\nCe livre nous a aid\u00e9s \u00e0 \u00e9viter des risques qui co\u00fbtent cher aux entreprises en termes de temps d’arr\u00eat et de r\u00e9putation. Quatre-vingt pour cent du co\u00fbt du cycle de vie d’un produit se situe au niveau de la production. <\/p>\n\n
LE LIVRE EXPLIQU\u00c9 EN MOINS DE 60 SECONDES<\/strong><\/p>\n\n La version actualis\u00e9e de Release it ! Design and Deploy Production-Ready Software traite de la production de syst\u00e8mes modernes – des syst\u00e8mes volumineux, complexes et fortement virtualis\u00e9s. Elle comprend un aper\u00e7u de l’ing\u00e9nierie du chaos, de la discipline de mise en \u0153uvre des mises \u00e0 jour sans temps d’arr\u00eat et de la livraison continue, ainsi que de la robustesse des logiciels natifs dans le nuage. Analysez les approches de l’architecture, de la conception et de la cr\u00e9ation de syst\u00e8mes distribu\u00e9s \u00e0 dominante logicielle. <\/p>\n\n TROIS CITATIONS PRINCIPALES<\/strong><\/p>\n\n R\u00c9SUM\u00c9S ET NOTES DE LECTURE<\/strong><\/p>\n\n Premier chapitre : Cr\u00e9er la stabilit\u00e9<\/strong><\/p>\n\n Lorsque votre logiciel ou votre base de donn\u00e9es tombe en panne, changez de fen\u00eatre et essayez quelque chose de nouveau. Vous pouvez faire appel \u00e0 un ing\u00e9nieur local pour vous aider \u00e0 mettre en \u0153uvre le changement. Si vous changez de base de donn\u00e9es, essayez de passer \u00e0 un meilleur fournisseur de services. Vous pouvez commencer par d\u00e9placer vos informations et vos donn\u00e9es de l’ancienne base de donn\u00e9es 1 vers la nouvelle base de donn\u00e9es 2, puis mettre \u00e0 jour la base de donn\u00e9es 1. Apr\u00e8s avoir v\u00e9rifi\u00e9 la base de donn\u00e9es mise \u00e0 jour, d\u00e9placez vos informations et vos donn\u00e9es vers la base de donn\u00e9es 1. <\/p>\n\n Une mauvaise stabilit\u00e9 entra\u00eene des co\u00fbts r\u00e9els \u00e9lev\u00e9s. Le prix apparent est une perte de revenus. Une bonne stabilit\u00e9 ne co\u00fbte pas si cher. Lors de l’\u00e9laboration de l’architecture, de la conception et de la mise en \u0153uvre de syst\u00e8mes mineurs, de nombreux points de d\u00e9cision ont une grande influence sur la stabilit\u00e9 du syst\u00e8me. La mise en \u0153uvre d’un logiciel tr\u00e8s stable co\u00fbte g\u00e9n\u00e9ralement le m\u00eame prix que celle d’un logiciel instable. Pour parler de stabilit\u00e9, vous devez conna\u00eetre les transactions. Une transaction est une unit\u00e9 abstraite de travail trait\u00e9e par le syst\u00e8me. Une transaction s’\u00e9tend sur de nombreuses pages et implique g\u00e9n\u00e9ralement des int\u00e9grations externes telles que la v\u00e9rification des cartes de cr\u00e9dit. Les transactions sont la raison d’\u00eatre d’un syst\u00e8me. Un syst\u00e8me peut traiter un seul type de transaction et le rendre enti\u00e8rement d\u00e9di\u00e9. <\/p>\n\n Les principales incertitudes qui p\u00e8sent sur la dur\u00e9e de vie de votre syst\u00e8me sont les fuites de donn\u00e9es et de m\u00e9moire. Ces deux dangers peuvent tuer votre syst\u00e8me en production et sont rarement d\u00e9tect\u00e9s lors des tests. Les tests permettent de visualiser les probl\u00e8mes afin que vous puissiez les r\u00e9soudre. Les probl\u00e8mes qui surviennent lorsque votre logiciel est termin\u00e9 sont ceux que vous n’avez pas test\u00e9s. Par cons\u00e9quent, ces pannes se produiront si vous ne testez pas les erreurs de m\u00e9moire dans l’application. <\/p>\n\n \n Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0Concevez avec scepticisme et vous obtiendrez la r\u00e9silience.<\/em>\n<\/strong>.\u00a0\u00bb<\/p>\n\n Chapitre deux : Conception pour la production<\/strong><\/p>\n\n Les op\u00e9rations vous am\u00e8nent \u00e0 concevoir pour des consid\u00e9rations de production en examinant les fondements physiques du syst\u00e8me : les machines et les c\u00e2bles sur lesquels tout repose. R\u00e9solvez certains probl\u00e8mes concernant les r\u00e9seaux, les noms d’h\u00f4tes et les adresses IP. Chaque d\u00e9ploiement a son propre ensemble de pr\u00e9occupations que les conceptions logicielles doivent prendre en compte. <\/p>\n\n La mise en r\u00e9seau au sein du centre de donn\u00e9es et du nuage ne se limite pas \u00e0 l’ouverture d’une prise de courant. Ces r\u00e9seaux absorbent g\u00e9n\u00e9ralement plus de redondance et de s\u00e9curit\u00e9 que les r\u00e9seaux de bureau. Lorsque vous ajoutez une ou deux couches de virtualisation, les applications et les services se comportent de mani\u00e8re plus distincte que dans les limites s\u00fbres de l’IDE. Ils n\u00e9cessiteront un travail important pour se comporter correctement dans cet environnement. <\/p>\n\n Une instance est une installation sur une seule machine (virtuelle ou physique) \u00e0 partir d’un r\u00e9seau \u00e0 charge \u00e9quilibr\u00e9e du m\u00eame ex\u00e9cutable. Les instances individuelles assurent la transparence, g\u00e8rent correctement la configuration, acceptent le contr\u00f4le et g\u00e8rent les connexions. Chaque machine n\u00e9cessite le code, la configuration et les liens r\u00e9seau corrects. Les d\u00e9veloppeurs pr\u00eatent g\u00e9n\u00e9ralement attention au comportement de leur code. C’est pourquoi ils disposent d’excellents outils pour construire, h\u00e9berger et d\u00e9ployer le code. Les d\u00e9veloppeurs doivent \u00eatre capables de construire un syst\u00e8me, d’effectuer des tests et de mettre en \u0153uvre au moins une partie du syst\u00e8me localement. <\/p>\n\n Les couches d’interconnexion couvrent tous les m\u00e9canismes qui combinent un ensemble d’instances en un syst\u00e8me coh\u00e9rent, y compris la gestion du trafic, la d\u00e9couverte et l’\u00e9quilibrage de la charge. C’est gr\u00e2ce aux couches d’interconnexion qu’il est possible de cr\u00e9er une haute disponibilit\u00e9. Envisagez la solution la mieux adapt\u00e9e \u00e0 votre organisation lorsque vous passez \u00e0 l’interconnexion, au panneau de contr\u00f4le et \u00e0 l’exploitation. Peu de techniques de d\u00e9couverte et d’innovation de services d\u00e9pendent g\u00e9n\u00e9ralement de logiciels suppl\u00e9mentaires. Une \u00e9quipe \u00e9tendue avec des milliers de petits services est performante lorsqu’elle utilise Consul ou tout autre service dynamique. De plus, le co\u00fbt d’exploitation de Consul est rapidement amorti. Pour les petites \u00e9quipes, le choix id\u00e9al dans une infrastructure \u00e0 \u00e9volution lente est le DNS. Cela implique des machines physiques engag\u00e9es et des machines virtuelles d\u00e9di\u00e9es \u00e0 longue dur\u00e9e de vie. Les adresses IP restent g\u00e9n\u00e9ralement stables pour que le DNS soit pratique. <\/p>\n\n Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0L’\u00e9quilibrage des charges, le routage, le d\u00e9lestage et la d\u00e9couverte de services sont quelques-unes des questions cl\u00e9s \u00e0 prendre en compte lors de la construction des couches.<\/em><\/strong><\/p>\n\n Chapitre trois : Livrer votre syst\u00e8me<\/strong><\/p>\n\n Vous ne devez pas pr\u00e9voir un seul ou quelques d\u00e9ploiements pour les productions, mais plusieurs. Apr\u00e8s avoir \u00e9crit, compress\u00e9 et envoy\u00e9 votre logiciel pour le d\u00e9ployer dans les op\u00e9rations, ajoutez des notes de mise \u00e0 jour pour chaque nouvelle option de configuration qu’ils doivent d\u00e9finir. Les op\u00e9rations fixeront un \u00ab\u00a0temps d’arr\u00eat planifi\u00e9\u00a0\u00bb pour l’ex\u00e9cution de la version. La plupart du temps, vous concevez l’\u00e9tat du syst\u00e8me apr\u00e8s une mise en production. Le probl\u00e8me est que cela suppose que l’ensemble du syst\u00e8me peut \u00eatre modifi\u00e9 par un saut quantique instantan\u00e9. <\/p>\n\n Le code est une responsabilit\u00e9 \u00e9vidente entre le moment o\u00f9 vous l’ex\u00e9cutez dans le r\u00e9f\u00e9rentiel et le moment o\u00f9 il s’ex\u00e9cute en production. Le code non d\u00e9ploy\u00e9 est g\u00e9n\u00e9ralement un inventaire. Il comporte des bogues non divulgu\u00e9s et provoque des arr\u00eats de production. Il peut s’agir d’une impl\u00e9mentation id\u00e9ale d’une fonctionnalit\u00e9 dont personne ne veut. Le d\u00e9ploiement continu minimise le d\u00e9lai entre l’ex\u00e9cution et la production du code et la responsabilit\u00e9 du code non d\u00e9ploy\u00e9. <\/p>\n\n Les bases de donn\u00e9es sont la principale raison des \u00ab\u00a0arr\u00eats planifi\u00e9s\u00a0\u00bb, principalement les changements de sch\u00e9ma dans les bases de donn\u00e9es relationnelles. Au lieu d’impl\u00e9menter des scripts SQL bruts \u00e0 l’aide d’une CLI d’administration, vous pouvez avoir un contr\u00f4le programmatique pour faire avancer la version de votre sch\u00e9ma. Un cadre de migration tel que Liquibase peut vous aider \u00e0 mettre en \u0153uvre les changements de sch\u00e9ma. Cependant, il ne rend pas automatiquement ces changements compatibles avec les versions ant\u00e9rieures et post\u00e9rieures. <\/p>\n\n Lorsque vous ajoutez des fonctionnalit\u00e9s \u00e0 votre application, veillez \u00e0 ne pas consommer les applications. Les diff\u00e9rents consommateurs de votre service ont d’autres objectifs et d’autres besoins. Chaque application consommatrice a son \u00e9quipe de d\u00e9veloppement qui travaille selon son propre calendrier. Vous ne pouvez pas forcer les consommateurs \u00e0 suivre votre calendrier de publication. Pour apporter des modifications compatibles \u00e0 l’API, r\u00e9fl\u00e9chissez \u00e0 ce qui constitue une modification incompatible. <\/p>\n\n Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0En m\u00eame temps, j’\u00e9prouvais un profond sentiment de perte : tout ce temps pass\u00e9 dans l’arm\u00e9e de d\u00e9ploiement. Tout ce potentiel gaspill\u00e9. L’humanit\u00e9 gaspill\u00e9e ! Utiliser les gens comme s’ils \u00e9taient des robots. Perturber des vies, des familles, des rythmes de sommeil… c’\u00e9tait un tel g\u00e2chis.\u00a0\u00bb<\/em><\/strong><\/p>\n\n Chapitre quatre : R\u00e9soudre les probl\u00e8mes syst\u00e9miques<\/strong><\/p>\n\n Le test de charge est g\u00e9n\u00e9ralement un processus non interventionniste. Vous d\u00e9finissez un plan de test, g\u00e9n\u00e9rez quelques scripts, configurez les g\u00e9n\u00e9rateurs de charge et le r\u00e9partiteur de test, et lancez une s\u00e9rie de tests pendant la nuit. Une fois le test termin\u00e9, analysez les donn\u00e9es collect\u00e9es pendant le test. Examinez les r\u00e9sultats, modifiez la configuration et programmez le prochain test. Le test de charge est \u00e0 la fois un art et une science. Il est inimaginable de reproduire le trafic de production r\u00e9el. Utilisez donc l’analyse du trafic et votre intuition pour parvenir \u00e0 une simulation aussi proche que possible de la r\u00e9alit\u00e9. <\/p>\n\n Le changement est garanti, mais la survie ne l’est pas. Le d\u00e9veloppement agile permet d’accepter le changement en r\u00e9action \u00e0 la situation de l’entreprise. Cependant, la fl\u00e8che est susceptible de pointer dans l’autre direction. Le changement de logiciel peut g\u00e9n\u00e9rer de nouveaux produits et de nouveaux march\u00e9s. Il peut cr\u00e9er un espace pour de nouvelles alliances et une nouvelle concurrence, en augmentant la surface entre des entreprises qui appartenaient auparavant \u00e0 des secteurs diff\u00e9rents. Tous les logiciels n’ont pas besoin d’\u00eatre modifi\u00e9s quotidiennement. Certains logiciels n’ont pas de potentiel de changement et d’adaptation rapide. Dans certains secteurs, le changement de logiciel passe par une certification longue et co\u00fbteuse. Les co\u00fbts de transaction sont \u00e9lev\u00e9s si vous voulez envoyer des astronautes dans l’espace avec un tournevis et une pince \u00e0 d\u00e9couper les puces. <\/p>\n\n Pour mettre en \u0153uvre un changement, votre entreprise doit passer par un cycle de d\u00e9cision. Quelqu’un doit sentir qu’un besoin existe, quelqu’un d’autre doit d\u00e9cider que ce changement r\u00e9pondra parfaitement \u00e0 ce besoin et qu’il vaut la peine d’\u00eatre mis en \u0153uvre. Ensuite, quelqu’un doit agir, concevoir la fonctionnalit\u00e9 et la mettre sur le march\u00e9, et enfin, quelqu’un doit voir si le changement a eu l’effet escompt\u00e9. Dans les petites entreprises, le processus peut impliquer deux ou trois personnes. La communication est assez rapide. <\/p>\n\n L’ing\u00e9nierie du chaos concerne les syst\u00e8mes distribu\u00e9s, g\u00e9n\u00e9ralement \u00e0 grande \u00e9chelle. Les environnements d’essai ou d’assurance qualit\u00e9 ne sont pas id\u00e9aux pour le comportement \u00e0 grande \u00e9chelle des syst\u00e8mes de production. Diff\u00e9rents ratios d’instances entra\u00eenent des comportements de sortie qualitativement diff\u00e9rents, ce qui est \u00e9galement le cas pour le trafic. Les r\u00e9seaux encombr\u00e9s se comportent de mani\u00e8re qualitativement diff\u00e9rente des r\u00e9seaux non encombr\u00e9s. <\/p>\n\n Citation pr\u00e9f\u00e9r\u00e9e du chapitre : \u00ab\u00a0La plupart des testeurs que j’ai connus sont suffisamment pervers pour que, si vous leur indiquez le \u00ab\u00a0chemin heureux\u00a0\u00bb \u00e0 travers l’application, c’est la derni\u00e8re chose qu’ils feront. Il devrait en \u00eatre de m\u00eame pour les tests de charge.\u00a0\u00bb <\/em><\/strong><\/p>\n\n COMMENT CE LIVRE PEUT AIDER LES D\u00c9VELOPPEURS DE LOGICIELS<\/strong><\/p>\n\n \u00ab\u00a0Release It !\u00a0\u00bb de Michael T. Nygard est un guide pratique qui aide les d\u00e9veloppeurs de logiciels \u00e0 concevoir, d\u00e9velopper et d\u00e9ployer des logiciels pr\u00eats pour la production. Le livre fournit des exemples concrets et des \u00e9tudes de cas, mettant en \u00e9vidence les pi\u00e8ges les plus courants et proposant des solutions pour les \u00e9viter. Il propose des conseils et des techniques pour identifier et r\u00e9soudre les probl\u00e8mes avant le d\u00e9ploiement, y compris la gestion des d\u00e9pendances, les tests et la surveillance. Il couvre des sujets tels que l’optimisation des performances, l’\u00e9volutivit\u00e9, la tol\u00e9rance aux pannes, la surveillance et la journalisation, en se concentrant sur la construction de logiciels qui peuvent survivre aux rigueurs de la production. En suivant les lignes directrices du livre, les d\u00e9veloppeurs de logiciels peuvent cr\u00e9er des syst\u00e8mes fiables et r\u00e9silients qui r\u00e9pondent aux exigences de leurs utilisateurs et de leurs clients. Dans l’ensemble, ce livre est une ressource essentielle pour les d\u00e9veloppeurs qui cherchent \u00e0 am\u00e9liorer la qualit\u00e9 et les performances de leurs logiciels dans l’environnement de production. <\/p>\n","protected":false},"excerpt":{"rendered":" Une simple d\u00e9faillance logicielle peut co\u00fbter beaucoup d’argent \u00e0 une organisation, mais il est possible de l’\u00e9viter en modifiant facilement l’architecture et la conception. Cette nouvelle \u00e9dition de \u00ab\u00a0Release It\u00a0\u00bb a \u00e9t\u00e9 publi\u00e9e en janvier 2018. Elle illustre comment concevoir des syst\u00e8mes qui fonctionnent plus longtemps en limitant les d\u00e9faillances et en reprenant le contr\u00f4le […]<\/p>\n","protected":false},"author":1,"featured_media":17672,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[102],"tags":[],"writer":[],"class_list":["post-19805","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-club-de-lecture"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19805","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/comments?post=19805"}],"version-history":[{"count":3,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19805\/revisions"}],"predecessor-version":[{"id":20030,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19805\/revisions\/20030"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media\/17672"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media?parent=19805"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/categories?post=19805"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/tags?post=19805"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/writer?post=19805"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-fauxels-3182780-1024x683.jpg\")
<\/figure>\n\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-pixabay-459304-1024x683.jpg\")
<\/figure>\n\n\n