Deployment bedeutet, eine Website von einer lokalen Umgebung auf Live-Server zu verschieben. Was wie eine einfache Sache erscheint, kann tatsächlich ziemlich komplex sein. Es gibt absolut unzählige Wege, dies zu tun. Sie reichen von benutzerfreundlicher Software und Diensten über komplexere Kommandozeilenwerkzeuge bis hin zu vollwertigen Systemen mit vielen beweglichen Teilen.
Ich bin kein Experte auf diesem Gebiet, aber ich habe im Laufe der Zeit einige verschiedene Deployment-Systeme eingerichtet und auch mit einer Reihe von verschiedenen gearbeitet. Ich dachte, wir könnten versuchen, so viel wie möglich hier zusammenzufassen und aufzuschlüsseln.
Direktes Arbeiten
Wenn Sie Dateien direkt auf Ihrem Server bearbeiten, entfällt im Wesentlichen jeder Deployment-Schritt. Dies können Sie mit einem FTP-fähigen Editor wie Coda oder Adobe Dreamweaver tun. Genug Leute machen das, dass beliebte Hoster wie Media Temple sogar Dokumentationen dazu haben, wie man es einrichtet.
Sie können sogar etwas wie WebDAV verwenden, um Ihren Remote-Server wie eine Festplatte zu mounten auf Ihrem lokalen Computer und Ihren bevorzugten lokalen Editor zu verwenden. Transmit hat eine "Disks"-Funktion, die dies sehr einfach macht.
Der Reiz liegt darin, dass man Ergebnisse so schnell live sehen kann. Allerdings wird dies generell missbilligt. Weil
- Es ist gefährlich, Fehler werden sofort bemerkt
- Es gibt keine Tests
- Es gibt keine Aufzeichnung von Änderungen – was/wer/wann
- Man kann Änderungen nicht rückgängig machen
- In Teams kann man die Arbeit anderer überschreiben
- Man kann keine großen, langfristigen Projekte ohne zusätzliche Einrichtung bearbeiten
Manuelles FTP verwenden
Eine sehr selbstgebastelte Deployment-Technik ist, einfach lokal zu arbeiten und die Dateien mit FTP-Software (wie Transmit) auf den Live-Server zu verschieben, wenn Sie bereit sind.
Das funktioniert zwar, kann aber mühsam sein. *Welche Dateien habe ich geändert? Ach, egal, ich schiebe einfach alles. Mann, das ist langsam.*
Das hat immer noch viele der gleichen Nachteile wie oben. Man riskiert immer noch, die Arbeit anderer zu überschreiben, man kann Änderungen nicht einfach rückgängig machen, etc.
FTP auf diese Weise zu verwenden bedeutet nicht automatisch, dass man keine Versionskontrolle nutzt, aber es ist wahrscheinlich. Wenn man es täte, würde man das völlig unabhängig verwalten und es würde sich extra mühsam anfühlen. Und immer noch nichts, was Sie daran hindert, einen Fehler zu machen (z.B. Dateien hochladen, bevor Sie aus dem Repo gezogen haben). Wenn Sie Versionskontrolle verwenden, suchen Sie wahrscheinlich bereits nach einem Weg, dies mit dem Deployment zu verknüpfen.
Das Thema Versionskontrolle
Versionskontrolle ist wichtig und spielt bei jeder anderen Deployment-Methode, über die wir sprechen werden, eine Rolle. Aber für sich genommen übernimmt die Versionskontrolle das Deployment nicht automatisch für Sie. Ohne zu sehr ins Detail zu gehen, Projekte werden in Repositories (oder „Repos“) gespeichert. Sie können mehrere Mitwirkende haben. Dateien werden synchron gehalten. Es ist die Aufgabe der Mitwirkenden, sicherzustellen, dass sie den neuesten Code haben und dass ihr neuer Code passt. Es gibt eine Aufzeichnung aller Änderungen.
Git ist wahrscheinlich das gängigste Tool zur Versionskontrolle, aber seien Sie sich bewusst, dass Subversion („SVN“) und Mercurial ähnlich sind und die gleiche Funktion erfüllen.
Versionskontrolle auf dem Server installieren, von dort ziehen
Versionskontrollsoftware ist eben genau das, Software. Sie ist wahrscheinlich nicht standardmäßig auf Servern enthalten, die Sie kaufen (selbst auf den „voll ausgestatteten“ Servern, die oft Dinge wie PHP automatisch mitbringen). Aber es ist auch wahrscheinlich, dass Sie sie auf diesen Servern installieren *können*.
Dann, genauso wie Sie von Ihrem lokalen Rechner aus git push und git pull ausführen können, können Sie sich per SSH auf den Server einloggen und von dort git pull ausführen, was die neuesten Dateien aus diesem Repo auf den Live-Server bringt.
Das ist im Grunde schon einfaches Deployment.
Jeremy Harris hat einen Artikel, der dies etwas erweitert und zeigt, wie Sie von Ihrem lokalen Rechner aus pushen und das .git-Verzeichnis aus dem Web-Root fernhalten. Joe Maller hat einen Artikel über die Verwendung eines „Hub“-Bereichs auf dem Server.
Cron Job
Ein Cron Job ist eine zeitgesteuerte/automatisierte Aufgabe auf einem Server. *Führe X alle 2 Minuten aus.* Ich habe Leute gesehen, die einen Cron Job ausführen, der alle paar Minuten Git-Pulls durchführt, und das ist ihre Deployment-Strategie.
Post-Receive Hooks / Webhooks
GitHub hat eine Funktion namens Post-Receive Hooks, bei der sie bei jedem Push auf ein Repo eine URL Ihrer Wahl POSTen. Sie könnten diese POST-Anfrage verwenden, um ein Skript auszuführen, das die für das Deployment benötigten Befehle ausführt, z. B. git pull.
NetTuts hat einen Artikel „The Perfect Workflow“, der erklärt, wie dies eingerichtet werden kann. Sie verwenden eine PHP-Datei, die den SSH-Befehl ausführt, was meiner Erfahrung nach von vielen Hostern ohne die Möglichkeit, dies zu erlauben, gesperrt wird.
Bitbucket, ein weiterer Versionskontroll-Host, bietet ebenfalls POST Service Management an.
Drittanbieter-Deployment-Webdienste
Es gibt einige Web-Apps, die ihr Geschäft damit machen, beim Deployment zu helfen.
Atlassian entwickelt BitBucket (Versionskontrolle) und Jira (Issue-Management), daher macht es Sinn, dass sie Bamboo entwickeln, das Deployments durchführt und die Produkte irgendwie miteinander verbindet.
Kommandozeilen-Interface (CLI) Tools
Eine schicke Art zu sagen: Werkzeuge, die durch Eingabe von Befehlen in das Terminal funktionieren. Sie haben typischerweise Konfigurationen, die Sie entweder in den Befehlen selbst übergeben, eine Konfigurationsdatei verwenden oder beides.
Capistrano
Capistrano ist nicht ausschließlich für Deployments gedacht. Es dient der Ausführung von Befehlen auf Servern. Deployment ist jedoch ein sehr häufiger Anwendungsfall dafür, und es entstand aus diesem Ursprung.
Capistrano wurde ursprünglich entwickelt, um die Bereitstellung von Webanwendungen in verteilten Umgebungen zu vereinfachen und zu automatisieren. Ursprünglich enthielt es eine Reihe von Aufgaben zur Bereitstellung von Rails-Anwendungen.
Es ist in Ruby geschrieben, kann aber für alles verwendet werden.
Wenn eine Website komplexer wird, reicht es wahrscheinlich nicht mehr aus, einfach Code aus einem zentralen Repo zu ziehen. Es können zum Beispiel mehrere Server beteiligt sein. Oder das Ziehen dieser Dateien kann einige Zeit dauern, und diese Zwischenzeit könnte Ihre App beeinträchtigen. Mit Capistrano können Sie es so konfigurieren, dass der Server vorbereitet, neue Dateien an einen neuen Ort gezogen, der Symlink aktualisiert, Berechtigungen bereinigt, Dienste neu gestartet und das alles auf mehreren Servern erledigt wird. Dieses Bild demonstriert das.
Es gab eine Web-Oberfläche dafür, aber sie scheint etwas veraltet zu sein.
RailsCasts bietet eine Reihe von Screencasts, um Capistrano kennenzulernen.
rsync
rsync beschäftigt sich ausschließlich mit Dateiübertragungen.
rsync ist ein Dateiübertragungsprogramm für Unix-Systeme. rsync verwendet den „rsync-Algorithmus“, der eine sehr schnelle Methode bietet, um entfernte Dateien zu synchronisieren. Dies geschieht, indem nur die Unterschiede in den Dateien über die Verbindung gesendet werden, ohne dass beide Dateisätze vorab an einem Ende der Verbindung vorhanden sein müssen.
rsync ist ein Befehl, daher wird er oft von einem Task-Runner wie Make oder häufiger Rake (da es auch Ruby ist) ausgeführt.
git-ftp
Vielleicht spüren Sie ein wiederkehrendes Thema
Anstatt das gesamte Projekt zu übertragen, dachte ich: Warum nicht nur die geänderten Dateien übertragen, seit dem letzten Mal kann Git mir diese Dateien sagen.
git-ftp pusht Dateien auf Ihren Server, genau wie jeder FTP-Client, aber es weiß genau, welche Dateien gesendet werden müssen, weil es Git verwendet, das es weiß.
git ftp push -u <user> -p - ftp://host.example.com/public_htmlDandelion
Dandelion ist ähnlich wie git-ftp, funktioniert aber über Konfigurationsdateien, so dass Sie genauer bestimmen können, was passieren soll und den Befehl vereinfachen (dandelion deploy). Es kann auch nach AWS pushen.
Ansible
Ansible konfiguriert Betriebssysteme, stellt Anwendungen bereit, führt parallele Befehle aus und orchestriert IT-Prozesse wie Zero-Downtime-Rollouts. Es verwendet standardmäßig SSH, sodass keine spezielle Software installiert werden muss, um mit der Verwaltung von Remote-Maschinen zu beginnen. Module können in jeder Sprache geschrieben werden.
grunt-ftp-deploy
Was Build-Tools/Task-Runner angeht, ist Grunt auf dem Weg zur Königsklasse. Es basiert auf Node.js, das einen eigenen Paketmanager (NPM) hat, ähnlich wie Ruby Gems.
Eine solche Seite ist grunt-ftp-deploy, die Dateien von Ihrem lokalen Rechner über FTP auf einen Server verschiebt. Sie konfigurieren die Aufgabe und führen sie dann einfach aus, wie immer Sie Grunt-Aufgaben ausführen möchten. Es ist eine ziemlich „dumme“ Aufgabe, da sie nicht einmal versucht, nur das zu verschieben, was sich geändert hat, oder Versionskontrolle zu referenzieren. Sie verschiebt einfach alles.
Statische Seiten
Eine „statische“ Website ist eine Website, die keine Dienste, Datenbanken oder Ähnliches benötigt. Nur ein Webserver und eine Reihe von Ressourcen-Dateien (z.B. .html, .css, .js, Bilder).
GitHub Pages
GitHub bietet einen Dienst namens GitHub Pages an, der statische Websites für Sie bereitstellt. Sie können sogar Ihren eigenen Domainnamen mit ihnen verwenden. Sie erstellen einfach einen Branch eines Repos namens gh-pages und es funktioniert irgendwie. Auf diese Weise ist das Deployment einfach nur das Pushen auf diesen Branch dieses Repos.
Es gibt einen Grunt-Task nur dafür.
Jekyll
Nur weil eine Website statisch ist, heißt das nicht, dass sie lahm/einfach/schlechte Architektur hat. Es gibt Build-Tools für statische Websites, mit denen Sie Vorlagen und Inhalte zusammenfügen und eine Website ausgeben können. Jekyll ist eines davon, das speziell für die Zusammenarbeit mit GitHub Pages entwickelt wurde.
Octopress
Octopress sitzt auf Jekyll auf und bietet Konfiguration, Vorlagen usw., damit Sie schneller starten können.
Weder Jekyll noch Octopress helfen unbedingt beim Deployment, sie sind nur sehr eng mit GitHub Pages verwandt, das eine Form des Deployments ist.
Amazon S3
Amazon bietet Webdienste an, mit denen Sie tatsächlich Server betreiben können, aber es gibt auch S3, das reine Dateispeicherung ist. Sie können tatsächlich eine statische Website auf S3 hosten und sogar Ihre eigene Domain verwenden.
Es gibt sogar eine Reihe von Kommandozeilenwerkzeugen namens s3cmd, die Sie konfigurieren und Befehle ausführen können, um statische Websites bereitzustellen (d.h. s3cmd sync).
Platform as a Service (PaaS)
Hoffentlich ist jetzt klar, dass selbst das Deployment kompliziert sein kann. Der gesamte Web-Plattform-Stack kann *extrem* kompliziert sein. Es ist kein Wunder, dass Unternehmen auf den Plan getreten sind und nun Dienste anbieten, um ihn zu vereinfachen. Diese Unternehmen bieten Hosting, Serververwaltung, Datenbanken und all diesen Kram an. Einfaches Deployment ist normalerweise Teil des Pakets.
git push heroku master.
Es gibt jede Menge PaaS auf Enterprise-Niveau. Sehen Sie sich SalesForce, RedHat und IBM für die Spitze des Eisbergs an.
In einer anderen Richtung: Mixture.io kümmert sich um Hosting/Deployment direkt aus seinem Desktop-Entwicklungstool heraus.
Continuous Integration Server
Von Wikipedia
Kontinuierliche Integration (CI) ist in der Softwaretechnik die Praxis, alle Entwickler-Arbeitskopien mehrmals am Tag mit einer gemeinsamen Hauptlinie zusammenzuführen.
Die Idee ist, dass einzelne Entwickler keinen Branch so lange ausgecheckt haben, dass er sich stark vom Haupt-Repo unterscheidet und das Zusammenführen der beiden schwierig wird.
Die Ausweitung dieses Konzepts auf den Server bedeutet, diesen Code auf tatsächlichen Servern auszuführen, um sicherzustellen, dass alles in Ordnung ist. Führen Sie den Build aus – besteht er? Führen Sie Ihre Tests aus – bestehen sie? Dies oft zu tun bedeutet, Probleme frühzeitig zu erkennen und riesige, tiefe Probleme entwickeln sich nie.
Dies steht in Beziehung zum Deployment, da Leute es verwenden, um Code automatisch bereitzustellen, wenn alle Schritte erfolgreich sind. Zum Beispiel:
- Neuen Code in das Repo committen/pushen
- CI-Tool führt alle von Ihnen konfigurierten Builds/Tests aus
- Wenn alles passt, wird es bereitgestellt
- Wenn etwas nicht passt, werden Sie benachrichtigt und es erfolgt kein Deployment
Ich verstehe das eigentlich kaum, also korrigieren Sie mich bitte in den Kommentaren, wenn ich alles falsch mache. Es gibt eine Reihe verschiedener, daher werde ich sie auflisten, anstatt zu versuchen, etwas zu erklären, das ich nicht gut kann.
- Travis CI (funktioniert natürlich mit GitHub)
- Jenkins CI (kann so eingerichtet werden, dass es mit GitHub funktioniert)
- CircleCI
- Codeship
CMS-spezifisch
CMS haben heutzutage so riesige Communities, dass es nicht überraschend ist, dass Tools auftauchen, die spezifisch für sie sind und nicht nur für ihre übergeordnete Sprache.
WordPress
- WP-Stack ist eine Boilerplate für WordPress-Sites, die Git und Capistrano voraussetzt.
- WordPress-Starter ist ähnlich, enthält aber S3-Backups.
- Wir haben nicht viel über Datenbank-Deployment gesprochen. Ich bin mir nicht sicher, ob es viel darüber zu sagen gibt. Ich war immer überrascht, wie umständlich das Verschieben von Datenbanken ist. WP Migrate DB Pro ist ein gutes, spezifisches Tool für WordPress, um sie synchron zu halten.
Drupal
Drupal hat eine Kommandozeilenschnittstelle namens Drush, die ein Deployment-Skript namens Drush Deploy hat.
War's das?
Nein, wahrscheinlich nicht. Ich habe nicht einmal Dinge wie Puppet und Salt Stack erwähnt, die ich nicht einmal wirklich verstehe.
Fühlen Sie sich frei, in den Kommentaren mit zusätzlichen Informationen, Dingen, die ich falsch gemacht habe, Dingen, die ich übersehen habe, oder wie Sie das Deployment handhaben, beizutragen.
Wir verwenden in meinem aktuellen Büro Continuous Integration. Genauer gesagt TeamCity.
Ich weiß auch nicht viel über das gesamte CI-Ding. Mein Manager möchte es so halten, dass niemand irgendeine Art von Branches erstellen darf, außer in sehr speziellen und seltenen Fällen, also passt das wohl zu dem, was Sie über niemanden sagten, der das Repository zu lange ausgecheckt hat, aber das gefällt mir nicht, weil es viele Vorteile der Verwendung von CVS zunichtemacht.
Ich frage mich, ob andere Leute, die mit CI arbeiten, dieses Problem haben, oder ob es nur mein Fall ist, dass die Einschränkungen die Arbeit erschweren.
Beste Grüße
Ich habe mich selbst auf dieses Abenteuer eingelassen und mir das Ganze aus CLI-Perspektive angesehen.
Diese 3 Befehle sind die Grundlage für jeden Dateiübertrag aus einer Terminal-Shell. Es sollte bekannt sein, dass
rsyncnicht am besten darin ist, Dateien zu verfolgen, wie es Git erreicht, indem es erkennt, wenn Dateien nicht mehr vorhanden sind oder sich von der Originalquelle unterscheiden.wgetfunktioniert großartig, aber für einzelne Abrufszenarien und Einwegkommunikation – ganz zu schweigen davon, dass Sie die URI jedes Mal kennen müssen, wenn Sie ihn ausführen.scpermöglicht das Kopieren von Dateien zu, von oder zwischen verschiedenen Hosts. Das bedeutet, es funktioniert großartig bei Zwei-Wege-Kommunikation. Es verwendetsshfür die Datenübertragung und bietet die gleiche Authentifizierung und das gleiche Sicherheitsniveau wiessh. Ich weiß nicht, wie es anderen geht, aberscpund der Rest davon klingt nach einer Menge Tipperei im Vergleich zur Verwendung einer GUI, aber wir können immer noch nicht ein ganzes Projekt oder eine Reihe von Unterverzeichnissen richtig synchronisieren. Hier sind SSH und POST HOOKS großartig, wenn Sie Git für das Deployment verwenden.Dennis, ich denke, du solltest dir rsync genauer ansehen. Es kann nicht nur gelöschte Dateien erkennen, sondern auch geänderte Dateien gleicher Größe anhand eines MD5-Hash erkennen. Es ist sehr schnell und ist wirklich das Einzige, was benötigt wird (SSH muss natürlich installiert sein). Es ist nichts Besonderes zu tun. Sie können per rsync herunterladen (Server zu lokal), um „Hotfixes“ zu erfassen (oft beheben wir Tippfehler oder andere Kleinigkeiten direkt per FTP), lokal zusammenführen, lokal testen und dann hochladen (neue Version der Website bereitstellen). Es ist sehr schnell und Sie müssen kein Repo auf Ihrem Produktionsserver pflegen (kein großes Ding, aber ich halte es lieber so schlank wie möglich). Ihre rsync-Befehle sind portierbar und Sie besitzen sie, sie sind leicht zu optimieren oder zu aktualisieren. Sie funktionieren mit OSX, Debian usw.
Bitte streichen Sie alle Deployment-Strategien, die FTP erfordern. Ich muss nicht erklären, warum...
Bitte erklären Sie, warum. Gibt es etwas Schlechtes daran, FTP zu verwenden, um versionierte Codes automatisch zu pushen?
Nebenbei bemerkt, ist es irgendwie lustig, dass FTP im Artikel so abgetan wird, als ob die überwiegende Mehrheit der Websites es nicht (zum Guten oder Schlechten) verwendet.
Es tut mir leid, aber das ist ein sehr schwaches Argument: „Tu das nicht, weil ich es sage.“
JA, ja, du musst erklären, warum, sonst wirkst du wie ein arroganter Spinner.
Wenn du genau liest, was Chris gesagt hat, empfiehlt er kein FTP – er erwähnt es nur als Option.
Toller Beitrag. Ich liebe es, dass du nie an Details sparst.
Mit Git kannst du Dateien auch direkt auf deinen Server pushen, so wie du es zu GitHub tun würdest. Ein gutes Tutorial, wie man das per SSH einrichtet, findest du hier von Arlo Carreon.
Das gesagt, ist Capistrano besser geeignet, wenn deine Website skaliert (denke an mehrere Server), aber das Pushen per Git ist großartig, wenn du nur den einen Server hast, auf den du deployst.
GIT ist sehr gut darin, auf mehrere Seiten gleichzeitig zu pushen. Ein Remote kann mehrere Upstream-URLs haben. Alle Server benötigen ein lokales Repository mit Post-Receive/Checkout-Hooks. Ich habe ein Repository, das auf 4 URLs pusht (1 ist Github, 3 sind Server).
Danke für den Beitrag, Chris. Dieses Thema interessiert mich definitiv, da ich gerne GIT verwende, aber leider verwenden viele Orte immer noch FTP für das Deployment. Ich kenne einen Weg, wie Leute dazu neigen, es „sicher“ zu spielen, indem sie separate Entwicklungs- und Live-Server haben. Das löst jedoch immer noch nicht das Problem der Nachverfolgung von Änderungen und des Zurücksetzens von Fehlern.
Ich bin tatsächlich zum GitHub Pages-Ansatz mit meiner Website übergegangen. Es funktioniert gut und ist für mich weitaus einfacher, als zu versuchen, meine lokale Kopie und meine Serverkopie synchron zu halten.
Ich würde gerne hören, was du für das Deployment auf css-tricks.com verwendest. Dreamweaver hatte früher ein rudimentäres „Check in/out“-System und verfolgte, welche Dateien du lokal geändert hast. Nicht so gut wie svn/git, aber nicht schlecht für ein kleines Webdesign-Team.
CSS-Tricks.com ist auf Beanstalk. Eines Tages würde ich darüber nachdenken, es auf GitHub zu verschieben, da es wirklich keinen Grund gibt, warum es privat sein müsste, und dann bekomme ich den Issue-Tracker und so weiter.
Fantastische Zusammenfassung, Chris!
Es könnte auch erwähnenswert sein, dass GitHub Pages ein kostenloser Dienst ist, was meiner Meinung nach ein großer Pluspunkt ist. Ich habe einen kleinen Beitrag darüber verfasst, wie man sich einrichtet, der jemandem helfen könnte: Deployment via GitHub for Free.
Ich verstehe nie, warum Leute so hart auf einem alten, aber zuverlässigen Protokoll wie http://FTP…sicher herumhacken, es ist alt… aber für Leute, die an kleinen Unternehmenswebsites arbeiten, mit Kunden, die kein Geld für Hunderte von Dollar pro Monat für Hosting auf einem dedizierten Server haben, kann FTP die einzige Option sein, um Dateien von einem lokalen Rechner auf einen gemeinsam genutzten Webserver zu übertragen… Lacht, wie ihr wollt, aber das ist die Realität für kleinere Websites… Nicht jeder arbeitet an einer großen Webanwendung…
Jeder, der direkt auf einem Live-Server bearbeitet, lebt gefährlich, da stimme ich zu…
git clone / git pull – im schlimmsten Fall 5 Minuten
ftp – mindestens 1-3 Stunden
Für ein Protokoll, das auf die Dateiübertragung spezialisiert ist, ist FTP Zeitverschwendung, wann immer ich Dateien senden möchte.
Bitte schaut euch https://deploybutton.com an. Ich fand es sehr einfach einzurichten. Es unterstützt mehrere Konfigurationen.
Eine noch bessere Lösung ist http://dploy.io/, da deploybutton scheinbar aufgegeben wurde.
Schöne Zusammenfassung. Aber du übersiehst Tools oder Umgebungen, die speziell für die Deployment-Automatisierung gedacht sind. À la LiveRebel, uDeploy, DeployIT, InRelease usw.
Pelican ist ein weiterer großartiger Generator für statische Websites (und/oder Blogs). Ich habe kürzlich ein Heroku-Buildpack erstellt, damit es hervorragend mit Heroku funktioniert.
http://getpelican.com/
Wow… dieser Beitrag hätte nicht zu einem besseren Zeitpunkt kommen können! Ich habe mich mit WordPress-Deployments mit Capistrano beschäftigt, aber es passt nicht zu den Servern, die wir verwenden, da wir an ihre Struktur gebunden sind und das Symlinking eine unordentliche Lösung darstellt.
Rsync hingegen funktioniert schnell und einfach und ist nicht voreingenommen!
Dieser Artikel beschreibt eine einfache Methode, um eine Rake-Aufgabe für WP-Deployments auszuführen
http://adamstacoviak.com/simple-wordpress-deployment-using-rake-and-rsync/
Abgesehen von Sass und Compass, die ich mit Grunt handhaben würde, ist das weitaus einfacher als die Einrichtung von Capistrano!
Dieser Artikel ist großartig für eine schnelle Referenz der wichtigsten Anliegen beim Rsync-Deployment
http://www.thegeekstuff.com/2010/09/rsync-command-examples/
Mit Git kannst du Dateien auch direkt auf deinen Server pushen, so wie du es zu GitHub tun würdest. Ich bin tatsächlich zum GitHub Pages-Ansatz mit meiner Website übergegangen. Es funktioniert gut und ist für mich weitaus einfacher, als zu versuchen, meine lokale Kopie und meine Serverkopie synchron zu halten.
Wir verwenden JIRA, Jenkins, GIT und GITHUB.
Wir erstellen ein Feature-Ticket oder ein Bug-Ticket in JIRA, dann erstellen wir einen Branch von unserer Hauptlinie mit dieser JIRA-Ticketnummer. Wir beheben den Bug oder wenn der Branch Feature-komplett ist, senden wir einen Pull-Request.
Dieser Branch wird dann in die Hauptlinie zusammengeführt und der Commit bezieht sich auf die JIRA-Nummer, und das JIRA-Ticket wird mit einem Link zum entsprechenden Commit aktualisiert.
Sobald das Ticket geschlossen ist, gehen wir zum nächsten über.
Wir haben wöchentliche Releases, dann verwenden wir am Ende der Woche Jenkins, um auf einen Staging-Bereich zu pushen… wir testen, dann pushen wir live. Dann fängt alles wieder von vorne an.
Hotfixes werden auf Branches von Staging gemacht und zurückportiert.
Es ist ein schöner, leicht verständlicher Workflow. Viele Kontrollen und Verantwortlichkeit.
Ich würde gerne wissen, ob jemand gute Vorschläge hat, wenn man Sourcesafe mit Sourcegear verwendet… oder nur Sourcegear, und keine Admin-Rechte auf dem Server hat, so dass man sich nicht anmelden kann, um eine „Neueste Version abrufen“ vom Server auszuführen.
Das Beste, was ich je geschafft habe, war ein „Neueste Version abrufen“ in ein neues Verzeichnis und dann das Ganze per FTP hochzuladen… Ja Eric, du hast gehört, ich habe FTP gesagt :)
Chris
Ich sehe nicht, wie heutzutage jemand ohne Versionskontrolle leben könnte. Ich kann mich nicht einmal an all die Male erinnern, in denen ich Änderungen vorgenommen habe, von denen ich dachte, sie seien gut, während sie etwas kaputt machten, das ich früher getan hatte. Ein Problem nicht sofort zu erkennen, ist ein großes Problem, aber es ist mit Versionskontrolle lösbar.
Obwohl ich sagen muss, dass ich immer noch keine Lösung gefunden habe, um die 3 Maschinen, auf denen ich arbeite, synchron zu halten. Ich habe A) das Büro, B) das Heimbüro, C) Laptop. Photoshop- und Illustrator-Einstellungen, Coda-Plugins, CodeKit-Websites/Einstellungen, Testserver in MAMP und alle Datenbanken für verschiedene WP-Websites synchron zu halten, ist harte Arbeit… Irgendwelche Tipps, wie man das alles schafft? :-)
Hallo Patrik,
Ich benutze Dropbox zum Synchronisieren zwischen Computern. Es ist eigentlich sehr einfach, wenn man es richtig einrichtet. Ich habe vor einiger Zeit einen Artikel über meine Einrichtung geschrieben. Schau ihn dir an, wenn du möchtest… Dropbox Sync for Development
Hinterlasse einen Kommentar, wenn du Fragen hast.
Patrik, ich denke, die Lösung für dich heißt „Dropbox+Hardlinks (Aliase)“ oder jeder andere ähnliche Dienst, z.B. Sugarsync ;)
@Chris Danke, das ist eine schöne Lösung für den MySQL-Teil, aber ich muss auch herausfinden, wie ich Coda-Website-Einstellungen, Coda-Plugins usw. synchronisiere. Ich kann dieses Problem wahrscheinlich auch mit Symlinks lösen – aber es scheint so zeitaufwendig zu sein, es einzurichten.
Ich überlege ernsthaft, die beiden iMacs abzuschaffen und stattdessen 27″ Cinema Displays zu verwenden und nur noch den Laptop zu nutzen. Dann müsste ich aber das Problem lösen, dass ich den Laptop **immer zu Hause vergesse**… :)
Niemand sollte ohne irgendeine Form der Versionskontrolle auskommen.
Ich stimme Chris' Antwort zu: Dropbox ist für all die anderen Dinge (Grafiken, Schriften, Einstellungen), die wir zwischen Rechnern synchron halten müssen, nahezu perfekt. Technisch gesehen kann Git auch funktionieren, aber dann werden Repos ziemlich groß. Adobe-Einstellungen… darüber bin ich mir nicht sicher. Ich bin neugierig auf Bittorrent Sync als Möglichkeit, verschiedene Verzeichnisse zu synchronisieren.
Datenbanken synchronisieren, das ist ein anderes Problem. Deshalb habe ich mit Statamic angefangen zu entwickeln: Flat-File, keine Datenbank. Viel einfacher, alles synchron und versionskontrolliert zu halten.
Du hast die 2, die ich benutze, nicht erwähnt
RPM/Yum (für unsere Webanwendungen) und Erica (für CouchDB CouchApps)
Das ist eine Variation der „Going Commando“-Technik. Wenn ich an einer zweiten Version einer Website arbeite, richte ich manchmal einfach einen neuen virtuellen Serverdatensatz auf dem Produktionsserver ein und gebe ihm eine Subdomain (zum Testen). Wenn ich dann bereit bin, live zu gehen, bearbeite ich einfach die virtuellen Serverdatensätze auf dem Server und lade Apache neu. Mit dieser Technik verschiebe ich keine Dateien und erstelle keine neuen Datenbanken, um live zu gehen. Ich ordne nur neu an, welcher virtuelle Server Entwicklung und welcher Produktion ist. Ein Vorbehalt bei WordPress-Websites ist, dass du das Entwicklungssystem so konfigurieren müsstest, dass es eine andere Site-URL hat. Das ist recht einfach, indem du die WP_SITEURL-Konstante in wp-config setzt.
Für WordPress-Websites habe ich gerade mit der Einrichtung von lokaler Entwicklung und Deployment mit DesktopServer von http://serverpress.com/products/desktopserver/ begonnen.
Es basiert auf XAMPP und deployt direkt ohne FTP. Es scheint also ein einfacher Prozess für Leute zu sein, die solo arbeiten. Irgendwelche Gedanken dazu?
Ich benutze tatsächlich Dropbox für meine Deployments. Es ist super praktisch und ich kann trotzdem Versionskontrolle darüber nutzen….
Grundsätzlich habe ich zwei Ordner in Dropbox eingerichtet, einen Entwicklungsordner und einen Produktionsordner. Die Live-Website wird aus dem Produktionsordner bedient, und meine Entwicklungsmaschine bedient aus dem Entwicklungsordner. Wann immer ich bereit bin, in die Produktion zu pushen, benutze ich Versionskontrolle, um die beiden Ordner zu synchronisieren, und das war’s. Wenn ich jemals kleine oder einfache Änderungen an der Produktionswebsite vornehmen muss, bearbeite ich einfach den Inhalt des Ordners und synchronisiere ihn später mit der Entwicklung.
Vielleicht nicht die sicherste Methode, aber es ist schön, nie SSH oder Remote zu einer anderen Maschine verbinden zu müssen…
Toller Beitrag! Eine weitere schöne Möglichkeit, über eine SSH-Verbindung zu deployen, ist die Verwendung von Fabric.
Ein weiteres großartiges Tool, das viel vom Risikofaktor beseitigt, ist RapidWeaver. Die Themes, die es mitbringt, sind nicht sehr beeindruckend, aber es gibt viele Drittanbieterentwickler, die viele erstellen. Es funktioniert ähnlich wie FTP in einem Sinne, aber auch nicht, du erstellst und bearbeitest Seiten lokal und kannst eine Vorschau sehen, wie sie in jedem installierten Webbrowser erscheinen. Dann lädst du hoch, wenn du bereit bist. Es ist aber nur für Mac.
Das ist eines dieser Themen, über die Entwickler sich bis zur Unendlichkeit streiten können. Es gibt so viele Möglichkeiten zu deployen und jede Situation ist einzigartig. Ich schätze die Bandbreite der Optionen, die du hier vorgestellt hast – sowie die Kommentare anderer Leute darüber, was für sie funktioniert.
Es hat eine Weile gedauert, bis ich einen Workflow gefunden habe, der für mich funktionierte – also, wenn jemand das hier liest und sich von den Auswahlmöglichkeiten und starken Meinungen überfordert fühlt, entspannt euch – ihr müsst etwas finden, das für euch und eure Organisation/Kunden/Team/etc. funktioniert. Es muss keine Raketenwissenschaft sein (aber es könnte eine sein, wenn du willst!).
Was es wert ist, meine Präferenz ist das Pushen nach Github/Bitbucket, dann das Ziehen von einem Staging-Server, dann das Rsynching zu Produktion. Für Medien und dergleichen, die außerhalb des Repos liegen, verlasse ich mich auf SSH und SFTP auf benutzerdefinierten Ports.
Schau dir das an, Laravel Deploy.
http://anahkiasen.github.io/rocketeer/
Wow. Faszinierend.
Ich bin sicher, dass Pakete für andere PHP-Frameworks entwickelt werden.
Für wirklich einfache Prototypen deployen unsere Designer Ordner über Dropbox mit site44.com
Ich habe nur 4 davon benutzt.
Die traditionelle FTP-Übertragung. Schwieriger Weg zu deployen und zu aktualisieren, wenn man viele Aktualisierungen in verschiedenen Ordnern hat. Ich lade am Ende einfach alles neu hoch und überschreibe alles.
Und natürlich habe ich als Rails-Entwickler auf dem Server Git-Pulling betrieben oder einfach Capistrano benutzt. Heroku habe ich auch schon mehrmals verwendet.
Für mich war das beste Deployment mit Git und Capistrano. Ich habe noch keine dieser Deployment-Dienste genutzt.
Heroku macht viel mehr als nur Ruby on Rails; ich würde sie nicht einmal als RoR-Host bezeichnen, wie hier zu sehen ist. Ich hoste Node-Apps bei ihnen und sie sind fantastisch. Sie unterstützen offiziell Java, Node.js, Python, Ruby, Scala und Clojure, und sie haben inoffizielle Unterstützung für PHP.
Ich hatte noch keine Gelegenheit, damit zu spielen, aber http://www.phptesting.org/ scheint eine ziemlich interessante PHP CI-Lösung zu haben (derzeit in Beta).
Derzeit benutze ich Git Flow (http://nvie.com/posts/a-successful-git-branching-model/) in Kombination mit einigen Post-Commit/Merge-Hooks für Archivierung und Deployment, aber ich möchte wirklich Jira zusammen mit einer CI-Lösung einrichten.
Ich muss die Hooks umschreiben, aber wenn jemand interessiert ist, kann er sie auf BitBucket finden.
Kennst du PAAS Openshift?
Danke für deinen Artikel, der mir viele Optionen zur Auswahl gegeben hat! Aber ich bin mir bei ihren Diensten und ihrer Leistung nicht wirklich sicher…
Ich habe ein Linode-Konto, um meine eigenen Blogs zu hosten, und benutze nur FTP für die Dateisynchronisierung. Da die Blogs klein sind und nur ich daran arbeite. Für mein Unternehmen haben wir jedoch ein eigenes Rechenzentrum, also bauen wir uns einen SVN-Server, um viele Websites zu bedienen.
Toller Beitrag/Liste.
Ich benutze und liebe http://modxcloud.com für meine MODX CMS-Websites. Könnte zur Liste hinzugefügt werden!
Ein Schritt, der meiner Meinung nach oft übersehen wird, wenn man eine Website bereitstellt, die auf irgendeine Art von CMS angewiesen ist (WordPress, b2evolution, Drupal oder dein eigenes…), ist, dass das Bereitstellen aktualisierter PHP- und statischer Dateien nicht ausreicht. Du wirst häufig ein Skript ausführen müssen, um die Datenbank zu erstellen/aktualisieren oder ein Plugin zu installieren usw.
Während all dieser Zeit ist deine Website einfach kaputt.
Meiner Meinung nach ist es genauso schlimm, eine Website während der Upgrade-Zeit kaputt zu lassen, wie deine Website live mit FTP zu bearbeiten.
Ich würde also sagen, man sollte sich darauf konzentrieren, seine Website zuerst in den „Wartungsmodus“ zu versetzen, indem man bei jeder Anfrage eine „Wartungsseite“ anzeigt, und sie dann wieder in den Normalbetrieb zurückversetzen, sobald die gesamte Einrichtung abgeschlossen ist.
Dies kann beispielsweise mit mod_rewrite in der .htaccess-Datei erfolgen. Jedes CMS hat möglicherweise auch eine spezifische Methode, dies für dich zu handhaben.
Keine Python-Liebe überhaupt?? :)
Ein anderer Kommentator erwähnte bereits Fabric (Ich benutze dieses Fabric Boilerplate), aber zusätzliche Python-Pakete machen das Deployment zum Kinderspiel.
Buildbot für Continuous Integration, automatisierte Builds/Tests/etc.
Salt für Konfigurationsmanagement, Release-Orchestrierung, praktisch alles, was du tun möchtest. (Hinweis: Dies ist ein viel umfangreicheres Paket, ideal für groß angelegte Deployments).
für diejenigen, die eine Benutzeroberfläche für Git und SVN mögen
git tower
http://git-tower.com
cornerstone (svn)
http://www.zennaware.com/cornerstone/index.php
Einige fantastische Dienste hier aufgelistet, Chris. Wir gründen gerade unsere eigene Agentur und suchen nach verschiedenen Lösungen für das Deployment, also schaue ich mir genau an, was angeboten wird.
Das ist eine **verdammte** Zusammenfassung. Hut ab für das Posten.
Ulrich hat oben über Deploy Button gepostet. Ich habe einen Blogbeitrag geschrieben und ein Screencast gemacht, wie Designer (einschließlich mir) Git und Deploy Button (oder einen ähnlichen Dienst) für einfache Deployments nutzen können.
http://adamjohnsondesign.com/blog/moving-ftp-git-deployment-designers-guide/
Ich habe das direkt mit meinem Bluehost Shared Account gemacht, ich pushe Änderungen live auf die Hauptwebsite und habe ein Git-Repository in einem Ordner auf meinem Hosting.
Ich vermute, https://www.cloudcontrol.com/ ist etwas Ähnliches, das hier eine Erwähnung wert sein könnte.
Eine meiner Lieblingsmethoden, Themes für WordPress bereitzustellen, war dieses Plugin, das deine von GitHub gehosteten Themes über die eigene Update-Funktion von WordPress bereitgestellt hat. Schade, dass das Projekt etwas verlassen scheint.
Danke! Das ist die beste High-Level-Erklärung von „Deployment“, die ich bisher gesehen habe.
Für Neulinge ist es leicht, sich von Begriffen wie „Deployment deiner App“ einschüchtern zu lassen, aber dein Artikel zeigt schön, dass es wirklich nur darum geht, WIE du deine Dateien von Computer A nach Computer B kopierst.
Sehr schöner Beitrag! Ich habe FTPloy ausprobiert, aber es war fehlerhaft. Also habe ich meine eigene Lösung entwickelt.
https://github.com/Wanchai/FTPbucket
Ich verwalte gerne alles von einem BitBucket-Repository aus (Git, Issues, Benutzer…).
FTP ist eine großartige Möglichkeit, Dateien zu kopieren und ist auf den meisten Servern vorhanden. Sobald du deine eigene Quellcodeverwaltung machst.
Ich habe ein kleines PHP-Skript geschrieben, das beim FTP-Deployment hilft. Es heißt PHPloy und ist eng mit Git gekoppelt, um zu bestimmen, welche Dateien wo bearbeitet/hinzugefügt/gelöscht wurden und lädt sie entsprechend hoch. Du legst deine FTP-Details in eine deploy.ini-Datei und führst nur einen Befehl zum Deployment aus.
Du kannst auch auf mehreren Servern gleichzeitig bereitstellen. Und wenn du mehrere Server konfiguriert hast, kannst du auswählen, auf welchen du bereitstellen möchtest, indem du dies tust.
Es gibt noch mehr, was getan werden kann – schau es dir auf Github an: https://github.com/banago/PHPloy
dploy.io ist jetzt **kostenlos** für 1 privates Repository, Pläne beginnen bei 15 $. Probier es aus!
Ich arbeite in einem kleinen Unternehmen. Ich bin der einzige Entwickler. Alle Websites in WordPress. Ich benutze MAMP und localhost. Das Hochladen von Dateien auf ein Subdomain über Filezilla FTP wird dem Kunden gezeigt und danach muss ich es zurück auf meinen localhost herunterladen und auf den Live-Server hochladen. Das ist nervig! Ich weiß nicht, was ich benutzen soll, bitte helfen und wie ich es mit Schritten einrichten kann.
Ich verstehe nicht, wie Git und Bitbucket funktionieren. Wie kann ich von localhost auf eine Subdomain oder einen Live-Server bereitstellen.
Ich weiß, dass ich für die Datenbank DBMigrate verwenden muss. Und nur importieren/exportieren.
danke
Ok, ich benutze Git und Bitbucket. Wie lade ich mein Repository von Bitbucket herunter und installiere es auf meinem FTP-Server? ? Etwas Kostenloses?
Probier http://dploy.io aus, es ist kostenlos und macht genau das und mehr.
Dima, ich habe das gesehen, aber dort hast du nur ein Repository kostenlos. Wenn ich mehrere Websites gleichzeitig bearbeite, brauche ich mehr Repositories, um sie über FTP bereitzustellen. Gibt es eine andere Option?
Zum Beispiel arbeite ich gerade lokal an 3 Websites, die ich auf 3 verschiedenen Subdomains bereitstellen möchte.
Danke für die Hilfe
Alle vergessen Joomla :(
Danke für den Artikel. Für viele Benutzer ohne PHP- oder Linux-Kenntnisse ist die Nutzung eines Drittanbieter-Cronjob-Dienstes wie easycron.com eine gute Wahl.
Vielen Dank dafür!