Comment utiliser la livraison continue pour se déployer sur un serveur en direct

Les plats clés

• La livraison continue (CD) est une méthode de déploiement de logiciels qui permet un déploiement rapide, fiable et fréquent de mises à jour et de nouvelles fonctionnalités vers un serveur en direct, réduisant les risques et l'intervention manuelle. Ce processus est bénéfique pour maintenir le contrôle de la qualité, réduire les coûts de développement et augmenter la productivité.
• CD implique un développeur rédigeant des tests de logiciels automatisés et du code, testant et validant les mises à jour localement, poussant la branche vers un référentiel de contrôle de version centrale, puis le système de CD tirant automatiquement le logiciel mis à jour, exécutant des processus de construction et exécutant à nouveau des tests automatisés sur un serveur de mise en scène. Une fois approuvé, toutes les modifications sont déployées sur le serveur en direct sans aucun effort du développeur.
• CD peut être automatisé à l'aide de services tels que CodeShip, qui peut gérer le processus CD. Cela réduit le temps et les efforts requis pour le déploiement manuel, ce qui rend le processus plus efficace et moins sujet à l'erreur humaine.

Cet article a été parrainé par CodeShip. Merci de soutenir les sponsors qui rendent le point de point possible! Comment déployez-vous votre site Web ou votre application sur votre serveur en direct? Ce processus semble-t-il familier?

1. Obtenez une copie de la dernière base de code
2. Ajouter, modifier et supprimer le code si nécessaire
3. Testez la mise à jour
4. Copiez les fichiers TOUT / modifiés sur le serveur à l'aide de FTP
5. rincer et répéter

C'est un flux de travail simple utilisé par de nombreux développeurs. Une proportion de développeurs gérera également les mises à jour sans contrôle source telles que GIT ou SVN. Le processus peut être assez bon pour les petits projets avec des mises à jour peu fréquentes. Malheureusement, il décompose le moment où votre site ou votre application atteint n'importe quel niveau de complexité.

Problèmes avec un flux de travail traditionnel

1. Le test n'est pas robuste

Votre système local est-il une correspondance exacte pour l'environnement de votre serveur?

2. C'est sujette à l'erreur

Un fichier manqué ou le fait de ne pas mettre à jour un enregistrement de base de données pourrait réduire toute l'application.

3. Vous déploiez sur un système en direct

Les utilisateurs peuvent rencontrer des problèmes d'accès même lorsque le processus est terminé avec succès en quelques minutes. Les utilisateurs d'Amazon, de Gmail, de Facebook ou de Twitter auraient-ils dû être inutile?

4. Il est difficile de revenir en arrière

Vos erreurs sont en direct; Rendre les modifications n'est pas toujours facile, même si vous utilisez le contrôle source.

5. Le contrôle de la source peut ne pas couvrir toutes les éventualités

Vous pouvez perdre des données de base de données ou d'autres actifs qui ne sont pas stockés en tant que fichiers.

6. Ce n'est pas une preuve future

Le flux de travail deviendra de plus en plus difficile à mesure que davantage de développeurs se joignent au projet ou que des serveurs supplémentaires sont ajoutés.

7. L'expédition est plus lente

Le déploiement manuel est douloureux, donc la libération de corrections de bugs et de mises à jour est fait moins souvent.

8. Le développement est imprévisible et l'échec peut ne pas être votre défaut (direct)

Une nouvelle version de Ruby, Node.js Update, la mise à niveau du framework ou la modification de la base de données sur votre serveur en direct pourraient arrêter votre application. Nous considérons rarement d'autres logiciels sur notre pile, mais même un système d'exploitation ou une mise à jour d'infrastructure pourrait être risqué. Évitez-vous les mises à jour pour minimiser les dangers malgré la vitesse, la stabilité et les avantages de sécurité qu'ils apportent?

Le principal problème: Le processus est laborieux

Vous pourriez faire un travail beaucoup plus productif. Pourquoi devriez-vous supporter des mises à jour manuelles lorsque les logiciels et les services peuvent effectuer les tâches fastidieuses pour vous? Vous utilisez peut-être déjà des outils de construction tels que Grunt, Gulp, Make ou Rake - alors pourquoi ne pas terminer votre processus de workflow avec une livraison continue automatisée?

Livraison continue en un mot

La livraison continue vous permet à vous et aux membres de votre équipe de déployer rapidement, de manière fiable et répétée des correctifs, des améliorations et de nouvelles fonctionnalités à votre serveur en direct. L'objectif est de réduire le risque et l'intervention manuelle. Vous rencontrerez également le terme intégration continue qui fait référence à la partie de développement axée sur le test de ce processus. Cela dit, les deux termes sont souvent utilisés de manière interchangeable. La livraison continue peut être imaginée comme un pipeline de déploiement à travers lequel les logiciels circulent des développeurs vers le serveur en direct. Le flux peut être tiré si une personne ou un système remarque une erreur critique. Le processus suit généralement ces étapes, bien que les politiques diffèrent d'une équipe à l'autre:

1. Un développeur écrit des tests logiciels automatisés et du code avant de tester et de valider leurs mises à jour localement. Un certain nombre de développeurs pourraient travailler sur différentes mises à jour, chacune ayant créé sa propre branche de l'application actuelle.
2. La branche est poussée vers un référentiel de contrôle de version centrale tel que GitHub ou Bitbucket. En règle générale, cela se traduit par une demande de traction qui peut être examinée par un autre développeur avant d'être fusionné dans la branche du logiciel principal.
3. Le système de livraison continu tire automatiquement le logiciel mis à jour, exécute les processus de construction et exécute à nouveau des tests automatisés. Cela se produit sur un serveur de mise en scène qui a un environnement identique au serveur en direct. Les développeurs sont informés si des échecs se produisent.
4. Les tests et l'évaluation d'acceptation des utilisateurs supplémentaires peuvent désormais être effectués sur le serveur de mise en scène par les propriétaires de produits et / ou les clients.
5. Sur l'approbation finale, toutes les modifications sont déployées sur le serveur en direct rapidement et sans douleur, sans aucun effort du développeur.

La livraison continue est souvent utilisée dans des environnements de développement agile, mais vous pouvez l'adopter quels que soient les processus que vous utilisez. Le processus est livré avec une multitude d'avantages:

• Le processus de déploiement est robuste. Vous aurez la confiance qu'une mise à jour fonctionnera avant qu'elle ne soit installée sur le serveur en direct.
• Il y a moins de risques. Le processus est moins sujet à l'erreur humaine et, en cas de défaillance catastrophique, vous pouvez faire reculer l'application à un état de travail.
• Le contrôle de la qualité est maintenu. Seul le code approuvé doit être mis en direct.
• Votre équipe devient plus productive et les coûts de développement sont réduits. L'investissement en temps de configuration initial sera remboursé dans un jour des jours maintenant que les développeurs n'ont pas besoin d'être impliqués dans les processus de déploiement manuel.

Mais les avantages de la livraison continue sont beaucoup plus importants lorsque vous n'avez pas besoin de gérer le logiciel vous-même.

Services de livraison continue automatisés

L'installation, la configuration et la gestion d'une suite de logiciels de livraison continue peuvent être intimidantes, longues et coûteuses, certains produits étant difficiles à travailler. Alors que les applications et les services comme Slack, Crashlytics et Pusher facilitent les tâches d'autres développeurs, d'autres font de même pour la livraison continue. Un tel exemple est CodeShip, un produit axé sur l'UX qui peut prendre en charge le processus de livraison continu pour vous. Leurs systèmes sont conçus pour être conviviaux, mais vous pouvez obtenir de l'aide et des conseils d'une personne réelle si vous en avez besoin. Le temps de configuration moyen? Quatre minutes. C'est plus rapide qu'une seule session FTP et vous n'avez besoin de le faire qu'une seule fois! Ils ont également un plan gratuit, offrant jusqu'à cinq projets privés et 100 constructions par mois. Pour en savoir un peu plus sur la livraison continue, CodeShip propose un «cours intensif» de cinq jours sur le sujet - il y a un lien pour s'inscrire en bas à gauche de leur page d'accueil. La livraison continue est un excellent moyen de quitter la corvée du déploiement FTP derrière, espérons-le pour toujours, et qui vaut la peine d'être enquêté. Avez-vous essayé une livraison continue? Quels sont vos conseils pour gérer le déploiement?

Les questions fréquemment posées sur la livraison continue et le déploiement des logiciels

Qu'est-ce que la livraison continue dans le déploiement de logiciels?

La livraison continue (CD) est une pratique de développement de logiciels où les modifications de code sont automatiquement construites, testées et préparées pour une version de production. Il augmente l'intégration continue en déployant toutes les modifications de code dans un environnement de test et / ou un environnement de production après l'étape de construction. Cela signifie qu'en plus des tests automatisés, votre logiciel est automatiquement prêt à être déployé en production à un moment donné.

En quoi la livraison continue diffère-t-elle du déploiement continu?

Alors que les deux pratiques sont similaires , la principale différence réside dans leurs étapes finales. La livraison continue signifie que le logiciel peut être publié à tout moment, avec la décision de se déployer à gauche à l'équipe. D'un autre côté, le déploiement continu va plus loin en déploiant automatiquement les modifications de la production sans intervention humaine, à condition que tous les tests automatisés se soient écoulés.

Quels sont les avantages de la livraison continue?

Continu La livraison offre plusieurs avantages. Il permet des versions plus rapides et plus fréquentes, réduisant le risque, le temps et les efforts de déploiement de nouvelles fonctionnalités. Il permet également des commentaires rapides sur de nouvelles modifications, garantissant que tous les problèmes sont identifiés et traités rapidement. De plus, il encourage une culture de responsabilité partagée, où les développeurs sont impliqués dans tout le cycle d'un changement - de l'écriture de code au déploiement et de la surveillance en production.

Quels outils sont couramment utilisés dans la livraison continue?

Il existe plusieurs outils disponibles pour la mise en œuvre de la livraison continue, notamment Jenkins, Bamboo, TeamCity et Circleci. Ces outils fournissent des fonctionnalités pour la création d'automatisation, les tests et le déploiement, aidant les équipes à automatiser leur pipeline de livraison.

Comment puis-je implémenter une livraison continue dans mon projet?

La mise en œuvre de la livraison continue implique plusieurs étapes. Tout d'abord, vous devez configurer un système de contrôle de version pour votre base de code. Ensuite, vous devez automatiser vos processus de construction et de test à l'aide d'un serveur d'intégration continue. Ensuite, vous devez automatiser votre processus de déploiement, en vous assurant que votre logiciel peut être publié à tout moment. Enfin, vous devez surveiller votre application en production pour identifier rapidement les problèmes.

Qu'est-ce qu'un pipeline de déploiement dans la livraison continue?

Un pipeline de déploiement est le chemin qu'un changement de code emprunte à partir du La machine du développeur à l'environnement de production. Il implique plusieurs étapes, notamment commettre, construire, tester et déploier, chaque étape conçue pour attraper différents types de problèmes.

Quel est le rôle des tests automatisés dans la livraison continue?

Automated Les tests jouent un rôle crucial dans la livraison continue. Il garantit que les modifications de code ne cassent pas les fonctionnalités existantes ou n'introduisent de nouveaux bogues. En exécutant des tests automatiquement pour chaque changement, les équipes peuvent prendre et résoudre les problèmes tôt, réduisant le risque de problèmes de production.

Comment la livraison continue est-elle liée à DevOps?

La livraison continue est une pratique clé en pratique Dans DevOps, une culture et un ensemble de pratiques qui visent à raccourcir le cycle de vie du développement logiciel et à fournir une livraison continue avec une qualité logicielle élevée. En automatisant les processus de construction, de test et de déploiement, la livraison continue aide à décomposer les barrières entre le développement et les opérations, favorisant une culture de responsabilité partagée.

Quels sont les défis de la mise en œuvre de la livraison continue?

La mise en œuvre de la livraison continue peut être difficile. Cela nécessite un changement de mentalité significatif, ainsi que des modifications apportées à vos processus de développement et d'exploitation. Certains défis courants comprennent la mise en place de l'automatisation nécessaire, la gestion de la fréquence accrue des versions et la garantie que votre équipe a les compétences et les connaissances nécessaires.

Comment puis-je surmonter les défis de la mise en œuvre de la livraison continue?

Surmonter les défis de la livraison continue implique une combinaison de changements techniques et culturels. Du côté technique, vous devez investir dans l'automatisation et l'outillage et vous assurer que votre équipe a les compétences nécessaires. Du côté culturel, vous devez favoriser une culture de responsabilité partagée, où tout le monde est impliqué dans le processus de livraison et se sent propriétaire de la qualité du logiciel.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!