Share
Il était une fois un fichier. C'était sur votre ordinateur et vous vouliez l'avoir sur un serveur.
Vous êtes-vous déjà demandé pourquoi il y a tant de façons de le faire? Nous expliquerons certaines des bases du déploiement dans cet article afin que vous sachiez quand utiliser quoi. Commençons!
FTP ou Protocole de transfer de fichier, est considéré par beaucoup comme le moyen traditionnel de "mettre en place un site". Il s’agit d’un protocole, ce qui signifie qu’il existe un ensemble de règles sur lesquelles l’ordinateur local et la machine hôte s’accordent et peuvent envoyer des messages. FTP n'est pas un "programme" en soi, mais plutôt une ligne téléphonique.
Donc, si FTP est une ligne téléphonique old-school (qui fonctionne toujours très bien), SFTP est comme un réseau 4G
Il offre un nouveau protocole pour que les deux machines puissent parler (non pas que ce soit nécessairement plus rapide, cependant). SFTP est alimenté par SSH, qui crypte essentiellement les messages transmis entre les deux ordinateurs; de sorte que tout réseau tiers malveillant ou réseau non sécurisé ne peut pas récupérer vos données brutes pendant le transfert.
Si vous n'avez pas tout à fait compris, FTP et SFTP sont tous deux des protocoles de transfert de fichiers. Cependant, SFTP (et d’autres protocoles de transfert utilisant SSH) transfère des fichiers et chiffre le transfert. "Je n'ai pas besoin de cryptage", pourriez-vous dire. Beaucoup de gens pensent de la même façon. Cependant, les développeurs avant-gardistes et les outils modernes se tourneront vers des méthodes plus sécurisées. Vous l'avez entendu avant - Mieux vaut prévenir que guérir.
Mais je n'ai pas envie de passer à travers les ennuis.
Tout d’abord, s’il s’agit de votre travail, faites-le chier. Vous pouvez soit rester avec votre zone de confort (vous savez, le FTP fonctionne toujours, tout comme votre téléphone fixe). Mais tu ne veux pas aller mieux? Après tout, c’est pour ça que vous êtes ici, à droite?
Maintenant, si vous êtes encore un peu paresseux mais que vous aimez l’idée d’une adoption facile, vous pouvez utiliser SFTP avec presque tous les clients FTP. C'est plus sécurisé. Assurez-vous que votre serveur prend en charge SSH (le port 22, généralement, doit être ouvert), et vous devriez être prêt à partir. Mais le but de cet article n'est pas de vous amener à penser au cryptage et à la sécurité des transferts; c'est pour vous faire penser à une stratégie de déploiement plus robuste.
"Mais je n'ai pas envie de passer à travers les ennuis." ... si c'est ton travail, laisse tomber
Si vous développez depuis un certain temps, vous avez probablement déjà explosé en créant un site et en glissant / déposant constamment vos fichiers sur votre client FTP (ou en double-cliquant ou en appuyant sur "sync", ou ...). Ce est techniquement, une stratégie de déploiement, même si elle n’est pas très robuste. Bien sûr, bien souvent, ce type de stratégie fonctionnera bien, en particulier si vous êtes la seule personne à jamais toucher aux fichiers et que vous n'avez jamais, comme par magie, écrasé ou supprimé un fichier important. Mais, encore une fois, vous êtes ici pour aller mieux, non? Et tu es un magicien.
Déploiement, dans sa forme la plus simple, prend du code et le rend "live". En transférant un index.html fichier dans votre répertoire de service, vous déployez. En fait, à la fin de la journée, toutes les stratégies de déploiement (sauf si vous utilisez un système d'application compilé) déplacent essentiellement des fichiers ou des versions de fichiers dans le "répertoire de travail en cours" ou modifient ceux qui sont déjà présents. Par exemple, vous pouvez apporter des modifications à cette même index.html fichier directement sur le serveur, ce qui "déployerait" efficacement ces modifications sur le public. Mais le déploiement peut être beaucoup plus.
Votre équipe a-t-elle déjà configuré un système vous obligeant à informer tout le monde lorsque vous avez transféré un fichier sur le serveur via FTP? Ou peut-être devez-vous redémarrer un serveur Django ou Rails après avoir changé de code. Si vous faites cela dans le cadre de la routine consistant à faire en sorte que votre site reflète les modifications que vous avez apportées, cela fait partie de votre processus de déploiement..
Ainsi, si déployer signifie faire vivre un ensemble de codes et de fichiers, comment peut-il y avoir beaucoup plus que SFTP? "Qu'est-ce que Git et pourquoi devriez-vous vous en soucier?" vous demandez. Git est un système de contrôle de version, ou un VCS. C'est l'un des nombreux VCS que nous avons choisi sans vergogne parmi nos préférés. Nous expliquerons pourquoi plus tard, mais parlons d'abord de quoi il est.
Les systèmes de contrôle de version accomplissent beaucoup de tâches, mais le plus important est de fournir un filet de sécurité aux développeurs, en particulier aux équipes de développement. Nous avons mentionné précédemment comment FTP et SFTP peuvent parfaitement fonctionner si vous êtes parfait et que vous n'écraserez jamais un fichier ni ne supprimerez un dossier important par inadvertance. Mais si vous ne l'avez pas encore fait, ne vous inquiétez pas, cela arrivera tôt ou tard. Il est presque certain que cela est arrivé à votre équipe si vous n’avez pas trouvé de solution de rechange. Mais même ces solutions de contournement sont pénibles. Par exemple, votre répertoire CSS a-t-il déjà ressemblé à ceci?
Si oui, vous gardez les versions des feuilles de style que vous finirez par fusionner ensemble. Incidemment, Git le fait, mais il le fait beaucoup mieux, plus rapidement et avec plus de robustesse que vous ne le pouvez vous-même. Conservez-vous un fichier CSS différent chaque fois que vous apportez quelques modifications? Juste au cas où vous voudriez revenir exactement sur la situation de ce fichier à un moment donné? Bien sûr que non. Mais Git fera exactement cela pour vous, et vous n'aurez pas de fouillis de fichiers éparpillés et de systèmes de nommage obscurs partout. Au-delà de cela, Git est assez intelligent pour savoir comment prendre votre styles.css déposer et fusionner avec Mary ou John styles.css fichier. De plus, les versions de Git sont ne pas des fichiers entiers; au lieu de cela, ils sont stockés dans deltas, qui est essentiellement une représentation de code de bas niveau des différences entre un fichier et un autre fichier. Cela signifie que les différentes versions sont beaucoup plus petites et beaucoup plus rapides à transférer lorsque vient le temps de les déployer..
Mais rien de tout cela n'a à voir avec le déploiement, vous dites? Vous avez raison, les systèmes de contrôle de version font en grande partie ce que leur nom suggère: gardez les versions dans l’ordre. Mais, ils ont également la capacité de communiquer à travers les différents protocoles dont nous avons déjà parlé. Git peut lire via HTTP et lire et écrire via SSH. (En savoir plus sur les protocoles de transfert ici.)
Ainsi, si Git dispose de ces connexions directes via des protocoles de transfert, vous pouvez transférer des versions avec votre équipe via un serveur local, GitHub ou votre propre serveur live. Et c'est ainsi que Git s'inscrit dans le déploiement. Vous poussez votre code, Mary et John poussent leur code, puis le responsable du déploiement de votre équipe se connectera au serveur et fusionnera le code dans l'environnement réel. Git offre la possibilité d’avoir plusieurs destinations et branches de code pour transférer différentes versions à différents endroits. Une pratique courante consiste à avoir un serveur "intermédiaire", dans lequel le code est poussé pour le vérifier dans un environnement réel sur un domaine de développement privé. Un autre flux de travail possible est de ne jamais connecter les référentiels locaux de votre équipe au référentiel actif, mais de permettre uniquement à la machine intermédiaire de pousser vers le serveur actif. Cela crée un système de révision qui ne peut pas être ignoré.
Les différentes versions sont beaucoup plus petites et beaucoup plus rapides à transférer lorsque vient le temps de les déployer.
Au-delà de la staging, des branches, des destinations de déploiement multiples et du contrôle de version robuste, Git propose des points d'ancrage, tels que "post-receive", qui permettent d'exécuter n'importe quel type d'action. Peut-être souhaitez-vous une branche "spider", où, lorsque le code arrive à un point de votre serveur, la réception de messages le pousse sur plusieurs emplacements (distant ou autre). Encore plus loin, utiliser une plate-forme comme GitHub offre une excellente interface graphique pour la mise en place de points d'ancrage. Dites facilement à GitHub de vous envoyer des courriels (ou si vous êtes créatif, créez une notification Growl) chaque fois que vous recevez un push d'un membre de l'équipe, par exemple.
Il y a littéralement des milliers de façons de développer une stratégie de déploiement avec Git. Vous pouvez rapidement constater qu’utiliser un VCS pour le déploiement offre des avantages, une protection et une puissance très étendus à votre déploiement. Une fois que vous aurez pris le temps d’en apprendre suffisamment sur Git pour mettre en place un flux de travail (et y faire quelques erreurs), votre processus de développement en profitera énormément..
Les commandes suivantes vont configurer un référentiel sur une machine distante, configurer un référentiel sur votre machine locale, ajouter le référentiel distant en tant qu '"origine", extraire une branche appelée "mybranch" qui sera fusionnée sur le serveur, pousser "mybranch" sur la télécommande, "origine", et se reconnecte enfin sur le serveur pour fusionner "mybranch" avec la branche "maître" par défaut.
local> ssh nomutilisateur@remotemachine.com remote> cd chemin / vers / projet distant / chemin / vers / projet> git init distant / chemin / vers / projet> quitter local> cd chemin / vers / local / projet local / chemin / vers / local / projet> git init local / chemin / vers / local / projet> git add. local / chemin / vers / local / projet> git commit -m "initial commit" local / chemin / vers / local / projet> git checkout mybranch local / chemin / vers / local / projet> git remote ajouter origine nomutilisateur@remotemachine.com : chemin / vers / projet local / chemin / vers / local / projet> git push origine mybranch local / chemin / vers / local / projet> ssh nomutilisateur@remotemachine.com distant> cd chemin / vers / projet distant / chemin / vers / projet> git merge mybranch
Au-delà de la création de votre propre flux de travail basé sur Git et de son intégration dans votre propre serveur, vous pouvez utiliser d'autres services gratuits, tels que Heroku ;. Heroku est une solution d'hébergement qui vous permet d'exécuter quelques lignes à partir de votre application contrôlée par Git et de la déployer sur le "cloud" (dans ce cas, un cluster de serveurs Linux distant) sur Git presque sans effort. Prenez quelques minutes pour configurer quelques éléments et passez à la course avec quelques lignes de code pour un déploiement simple. Sérieusement, ça ressemble à ça.
# travaillez, gardez le contrôle de version avec Git… puis> heroku create --stack cedar # the --stack cedar vous permet de créer plusieurs types d'applications, y compris PHP et Node #… Heroku vous dira qu'il crée des choses , alors il vous dira qu’il a ajouté une télécommande heroku à votre dépôt git> git push heroku master # et le tour est joué! Ouvrez l'application déployée dans votre navigateur> heroku open
Parmi les autres outils similaires, citons Pagoda Box, axée sur les architectures basées sur LAMP, et AppFog et PHPFog, très similaires à Heroku..
Tant qu'il n'y a pas d'erreurs dans votre configuration et que vous avez suivi les instructions de Heroku concernant la configuration d'applications, vous pouvez installer Rails, PHP ou les applications de nœud en quelques instants. Oh, et avons-nous déjà mentionné le fait que vous pouvez créer gratuitement de simples applications basées sur Heroku? Ce n'est que lorsque vous effectuez une mise à niveau vers plus d'instances ou de mémoire, ou que vous devez ajouter une base de données, que des frais sont facturés par Heroku. Parmi les autres outils similaires, citons Pagoda Box, axée sur les architectures basées sur LAMP, et AppFog et PHPFog, très similaires à Heroku. Ces options offrent des services similaires et une intégration Git, avec des structures de tarification différentes. Les trois offrent une option gratuite pour une puissance de serveur limitée. Il s'agit clairement d'avantages considérables, car il vous faut beaucoup de temps pour configurer votre propre serveur avec des architectures d'application plus complexes, telles que Rails ou Node. Au-delà de cela, la mise à l'échelle devient très simple, ces trois services offrant un équilibrage de charge et une mise à l'échelle vers plusieurs instances d'un simple clic. Ces services s’occupent de la lourde administration des serveurs pour vous, afin que vous puissiez vous concentrer sur la création d’applications, sachant qu’il existe une stratégie de déploiement bien documentée, sûre et rapide que vous pouvez utiliser lorsque vous êtes prêt à entrer en bourse..
Espérons que cet article a dissout une certaine confusion quant aux différences entre Git (et d’autres VCS) et FTP / SFTP, ainsi qu’à ce que signifie le concept de déploiement. J'espère également que cela vous a incité à élaborer votre propre stratégie de déploiement, avec l'aide d'outils tels que Git et Heroku. Si vous avez déjà une stratégie, que faites-vous pendant le déploiement??
Accentsconagua