Jedes Projekt, das wir ausliefern, läuft über GitHub: Versionskontrolle, Code-Review und die CI/CD-Pipelines, die aus einem gemergten Pull Request automatisch etwas machen, das auf Brova Cloud läuft.
Derselbe dreiphasige Prozess, den wir für alles anwenden, was wir bauen: Beratung, Umsetzung, Betrieb. GitHub verändert, was innerhalb jeder Phase passiert, nicht die Struktur.
Branching-Strategie, Schutzregeln und Zugriff konfiguriert, noch vor dem ersten Commit.
Nichts erreicht die Produktion, ohne dass ein weiterer Entwickler es geprüft hat.
CI/CD-Pipelines, die testen, bauen und nach Brova Cloud ausliefern, ohne einen manuellen Schritt, der vergessen werden könnte.
Ein Werkzeug ist nur so gut wie die Disziplin, mit der es eingesetzt wird. Das bedeutet in der Praxis, wenn wir sagen: "wir setzen GitHub ein".
Verpflichtende Reviews, damit Qualität nicht von Erinnerung oder guten Absichten abhängt.
GitHub Actions führt bei jedem Merge automatisch Tests und Deployments aus.
Direkt verknüpft mit den Commits und Pull Requests, die sie gelöst haben.
Darüber, wer was wann und warum ausgeliefert hat, für jede Umgebung.
Das, was am häufigsten zu GitHub gefragt wird, bevor Kunden Kontakt aufnehmen.
Ja, der Branch-Schutz macht das zur Pflicht, nicht zur Empfehlung: Nichts erreicht die Produktion, ohne dass ein anderer Entwickler es vorher prüft, sodass Qualität nicht vom Gedächtnis oder den guten Absichten einer Person an einem hektischen Tag abhängt.
Vollständig, über CI/CD-Pipelines, die mit GitHub Actions gebaut werden. Tests laufen und Deployments zu Brova Cloud erfolgen bei jedem Merge automatisch, ohne einen manuellen Schritt, den jemand vergessen oder aus Zeitdruck überspringen könnte.
Sie haben Zugriff. Alle unsere Kunden sind vollständig Eigentümer ihres Codes, und das GitHub-Repository, einschließlich des vollständigen Verlaufs, wer was wann und warum gemacht hat, ist Teil dessen, worauf Sie während und nach dem Projekt Zugriff erhalten.
Sie wird bei der Einrichtung des Repositorys festgelegt, vor dem ersten Commit, je nachdem, wie viele Personen parallel arbeiten und wie häufig Releases erfolgen. Ein Solo-Projekt und ein Team mit fünf Entwicklern brauchen deutlich unterschiedliche Branching-Ansätze, daher nutzen wir nicht unabhängig vom Kontext ein einziges Muster.
Ja, das Issue-Tracking ist direkt mit den Commits und Pull Requests verknüpft, die sie gelöst haben, sodass es eine klare Linie zwischen der Meldung eines Bugs und der genauen Codeänderung gibt, die ihn behoben hat, statt eines Bug-Trackers, der losgelöst vom Code existiert.
Oder schreiben Sie uns per WhatsApp, +44 7883 256391. Wir antworten innerhalb eines Werktags.