Est-il recommandé de déployer un projet sur le serveur fichier par fichier manuellement?


26

L'entreprise pour laquelle je travaille ne met pas encore en œuvre la livraison continue. Nous déployons toujours le projet manuellement sur le serveur, fichier par fichier. Quelle est la meilleure pratique: déployer manuellement un artefact de projet pour chaque déploiement ou poursuivre le déploiement fichier par fichier?


12
Il n'y a même pas à distance une "pratique unique pour toutes les situations" pour cette tâche.
whatsisname

26
Normalement, je lierais à Pourquoi poser une question sur les «meilleures pratiques» est-il une mauvaise chose? Je pense que nous pouvons tous convenir qu'il s'agit de la pire pratique. Il se classe légèrement au-dessus de «mettre le feu au serveur».


9
Je soupçonne que OP pose cette question parce qu'il connaît déjà la réponse, et son lieu de travail est Doing It Wrong (tm), et OP essaie de recueillir des preuves pour justifier la modification de la façon dont ils font les choses.
user1936

2
Nous l'avons fait de cette façon au deuxième millénaire. Ça devrait aller! ;)
Don Branson

Réponses:


103

Quelle est la meilleure pratique? déployer manuellement un artefact de projet à chaque déploiement ou continuer à faire le déploiement fichier par fichier?

Ni.

La meilleure pratique consiste à automatiser votre déploiement, complètement et exclusivement. Cela signifie que personne ne peut rien mettre manuellement sur un serveur.

"Pour résumer le résumé du résumé: les gens sont un problème." (Douglas Adams)

Les gens font des fautes. Si l'un des fichiers que vous oubliez de copier est une "bibliothèque" partagée qui a été profondément modifiée, vous pouvez faire planter l'ensemble du site de production.


17
@JohnHamilton Si l'automatisation de la compilation est une tâche difficile, alors c'est quelque chose à résoudre à long terme. Vous n'avez pas besoin d'avoir des environnements de développement, de test et de préproduction complets avec un déploiement complètement automatisé, mais la création d'un package de déploiement standard devrait être une pratique standard.
Neil

20
Euh, la taille de l'entreprise n'est pas vraiment le problème (dans une certaine mesure). Le coût va être lié à la mesure dans laquelle le déploiement est automatisé et également à la complexité de l'environnement de production. Mais il y a un gradient d'automatisation et un gradient de "coût" (temps / argent) à partir de choses simples comme un script pour copier la sortie du build sur la production (petit investissement avec des économies de coûts tangibles immédiates), et en augmentant à partir de là, et c'est plus dépendant sur le rachat de la direction que la taille de l'entreprise.
BurnsBA

39
@JohnHamilton: Une petite entreprise mal gérée pourrait se tromper en pensant cela, bien sûr. L'automatisation de la copie de fichiers n'est pas exactement une tâche difficile, et le coût d'avoir une personne employée à le faire régulièrement dépassera largement le coût de l'écriture, même du script le plus trivial pour le faire à la place.
GManNickG du

8
@JohnHamilton: Le coût de l'automatisation doit être mis en balance avec le risque d'erreurs commises lors du déploiement manuel.
Robert Harvey du

7
Vous n'avez même pas nécessairement besoin de Jenkins. Juste un script enregistré avec un tas de commandes scp (ou tout ce que vous utilisez lors du téléchargement manuel) serait une amélioration.
user253751

14

Les étapes manuelles demandent beaucoup d'efforts et sont risquées: vous pourriez oublier un fichier nécessaire. Peut-être que tout le monde dans votre équipe ne sait pas quels fichiers doivent être copiés. Tous ces problèmes rendent les déploiements importants, intimidants et rares - complètement inutilement. L'automatisation résout ces problèmes.

Même l'étape d'automatisation la plus simple peut avoir de gros avantages, car les déploiements deviennent triviaux. Un script qui copie les fichiers ou les artefacts via (S) FTP ou Rsync ou une autre technologie est une excellente première étape. Vous pouvez ultérieurement développer ce script pour effectuer automatiquement les étapes de pré-déploiement et de post-déploiement sur le serveur, comme le redémarrage des services.


Si le nombre total de serveurs est de 2 ou moins, le manuel est moins risqué qu'automatique. Automatique nécessite une vérification approfondie des bogues. Je n'ai jamais vu une solution automatique triviale qui est restée triviale.
Joshua

3
@Joshua Je ne suis pas sûr que le nombre de serveurs devrait être un facteur ici. L'automatisation a également de la valeur lorsque vous déployez plusieurs fois sur le même serveur. La question est, à qui faites-vous le plus confiance: l'ordinateur pour exécuter fidèlement un script qui a fonctionné une fois, ou votre capacité à vous souvenir de toutes les étapes nécessaires à chaque fois? En tant qu'humain faillible et oublieux, j'ai une forte préférence pour ne pas faire les choses manuellement. Parfois, je script même des tâches ponctuelles juste pour que je puisse revoir les commandes avant de les exécuter. C'est beaucoup moins risqué que de faire des choses au hasard manuellement jusqu'à ce que ça marche!
amon

J'ai une vaste expérience dans les deux sens. Ce que je fais pour le déploiement manuel est l'installation de xcopy, donc il n'y a vraiment pas d'étapes à oublier.
Joshua

9

La meilleure pratique serait de mettre en œuvre un processus automatisé quelconque.

Veillez à vérifier qu'il n'y a pas de raison particulière à l'approche «fichier par fichier» dont vous devriez tenir compte.


1
Je pose cette question parce que je veux juste m'assurer que ce n'est pas du tout la meilleure pratique au monde. Je me demande s'il y a encore des entreprises / développeurs qui déploient toujours manuellement leurs applications / projets, et ce qui aggrave, c'est le déploiement fichier par fichier à chaque itération de développement.
Jake Muller du

4
La meilleure question à poser est "pourquoi faisons-nous de cette façon?" Je ne peux pas penser à une raison, mais je sais que certaines entreprises aiment garder une main manuelle sur la gâchette pour ainsi dire
Ewan

8
@JakeMuller Ce que vous devez lire entre les lignes de cette réponse, c'est que les décisions doivent être prises en raisonnant sur la situation, et non en adhérant servilement à ce que quelqu'un sans le savoir a déclaré toujours la bonne réponse.
Blrfl

L'approche fichier par fichier pourrait être due au fait que les dépendances entre les fichiers et donc les mises à jour de fichiers sont déployées avant les modifications apportées à d'autres fichiers qui dépendent de ces fichiers. La mise à jour des fichiers dans le mauvais ordre peut freiner brièvement le système.
bdsl

6

Avec la livraison continue (ou le déploiement, en fait) et le déplacement de chaque fichier à la main, vous regardez les deux extrêmes. Il est parfaitement compréhensible que vous ne puissiez pas / ne souhaitiez pas (encore) créer un pipeline entièrement automatisé. Cependant, vous devriez envisager d'automatiser certaines parties du processus.

Déplacer chaque fichier à la main est assez risqué, et vous pouvez atténuer ce risque, par exemple, en marquant votre référentiel de code, en vérifiant cette balise sur votre ordinateur, en construisant vos artefacts et en les téléchargeant sur votre serveur. Chacune de ces étapes peut être automatisée pour être exécutée en quelques clics de souris, ce qui réduira considérablement le risque d'oublier un fichier ou de pousser accidentellement pour produire des fichiers supplémentaires.

Automatisez ce que vous pouvez, une étape à la fois. Le fait que vous ne puissiez pas vous permettre un pipeline de CD entièrement automatisé ne devrait pas vous décourager d'automatiser certaines pièces.


1

La meilleure pratique serait de faire une analyse coûts / avantages pour votre déploiement particulier pour votre entreprise particulière.

La réponse générale est «ne faites pas les choses manuellement, automatisez». C'est généralement la bonne réponse pour les types d'entreprises générales. L'uniformité des réponses que vous recevez devrait indiquer à quel point la communauté considère qu'il s'agit de meilleures pratiques. Si votre entreprise estime que l'automatisation n'est pas le bon outil, elle devrait avoir une idée de ce qui les rend uniques. Cette spécificité doit être prise en compte dans votre processus décisionnel. Il n'y a pas de "meilleures pratiques" lorsque l'échantillon est égal à 1.

Des questions telles que «combien de fichiers» et «à quelle fréquence les choses sont-elles mises à jour» et «quelles sont les conséquences de casser des choses» et «à quelle vitesse pouvez-vous annuler une mauvaise modification» sont des questions importantes auxquelles il faut répondre. Si vous automatisez, bon nombre de ces questions deviennent sans importance, mais elles sont essentielles pour affecter correctement les coûts et les avantages d'un processus de mise à jour manuelle.


1

Il existe de nombreuses nuances de gris entre la copie manuelle fichier par fichier et la livraison continue.

Commencez par réduire la complexité du processus de déploiement, par exemple en utilisant un fichier zip, un package de style rpm, une infrastructure comme outil de gestion de code (comme marionnette ou chef) ou même simplement un simple script qui copie les fichiers pour vous à partir d'un zone de transit sur le serveur ftp.

Les processus de déploiement comportant plus d'étapes manuelles sont plus susceptibles de comporter des erreurs (et donc d'échouer) - comme d'autres l'ont dit, supprimez l'élément humain.

Vous n'avez pas besoin de mettre en œuvre une livraison continue complète (ce qui est coûteux et nécessite des efforts / investissements / innovation au fil du temps) - commencez simplement, faites-le fonctionner, démontrez les avantages - et continuez à partir de là.


0

Cela dépend de la technologie logicielle (ou pile) que vous utilisez (langage interprété, langage compilé, application de bureau, mobile, etc.), logiciel. dev. les politiques du service, si vous avez les outils pour l'automatiser, à quel point votre application est critique, et une chose importante à considérer est votre architecture logicielle (comment votre application a été conçue). C'est pourquoi vous avez ici des réponses différentes. En règle générale, la meilleure approche sera de réduire au maximum l'intervention humaine dans les tâches de déploiement, afin d'éviter les erreurs. Une bonne pratique consistera à tester tout sur un serveur QA (pensez à utiliser un serveur virtuel si le budget est un problème) avant le déploiement, et à avoir des procédures inverses pour restaurer la version précédente en cas de catastrophe ( TOUJOURS avoir une sauvegarde).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.