Was ist die optimale Entwicklungsumgebung? Diese Frage stellen sich Entwickler vermutlich immer wieder. Versionierungssysteme vereinfachen die Zusammenarbeit, FTP ist out, Deploying via GIT das neue State of the art. Genau vor dieser Frage stand ich jetzt bei einem kleinen Projekt. Warum ich bislang immernoch an FTP festgehalten habe? – Ganz einfach. Schnelle Änderungen lassen sich ebenso schnell veröffentlichen. Was aber, wenn ich ein Versionierungssystem mit ins Spiel bringen muss? Natürlich ist es möglich auch über eine GIT Integration in der IDE die Daten letztendlich dennoch via FTP zu veröffentlichen. Hier kann es aber zu unterschiedlichen Ständen kommen und GIT ist nicht mehr zwangsläufig der eigentliche „Master“. Schöner wäre es dann, gerade im Hinblick auf die Zusammenarbeit mit Dritten, die Veröffentlichung direkt über GIT (hier Bitbucket) zu ermöglichen. Und das ist mit ein paar wenigen Einstellungen möglich.

Bei Bitbucket lässt sich genau das mit den sog. Pipelines und der Continuous Delivery realisieren. Lokal ist GIT mit dem enstprechenden Projekt verbunden und der eigentliche (persönliche) Testserver des Entwicklers läuft lokal. Hier werden die Änderungen getestet, bevor sie dann in das GIT Repository  gepushed werden. Angekommen im GIT Repository wird via Pipeline die Veröffentlichung der eigentlichen Seite dann auf dem Produktivserver vorgenommen. In diesem Fall per FTP (Atlassian ftp-deploy).

Den Weg versuche ich in drei einfachen Schritten zu beschreiben.

Schritt -1-

In den Bitbucket Repository Settings müssen folgende Einstellungen vorgenommen werden. Zunächst müssen Pipelines an sich aktiviert werden:

Bitbucket – Repository Settings –> Pipelines –> Settings –> „Enable Pipelines“ aktivieren

 


 

Schritt -2-

In den Repository Variablen müssen jetzt die Zugangsdaten für den entfernten FTP Server erfasst werden.

Bitbucket – Repository Settings –> Pipelines –> Repository Variables

FTP_PASSWORD
FTP_HOST
FTP_USERNAME

 


 

Schritt -3-

Ist das erledigt, muss das Script angelegt was am Ende für die Veröffentlichung der Dateien verantwortlich sein wird. Die Datei kann direkt im Webfrontend von Bitbucket angelegt und gespeichert werden. Achtung! Ist es ein globaler FTP Zugang sollte der REMOTE_PATH genauer beachtet und ggf. angepasst werden.

Bitbucket – Repository –> Quellconde –> Datei anlegen (bitbucket-pipelines.yml)

Die Datei: bitbucket-pipelines.yml

image: atlassian/default-image:2

pipelines:

  branches:
    master:
      - step:
          name: Deploy to Production
          deployment: production
          script:
            - pipe: atlassian/ftp-deploy:0.3.5
              variables:
                USER: $FTP_USERNAME
                PASSWORD: $FTP_PASSWORD
                SERVER: $FTP_HOST
                REMOTE_PATH: /
                DELETE_FLAG: 'false' # Don't delete existing files
                EXTRA_ARGS: "--exclude=.bitbucket/ --exclude=.git/ --exclude=bitbucket-pipelines.yml --exclude=.gitignore" # Ignore these

 


 

Schritt -4-

Jetzt ist das Repository dahingehend angepasst, dass es Commits aus dem Master heraus automatisch auf dem Produktivserver via FTP veröffentlicht. Zur Kontrolle gibt es in den Pipelines eine schöne Übersicht der verschiedenen Zustände.

Bitbucket – Repository – Pipelines – Prüfen und/oder Deploying anstossen

 

Was auf jeden Fall beachtet werden sollte, bei aller Euphorie

Bitbucket stellt in der freien (kostenlosen) Version nur 50 Minuten Build Minuten zur Verfügung. Das bedeutet, dass man entweder auf einen der höheren Tarife umsteigen muss, oder genug Zeit hat zu warten. Für 3 Euro im Monat bekommt man allerdings schon 2500 Minuten (Plan Details), was durchaus eine Überlegung wert ist.