SAFweb2-Release 2.1.17

Releases erstellen

Release erstellen bedeutet, alle nötigen Komponenten in eine Archivdatei (meist .tgz) zu verpacken, damit die Auslieferung vereinfacht wird. Diese Archivdatei wird auf dem Zielsystem dann im dafür vorgesehenen Verzeichnis entpackt. Möglicherweise sind noch wenige Konfigurationen vorzunehmen, danach sollte die Software dann laufen.

Ablauf auf Testserver

Auf dem Testserver sind drei Umgebungen installiert.

  • Transition
  • Test
  • Produktiv

Transition

Hier wird der Code per git pull oder git clone aktualisiert. Es werden dann alle unitTests durchgeführt und ggf. Korrekturen vorgenommen. Sind die Tests erfolgreich beendet und alle Korrekturen implementiert, wird der Code im Git Repository aktualisiert mit git push.

Test

Der Code wird hier über Git aktualisiert. Aus dem develop Branch wird per git clone eine vollständige frische Kopie angefertigt. Dann finden die Productiv Optimierungen statt. Die so entstandene Codebasis wird dann in ein Tarball gepackt und in Produktiv kopiert.

Produktiv

Der entpackte Tarball wird so aufbereitet, dass bei bestehender Datenbank ein lauffähiges System entsteht. Wenn der Code hier läuft, bei definierter Konfiguration, dann wird das Tararchiv als Release freigegeben.

Das Release wird dann auf die Download Platform gestellt, von wo es beim Kunden geladen werden kann.

Die Installation beim Kunden erfolgt in folgenden Schritten:

  1. laden des Tar Archives
  2. auspacken im Zielverzeichnis mit Release-Kennung
  3. Konfiguration
  4. symbolischer Link von aktiver Produktiv auf neues Release legen
  5. kurzer funktionaler Test

Module

Es existieren derzeit folgende Module:

  1. SAFweb2 Test (die Anwendung)
  2. SAFweb2 Produktiv (die Anwendung)
  3. SAFweb2 Transition
  4. oraapi (Oracle API)
  5. Appliance-Page (Startwebseite der Anwendung)
  6. Docker (alle Docker Container)
  7. Installation (Installationsskript)
  8. SAFdocs (diese Doku hier)

Die derzeitige Codeverwaltung und Versionierung erfolgt mit git. Dazu wurde ein eigenes Git-Repository auf einem unserer Webserver aufgesetzt.

Releases werden derzeit für folgende Module erzeugt:

  1. Installation

Damit das Release erstellt werden kann, ist eine bestimmte Verzeichnisorganisation nötig. Der Aufbau der Verzeichnisse für die Softwareentwicklung von SAFweb2 ist hier nachzulesen.

Make a Release

Hierfür wird das Modul mk_release verwendet.
Für jedes Modul gibt es ein eigenes Shellskript, mir dem das Release jeweils erstellt werden kann. Dem Shellskript stehen alle notwendigen Informationen in Form von Konfigurationsdateien zur Verfügung.

Workflow zum Release erstellen

Release-Flow

Release für Modul Installation

Quick-Start

  1. Release in installation-release.sh erhöhen
  2. sh installation-release.sh (ausführen)
  3. Shelloutput verfolgen

Anleitung

Das auszuführende Skript heißt installation-release.sh. Zusätzlich wird eine Dateiliste benötigt:

installation-release-filelist.txt

linux
startpage
README.md
update_installer.sh

Im Shellskrip installation-release.sh muss vor jedem neuen Release die neue Releasenummer angepasst werden:

[installation-release.sh]

#! /bin/bash

RELEASE=0.2.4                 <== hochzaehlen
INSTALLDIR=installation
BUILDDIR=./build
BTARGET=$BUILDDIR/$INSTALLDIR
...

Weiterhin müssen der Download-Host, und das Downloadverzeichnis, sowie die Quellcodebasis ggf, angepasst werden.

  • HOST - IP Adresse oder HOSTNAME des Online-Downloadservers
  • DOWNLOADBASE - das Verzeichnis auf den HOST
  • SOURCEBASE - Quellcode des Moduls für das das Release erstellt werden soll
[installation-release.sh]

...
HOST=95.217.217.117
DOWNLOADBASE=/opt/dockerized/download.safineia.net/downloads/safweb2
SOURCEBASE=~/projekte/SAFINEIA/safweb2/installation                   <== an lokales anpassen
...

Release für Modul SAFweb2 Testumgebung

Quick-Start

Auch der Testserver läuft im Produktiv-Modus, allerdings mit dem Code aus dem develop Branch.

  1. Testserver aktuallisieren
    1. git branch develop update
  2. UnitTests durchführen (testen / korrigieren / testen)
    1. ok? weiter
    2. nicht ok? Fix
  3. ok -> App vorbereiten
    1. php artisan clear:cache
    2. php artisan clear:config
    3. php artisan clear:route
    4. php artisan clear:view
  4. rsync mit Release-Package Directory
  5. Zip File erstellen
    1. ohne .env
  6. Zip zum Release-Test-Server kopieren
  7. Release auspacken
    1. app-x.y.z
    2. alten SymLink löschen
    3. SymLink von app -> app-x.y.z
  8. Browser Test
  9. ausliefern

Prozess

Test Release Workflow

Prozessdetails

Codebasis auschecken

git clone -b main safweb@95.217.217.117:/opt/gitrepositories/...         // first checkout
git clone user@git-server:project_name.git -b branch_name /some/folder   // or so

Repositories

horst-elektronik.de.git
safineia.eu.git
safweb2-appliance_page.git
safweb2-docker.git
safweb2-docs.git
safweb2.git
safweb2-installation.git
safweb2-man.git
safweb2-oraapi.git
safweb2-releases.git
safweb.git
webinfo-frontend.git
webinfo.git
webinfo-layout
webinfo-layout.git
websites
    docs_safineia_eu.git
    layout_safineia_eu.git
    safineia_eu.git
    techdocs_safineia_eu.git

Codebasis commit nach Änderung

git add . && git commit -m "COMMIT COMMENT" && git push origin develop

Für docs:
git add . && git commit -m "COMMIT COMMENT" && git push origin main

Testserver update

su safweb

# update app
cd app
git branch
git pull origin
docker exec  safweb-test-phpfpm php artisan migrate:fresh --seed
docker exec  safweb-test-phpfpm php artisan test

# App Deploy
docker exec  safweb-test-phpfpm php artisan cache:clear
docker exec  safweb-test-phpfpm php artisan config:clear
docker exec  safweb-test-phpfpm php artisan route:clear
docker exec  safweb-test-phpfpm php artisan view:clear

# remove storage/logs

# write permissions
sudo chmod -R 775 storage
sudo chmod -R 775 bootstrap/cache

docker exec  safweb-test-phpfpm composer install --optimize-autoloader [--no-dev] -> kein Faker mehr

# app oraapi
cd ../oraapi
git branch
git pull origin
docker exec  safweb-test-phpfpm php artisan test

Partieller DB-Seed

php artisan db:seed --class=BikrMaschinendatenSeeder
php artisan db:seed --class=BikrProduktlinienSeeder
php artisan db:seed --class=BikrProduktlinieStationenSeeder

Releases erstellen

# copy files from test/app to 3_releases/app-test
sh sync-app-test.sh

# create a Link to Origin Folder (app-test or oraapi-test).
ln -s app-test app-0.1.1

# remove files
rm -f app-test/.env
rm -rf app-test/.git
rm -f app-test/.gitattributes
rm -f app-test/.gitignore
rm -f app-test/.nvmrc

# create Archive
tar -hczvf app-0.1.1.tgz app-0.1.1

# deliver
scp app-0.1.1.tgz safweb@customserver:/tmp

# move tar to /opt/safweb/test
mv /tmp/app-0.1.1.tgz /opt/safweb/test
cd /opt/safweb/test

# unpack tar
tar -xzvf app-0.1.1.tgz
# copy .env from app to new release
APP_ENV=production
APP_DEBUG=false

# Symlink the new Release
rm app
ln -s app-0.1.1 app

Info
Nachdem die Umgebung auf production umgestellt wurde, kann kein db:seed mehr ausgeführt werden. Durch den Optimiser wurde der faker entfernt. D.h. der Datenbankinhalt muss ggf. auf andere Weise importiert werden! Lässt man beim docker exec safweb-test-phpfpm composer install --optimize-autoloader [--no-dev] das –no-dev weg, ist alles wieder möglich, jedoch bleiben die Dev-Pakete dann auch erhalten (mehr Code).

Release für SAFweb2 Transition

Transition ist der Bereich, in dem der develop Branch getestet wird. Sind alle Tests durchgelaufen, dann wird dieser Branch mit dem main Branch gemerged.

Release für Modul SAFweb2 Produktivumgebung

Quick-Start