Hilfe für Anfänger beim Live-Schalten einer Website

Avatar of Chris Coyier
Chris Coyier am

DigitalOcean bietet Cloud-Produkte für jede Phase Ihrer Reise. Starten Sie mit 200 $ kostenlosem Guthaben!

Ich erhielt neulich eine tolle E-Mail von einem Herrn namens Josh Long. Er ist, in seinen Worten, „relativ neu im Webdesign“ und war etwas ratlos, was das Konzept des Live-Schaltens einer Website angeht. Ich sollte erwähnen, dass ich mich über solche E-Mails freue und sie immer lese, aber ich kann normalerweise keinen technischen Support per E-Mail anbieten. Wenn ich überhaupt antworten kann, verweise ich die Leute normalerweise auf andere Community-Ressourcen.

In diesem Fall erschien mir das als ein perfekter Moment für Josh. Er ist ein wenig verwirrt, aber er weiß genug, um viele Fragen zu stellen und all diese Dinge zu sortieren. Ich dachte, das wäre eine wunderbare Gelegenheit, seine Fragen zu vertiefen und ihm und vielleicht auch anderen in einer ähnlichen Situation zu helfen.

Hier ist einer der ursprünglichen Absätze, die Josh mir geschickt hat, komplett unbearbeitet

Ich bin relativ neu im Webdesign, habe aber ein paar Kurse über HTML und CSS belegt und einen Codecademy-Kurs über JavaScript absolviert. Aber (was wahrscheinlich eine ganze Weile dauert!) nachdem ich eine HTML/CSS/JS-Website oder -Webseite vollständig entworfen und codiert habe, verstehe ich den vollständigen Prozess vom lokalen Rechner, der mit MAMP/WAMP gehostet wird, bis zur Veröffentlichung einer öffentlichen Seite mit WordPress (?) oder einem anderen Hoster (ist WordPress überhaupt ein Hoster?!) nicht ganz und auch nicht, wie man einen geeigneten Server und eine Möglichkeit findet, Bilder/Videos oder andere Inhalte zu hosten. (Wenn das so klang, als ob ich die Hälfte davon nicht wüsste, dann liegt das daran, dass ich es leider nicht tue! ... aber ich würde es wirklich gerne!)

Kannst du diese Begeisterung spüren? Ich liebe sie.

Wir haben ein wenig zusammengearbeitet, um viele seiner Fragen für diesen Beitrag zu verfeinern, aber es sind immer noch Joshs Worte. Los geht's!


Was ist ein Domain-Registrar? Ich verstehe, dass sie für die Registrierung von Domainnamen sind, aber was ist der Unterschied zwischen ihnen? Woher weiß ich, welcher der richtige für mich ist? Eine schnelle Suche nach „beste Domain-Hoster“ bei Google ergab 5 Anzeigen für Unternehmen, die Domain-Registrare/Hoster sind, und 9 „Top 10“-Seiten, die so aussehen, als hätten sie eine Art Verbindung zu mindestens einem Unternehmen, das sie empfehlen. Suche ich einfach nach dem billigsten?

Du hast absolut Recht, Domain-Registrare sind für die Registrierung von Domainnamen da. Wenn du joshlongisverycool.com haben möchtest, musst du es kaufen, und Domain-Registrare sind Unternehmen, die dir dabei helfen.

Suche nach einem Domainnamen

Es ist schade, dass die Suchergebnisse im Web so stark von Anzeigen und mit Affiliate-Links gesättigten SEO-optimierten Seiten überschwemmt sind. Von diesen Seiten wirst du nie absolute Ehrlichkeit bekommen, denn sie sind voller Links, die denjenigen bewerben, der ihnen am meisten zahlt, um Neukunden zu schicken. Sogar Google selbst wird dir einen Domainnamen verkaufen.

Die Wahrheit ist, dass man hier nicht *zu* viel falsch machen kann. Domainnamen sind eine Art Ware und die Hunderte von Unternehmen, die dir einen verkaufen, konkurrieren weitgehend über Marketing.

Ein paar Dinge, auf die man achten sollte

  • Manche Unternehmen behandeln die Domain als Lockangebot. Wie ein Lebensmittelgeschäft, das billige Milch verkauft, in der Hoffnung, dass du noch mehr Sachen kaufst, während du da bist. Der Kassiervorgang bei jedem Domain-Registrar wird dich mit ziemlicher Sicherheit versuchen, dir einen Haufen Extras zu verkaufen. Sie könnten dir zum Beispiel zusätzliche Domainnamen oder E-Mail-Hosting verkaufen, das du wahrscheinlich nicht brauchst. Sei einfach vorsichtig.
  • Webhoster (zu denen wir als Nächstes kommen) verkaufen sie dir oft zusammen mit dem Hosting. Das ist, denke ich, in Ordnung, aber ich halte es für einen Interessenkonflikt. Nehmen wir an, du entscheidest dich eines Tages, den Hoster zu wechseln. Dieses Hosting-Unternehmen hat dann falsche Anreize, dir das leicht zu machen. Wenn die Domain woanders verwaltet wird, hat dieser Domain-Registrar den richtigen Anreiz, dir bei Änderungen zu helfen.

Ich möchte dir nicht noch mehr Lärm zumuten, aber hier sind ein paar Domain-Registrare, die ich persönlich genutzt habe und die *nicht für Sponsoring bezahlt werden oder Affiliate-Links sind*

Unsere eigene Sarah Drasner empfiehlt ZEIT domains, die sehr interessant sind, da man sie komplett über die Kommandozeile kauft und verwaltet.

Ich würde vorschlagen, wenn du dir vorstellen kannst, mehrere Domainnamen in deinem Leben zu besitzen, diese bei einem einzigen Registrar zu konsolidieren. Die Verwaltung von Domains ist nichts, was du sehr oft tun wirst, daher verliert man leicht den Überblick, welche Domains du bei welchem Registrar registriert hast, ganz zu schweigen davon, wie/wo man alle Einstellungen bei verschiedenen Registraren ändert.

Ich würde auch vorschlagen, dass es in Ordnung ist, hier zu experimentieren. So haben wir alle gelernt. Wähle einen mit einer UI, die du nicht hasst, und einem vertrauenswürdigen Gefühl. Vielleicht nutzt dein Freund diesen auch. Hoffentlich klappt es gut. Wenn du ihn hasst, ist es ein bisschen Arbeit, aber du kannst ihn immer wechseln.


Was ist ein Webhoster und warum brauche ich einen? Eine Google-Suche liefert dir einen Berg von „beste Webhoster“-Artikeln und Anzeigen. Diese Webseiten scheinen alle voller Fachbegriffe wie „Shared Hosting“ und „Managed Hosting“ zu sein. Ich sehe Dinge wie „empfohlene Hoster“ auf einigen Seiten. Wie findet man den richtigen Webhoster? Ich bin mir nicht einmal sicher, was meine Bedürfnisse sind. Sollte ich einfach den billigsten nehmen?

Nur weil du eine Domain *besitzt*, heißt das nicht, dass sie etwas tut. Tatsächlich wird der Domain-Registrar, sobald du sie gekauft hast, wahrscheinlich eine „Coming Soon“-Seite für dich einrichten

Eine „Coming Soon“-Seite, die man direkt nach dem Kauf eines Domainnamens sehen könnte.

Um eine Website unter deiner neuen Domain zu hosten, musst du die DNS deiner neuen Domain so konfigurieren, dass sie auf einen mit dem Internet verbundenen Server verweist. Hier ist eine interessante Tatsache… du könntest das direkt von deinem Haus aus machen, wenn du wolltest. Dein Internetdienstanbieter (ISP) zu Hause gibt dir wahrscheinlich eine IP-Adresse. Das ist alles ein bisschen nerdig, aber du könntest deinen Domainnamen auf diese IP verweisen und deinen Computer so einrichten, dass er als Webserver fungiert, der auf eingehende Anfragen reagiert und deine Website liefert. Das macht aber fast niemand. Du willst nicht, dass dein Webserver ausfällt, weil du deinen Laptop zugemacht hast oder dein ISP deine IP geändert hat.

Webhosting-Dienste stellen dir diesen Server zur Verfügung. Ähnlich wie Domain-Registrare sind Webhoster fast eine Ware. Es gibt viele davon, die einen ähnlichen Dienst anbieten, daher ist der Preis recht niedrig und sie finden andere Dinge, auf denen sie konkurrieren.

Der Kauf von Webhosting ist etwas kniffliger als der Kauf einer Domain. Du musst ein wenig über die Website wissen, die du hosten möchtest, wenn du diese Wahl triffst. Wird es eine WordPress-Seite sein? Oder eine andere PHP/MySQL-basierte CMS-Seite (dazu kommen wir später)? Das bedeutet, dass dein Hoster diese Technologien unterstützen muss. Die meisten tun es, manche nicht. Du solltest vielleicht in deren Dokumentation nachsehen oder sie direkt fragen, bevor du dich entscheidest, wenn du unsicher bist. Es gibt viele Technologien, um Websites zu betreiben. Sagen wir, die Seite wird Ruby on Rails verwenden – das sind andere Anforderungen, die nicht alle Hoster anbieten. Oder Node… Oder Python… dieselbe Geschichte.

Wenn ein Webhoster sagt, dass er sich auf eine bestimmte Technologie spezialisiert hat und das ist, was du brauchst, dann ist das wahrscheinlich ein guter Weg, besonders in deinen Anfängen. Schauen wir uns das mal ganz kurz an. Auch hier handelt es sich nicht um Affiliate- oder bezahlte Links und es handelt sich um etwas zufällig ausgewählte Webhoster, die mir einfallen

Hier sind nun einige andere Webhoster, die etwas weniger traditionell sind. Bitte verzeiht die technischen Begriffe – wenn sie euch nichts bedeuten, ignoriert sie einfach.

  • Netlify bietet Hosting für statische Seiten, was großartig für Dinge wie statische Seitengeneratoren und JAMstack-Sites ist.
  • Zeit ist ein Hoster, mit dem man ausschließlich über die Kommandozeile interagiert.
  • DigitalOcean hat seine eigene Art, über Hosting zu sprechen. Sie nennen ihre Server Droplets, die so etwas wie virtuelle Maschinen mit zusätzlichen Funktionen sind.
  • Heroku eignet sich hervorragend zum Hosten von Apps mit einem fertigen Backend für Dinge wie Node, Ruby, Java und Python.
  • Amazon Web Services (AWS) ist eine ganze Suite von Produkten mit spezialisierten Hosting-Schwerpunkten, die für ziemlich fortgeschrittene Benutzer gedacht sind. Microsoft Azure und Google Cloud sind ähnlich.

Auch hier würde ich sagen, dass es in Ordnung ist, in gewissem Sinne einige Fehler zu machen. Wenn du nichts besonders kritisch Mission-Kritisches hostest, wie deine persönliche Website, wähle einen Hoster, der zu dir passt und probiere es aus. Hoffentlich klappt es großartig – wenn nicht, kannst du wechseln. Das Wechseln ist nicht immer super angenehm, aber jeder macht es irgendwann und du wirst dabei lernen.

Wenn du Webhosting kaufst, wird dir der Hoster sagen, wie du es nutzen kannst. Eine gängige Methode ist, dass der Hoster dir SFTP-Zugangsdaten gibt. Dann verwendest du Software, die zum Verbinden mit Servern über SFTP entwickelt wurde, und das ermöglicht es dir, Dateien auf den Webserver hochzuladen.

Das ist ein magischer Moment!

Sagen wir, du hast an einer Datei gearbeitet, die eine einzelne index.html-Datei ist, die eine style.css-Datei lädt. Lade diese Dateien per SFTP in den Ordner hoch, den dein Hoster dir als öffentliches Stammverzeichnis für diese Seite nennt.

Das ist der Prozess, um eine Website von lokal auf live zu bringen! Daran ist auch nichts falsch. Dies wird als Deployment bezeichnet, und das ist so grundlegend und einfach, wie es nur geht. Selbst ausgefeiltere Deployment-Methoden tun im Grunde dasselbe im Hintergrund. Wir werden später tiefer auf das Deployment eingehen.


Solltest du deinen Domain-Registrar und Webhoster bündeln, wenn ein Unternehmen beides anbietet?

Das habe ich oben schon ein wenig erwähnt: Ich bin im Allgemeinen ein Fan davon, das *nicht* zu tun. Einerseits ist es sehr praktisch. Dinge wie gemeinsame Abrechnung und ein einheitlicher Bestellvorgang. Der Hoster wird auch Dinge tun, wie die DNS für dich zu konfigurieren, damit alles für ihr Hosting eingestellt ist, und du musst wahrscheinlich nicht einmal darüber nachdenken.

Aber sagen wir, der Tag kommt, an dem du diesen Hoster nicht mehr magst. Du hast ein besseres Angebot gefunden, bist über sie hinausgewachsen, warst von ihrem Support oder Service abgeschreckt, oder aus irgendeinem anderen Grund. Du möchtest den Hoster wechseln. Das Problem ist, dass sie nicht nur dein Hoster, sondern auch dein Domain-Registrar sind. Lässt du die Domain bei ihnen und wechselst nur den Hoster? Wahrscheinlich nicht, du versuchst, sie zu verlassen. Jetzt musst du zwei Dinge wechseln. Das macht diesen Wechsel noch riskanter, aber schlimmer ist, dass dieses Unternehmen nicht gerade motiviert ist, schnell und hilfreich auf deine Anfragen zu reagieren, da es weiß, dass es dich als Kunden verliert.


Was genau ist ein „CMS“? Welchen Zweck hat es? WordPress, Joomla und Drupal sind die bekanntesten Namen, die ich für Content-Management-Systeme gefunden habe, und aus ihren Beschreibungen klingen alle sehr ähnlich. Welche Arten von Funktionen unterscheiden sie voneinander? Ist ein CMS alles, was ich brauche, um meine Website von meinem lokalen Computer ins Internet zu bringen?

CMS (Content Management System) ist ein ziemlich generischer Begriff. Es bedeutet buchstäblich alles, was dir hilft, Inhalte zu verwalten. Es gibt, wie du gesehen hast, einige große Player wie WordPress und CraftCMS. Sie haben nichts direkt mit der Verbindung zwischen lokaler Arbeit an einer Seite und der Live-Schaltung dieser Seite zu tun. Aber sie komplizieren es eher.

Der Grund, warum du überhaupt ein CMS verwenden würdest, ist, die Arbeit an deiner Website zu erleichtern. Betrachten wir diese Seite, die du gerade siehst. Es gibt Zehntausende von Seiten auf dieser Seite. Es wäre unmöglich, jede einzelne als eine von Hand erstellte datei.html zu haben.

Stattdessen ermöglicht uns ein CMS, all diese Seiten zu erstellen, indem wir Daten und Vorlagen kombinieren.

Betrachten wir die Technologie hinter WordPress, einem CMS, das für CSS-Tricks ziemlich gut funktioniert. Damit WordPress laufen kann, benötigt es

  1. PHP (die Backend-Sprache)
  2. MySQL (die Datenbank)
  3. Apache (der Webserver)

Das kannst du alles lokal machen!

Ich benutze dafür Local by Flywheel (Mac und Windows), aber es gibt eine Reihe von Möglichkeiten, diese Technologien zum Laufen zu bringen: MAMP, Docker, Vagrant usw.

Das bringt dich lokal mit deinem CMS zum Laufen. Das ist eine schöne Sache. Eine gute lokale Entwicklungsumgebung für deine Website ist entscheidend. Aber sie hilft dir nicht, die Website live zu schalten.

Wir werden uns später damit beschäftigen, wie man das alles auf eine Live-Website bringt, aber du solltest das wissen: Der Webserver, den du betreibst, muss dieselben Technologien ausführen. Wenn wir das obige WordPress-Beispiel betrachten, muss dein Webserver *auch* PHP, MySQL und Apache ausführen. Dann musst du ein System einrichten, um all deine Dateien von deinem lokalen Computer auf deinen Webserver zu bekommen, wie bei jeder anderen Website auch, aber wahrscheinlich auch ein System zur Verwaltung der Datenbank. Die Datenbank ist etwas knifflig, da sie keine „flache Datei“ ist, wie die meisten anderen Teile deiner Website.

Ein CMS könnte aus beliebigen Technologien erstellt werden, nicht nur aus den oben genannten. Siehe zum Beispiel KeystoneJS. Anstelle von PHP ist Keystone Node.js. Anstelle von MySQL für die Datenbank verwendet es MongoDB. Anstelle von Apache verwendet es Express. Nur ein anderer Satz von Technologien. Beides kannst du lokal *und* auf einem Live-Webserver zum Laufen bringen.

Ein CMS könnte sogar ganz ohne Datenbank auskommen! Statische Seitengeneratoren sind so etwas. Du bringst die Website lokal zum Laufen, und sie erzeugt eine Reihe von flachen Dateien, die du auf deinen Live-Server überträgst. Eine andere Vorgehensweise, aber absolut immer noch ein CMS. Was ich immer sage, ist, dass das beste CMS ein individuell angepasstes ist, das auf deine Bedürfnisse zugeschnitten ist.


Was ist „Asset-Hosting“? Sind Assets keine Inhalte? Was ist der Unterschied zwischen einem CMS und einem Asset-Hosting-Dienst? Was macht ein Asset-Host?

Definieren wir ein Asset: jede „flache“ Datei. Das heißt, nicht dynamisch generiert, wie ein CMS eine HTML-Datei generieren könnte. Bilder sind ein Paradebeispiel für ein „Asset“. Aber auch Dinge wie CSS- und JavaScript-Dateien, sowie Videos und PDFs.

Und bevor wir weitergehen: Wahrscheinlich musst du dich darum noch nicht sofort kümmern. Dein Webhoster kann Assets hosten, und das ist für deine ersten Schritte mit kleinen Websites mehr als genug.

Ein Hauptgrund, warum Leute sich für einen Asset-Host (wahrscheinlich häufiger als CDN oder Content Delivery Network bezeichnet) entscheiden, ist die Geschwindigkeitssteigerung. Asset-Hosts sind ebenfalls Server, genau wie der Webserver deines Webhosters, aber sie sind darauf ausgelegt, diese flachen Asset-Dateien super schnell zu hosten. So werden diese Assets nicht nur super schnell an die Leute geliefert, die deine Website ansehen, sondern dein Webserver wird von dieser Last befreit.

Du könntest sogar so etwas wie YouTube als Asset-Host betrachten. Das 100 MB Video von einem Schmetterling in deinem Garten ist eine enorme Last für deinen kleinen Webserver und potenziell ein Problem, wenn deine ausgehende Bandbreite begrenzt ist, wie es oft der Fall ist. Das Hochladen dieses Videos auf YouTube bringt dein Video in dieses ganze soziale Universum, aber ein wichtiger Grund dafür, abgesehen von der sozialen Komponente, ist, dass es dieses Video-Asset für dich hostet.


Ich habe von „Repositories“ gehört, verstehe aber nicht wirklich, was das ist. Ich höre Sätze wie „lade es einfach in mein Git-Repository hoch.“ Was zum Teufel bedeutet das? Ich fühle mich wie ein Idiot, weil ich das frage. Was ist Git? Wofür ist es gut? Muss ich es benutzen? Ist es am „Lokal-zu-Live“-Prozess beteiligt?

Es tut mir leid, dass du mit einem *„einfach“* konfrontiert wurdest. Es gibt eine Epidemie in Technologiegesprächen, wo Leute das einfügen, um es so aussehen zu lassen, als ob das, was sie sagen werden, einfach und offensichtlich ist, obwohl es je nach Leser das Gegenteil sein kann.

Aber lass uns über Git-Repositories sprechen.

Git ist eine spezielle Form der Versionskontrolle. Es gibt andere, aber Git ist in der Webindustrie so dominant, dass es sich kaum lohnt, andere zu erwähnen.

Nehmen wir an, du und ich arbeiten *gemeinsam* an einer Website. Wir haben eine Domain und Hosting gekauft und die Website live geschaltet. Wir haben die SFTP-Zugangsdaten geteilt, sodass wir beide Zugriff auf die Dateien der Live-Website haben. *Das kann ziemlich gefährlich sein!*

Coda ist ein Code-Editor, mit dem du Dateien direkt auf einem Server bearbeiten kannst, mit dem du dich über SFTP verbunden hast. Cool, aber gefährlich!

Sagen wir, wir bearbeiten beide eine Datei und laden sie per SFTP hoch… welche Änderung gewinnt? Es ist diejenige, die zuletzt hochgeladen wurde. Wir haben keine Ahnung, wer was getan hat. Wir überschreiben uns gegenseitig und haben keine Möglichkeit, mit den Änderungen des anderen synchron zu bleiben, Änderungen wirken sich sofort auf die Live-Website aus, was zu Problemen führen kann, und wir haben keine Möglichkeit, Änderungen rückgängig zu machen, falls wir etwas kaputt machen. *Das ist eine Situation, die so inakzeptabel ist, dass sie wirklich nie gemacht wird.*

Stattdessen arbeiten wir mit Versionskontrolle, wie Git. Mit Git, wenn wir Änderungen vornehmen, committen wir sie in ein Repository. Ein Repository kann überall gehostet werden, sogar auf deinem lokalen Rechner. Aber um sie wirklich nützlich zu machen, werden sie irgendwo im Internet gehostet, wo jeder Zugriff darauf hat. Du hast sicher GitHub gesehen, das diese Repositories hostet und eine Reihe anderer Funktionen wie Issue-Tracking hinzufügt. Ähnlich sind GitLab und Bitbucket.

Nehmen wir nun an, du und ich arbeiten an derselben Website, aber wir haben ein Git-Repository dafür eingerichtet. Wenn ich eine Änderung vornehme, committe ich sie in das Repository. Wenn du auch eine Änderung vornehmen möchtest, musst du meine Änderungen herunterziehen, was sie in deine eigene Kopie des Codes mergt. Dann kannst du deine Änderungen hochpushen. Wie bei allem wird es komplizierter, aber das ist die Essenz.

Aber ein Git-Repository ist *nicht die Live-Website*. Du bist auf dich allein gestellt, wenn es darum geht, die Dateien aus einem Git-Repository auf eine Live-Website zu bekommen. Glücklicherweise ist das eine Situation, mit der jeder konfrontiert ist, daher gibt es viele Optionen. Gut, dass deine letzte Frage sich damit beschäftigt!


OK. Nun, da das alles geklärt ist… wo fängst du an, um von lokal zu live zu kommen? Wo „lädst“ du deine HTML-, CSS- und JavaScript-Dateien hoch? Wie verknüpfst du deinen glänzenden neuen Domainnamen mit diesen Dateien und siehst ihn in der Welt? Welcher Dienst ist für das Hinzufügen neuer Inhalte zu deiner Website oder deren Aktualisierung zuständig? Wird es wirklich verwirrend, wenn du für jeden Dienst unterschiedliche Unternehmen hast?

Fangen wir mit einer sehr einfachen Website auf dem an, was ich als typisches Webhosting betrachten würde. Nehmen wir an, du hast nur index.html, style.css und script.js-Dateien auf deinem lokalen Computer, die deine gesamte Website ausmachen. Du hast einen Domainnamen gekauft und die DNS-Einstellungen auf einen Webhoster zeigen lassen. Dieser Hoster hat dir SFTP-Zugangsdaten gegeben. Du wirst diese Zugangsdaten in einer App verwenden, die SFTP-Verbindungen erlaubt, um dich einzuloggen

Dein Hoster wird dir auch sagen, welcher Ordner das „öffentliche Stammverzeichnis“ deiner Website ist. Die Dateien dort werden im öffentlichen Internet für die Welt sichtbar sein!

Du hörst Leute vielleicht von der „Live“-Website als „Produktions“-Website sprechen. Wenn jemand etwas fragt wie: *Ist dieser Fehler in die Produktion gelangt?* meinen sie, ob der Fehler auf der Live-Website vorhanden ist. „Entwicklung“ ist dein lokaler Computer. Du hast vielleicht auch eine „Staging“-Website, die eine Kopie der Live-Website auf derselben Hardware/Software wie die Live-Website zum Testen ist.

Erinnerst du dich, wie wir früher über Git-Repositories gesprochen haben? Während die Repositories selbst dir nicht direkt helfen, die Dateien darin auf deinen Webserver zu bekommen, arbeiten die meisten Systeme, die dir beim Lokal-zu-Live-Prozess helfen, mit deinen Repositories.

Der Begriff „Lokal-zu-Live“ bezieht sich auf Deployment. Wenn du Änderungen hast, die auf deiner Produktionswebsite erscheinen sollen, deployst du sie. Das ist der Prozess, deine Arbeit von der „Entwicklung“ zur „Produktion“ zu verschieben.

Ein Dienst, der bei dieser Idee des Deployments hilft, ist Beanstalk. Beanstalk hostet dein Git-Repository, *und du gibst ihm die SFTP-Zugangsdaten für deinen Server* – so kann es die Dateien auf deinen Webserver übertragen, wenn du Commits machst. Cool, oder? Wenn du dieses Git-Repo woanders hosten möchtest, wie auf GitHub, Bitbucket oder Gitlab. Schau dir DeployBot an, das dasselbe tut, nur dass es sich auch mit diesen Seiten verbinden kann. Es überrascht dich wahrscheinlich nicht, dass es hier viele Optionen gibt, die sich in Preis und Komplexität unterscheiden.

Kehren wir zu unserem WordPress-Beispiel zurück.

  1. Du hast es perfekt lokal (auf deinem Computer) am Laufen und möchtest es jetzt live schalten.
  2. Du hast einen Domainnamen bei einem Registrar gekauft.
  3. Du hast Hosting gekauft, das die WordPress-Anforderungen erfüllt.
  4. Du hast die DNS der Domain auf den Webhoster zeigen lassen.
  5. Du hast überprüft, ob alles funktioniert (einfache Methode: eine index.html-Datei im öffentlichen Stammverzeichnis per SFTP hochladen und überprüfen, ob sie geladen wird, wenn du die Domain in einen Browser eingibst).

Jetzt hast du noch etwas Arbeit zu erledigen

  1. Richte ein Git-Repository für die Website ein.
  2. Richte einen Deployment-Dienst ein, um die Dateien aus dem Repository auf die Live-Website zu übertragen.
  3. Konfiguriere/Richte die Live-Website nach Bedarf ein. Zum Beispiel brauchst du eine Datenbank auf der Live-Website. Du musst diese erstellen (dein Hoster wird Anleitungen haben) und Dinge tun wie den WordPress-Installer ausführen und Konfigurationsdateien aktualisieren.
  4. Wenn du Dinge in deiner lokalen Datenbank hast, die du auf die Live-Website übertragen möchtest, musst du möglicherweise Dinge exportieren/importieren. Das kann auf der rohen MySQL-Ebene mit den nativen Import/Export-Funktionen von WordPress geschehen, oder mit einem ausgefallenen Plugin wie WP DB Migrate Pro.

Das ist keine triviale Menge Arbeit! Tut mir leid. Dieser Prozess ist jedoch für jede Website ziemlich ähnlich. Es geht darum, deinen Produktionswebserver genau so zu konfigurieren und einzurichten, wie er sein sollte, und dann die Dateien darauf zu deployen. Jede Website ist ein wenig anders, aber du wirst diesen Tanz schon lernen.

Es ist wirklich ein großer Tanz. Ich habe dir hier nur ein Bild gezeichnet. Ich habe versucht, eines auszuwählen, das allgemein genug und breit genug ist, dass es die Landschaft dessen zeigt, was getan werden muss. Aber bei jedem Schritt dieses Tanzes gibt es verschiedene Möglichkeiten, wie du Dinge tun kannst, verschiedene Dienste, die du auswählen kannst, Unternehmen, die versuchen, dir bei verschiedenen Schmerzpunkten zu helfen… es ist eine sich ständig verändernde Welt.

Derzeit erfreut sich Netlify großer Beliebtheit, da sie einer der wenigen Webhoster sind, die dir tatsächlich beim Deployment helfen. Sie beobachten deine Git-Repositories und führen das Deployment für dich durch! Netlify ist nur für statische Websites, aber das kann eine ganz eigene Welt sein. ZEIT ist ebenfalls enorm innovativ darin, wie es beim Deployment und Hosting von Webprojekten hilft, einschließlich der direkten Verbindung mit GitHub.


Viel Erfolg!

Ich hoffe, das war hilfreich. Denk daran, du bist nicht allein damit. Millionen anderer Entwickler haben das schon vor dir gemacht und es gibt Hilfe im Internet.

Und denk daran: Der beste Weg, irgendetwas zu lernen, ist…