Entwicklung, Release und Betrieb

Lokales Setup

python3 -m venv .venv
.venv/bin/pip install -e '.[dev]'
cp .env.example .env
.venv/bin/uvicorn app.main:app --reload

SILLYHOME_HA_URL und SILLYHOME_HA_TOKEN nur lokal in .env setzen.

Qualitätsprüfung

.venv/bin/pytest -q
.venv/bin/ruff check .
.venv/bin/mypy app backend tests
git diff --check

Release

Version in allen vier Stellen ändern: pyproject.toml, addon/config.yaml, app/main.py, CHANGELOG.md.
Qualitätsprüfung ausführen.
Feature-Branch committen und pushen.
Pull Request nach main erstellen und mergen.
Annotiertes Tag auf dem Merge-Commit erstellen.
Gitea-Release aus demselben Tag erstellen.

Beispiel:

git tag -a v0.7.0 -m 'SillyHome Next 0.7.0'
git push origin v0.7.0

Home-Assistant-Update

Vorher Teil-Backup des Add-ons erstellen. Danach:

ha store reload
ha apps info 58adbe1e_sillyhome_next
ha apps update 58adbe1e_sillyhome_next
ha apps info 58adbe1e_sillyhome_next
ha apps logs 58adbe1e_sillyhome_next

Kein Home-Assistant-Neustart ist erforderlich.

Live-Verifikation

Pflicht:

wget -qO- http://58adbe1e-sillyhome-next:8000/health
wget -qO- http://58adbe1e-sillyhome-next:8000/v1/actuators

Für einen Aktor prüfen:

behavior.mode
behavior.activation_ready
behavior.activation_reason
behavior.related_automations
behavior.paused_automation_entity_ids
behavior.prediction.execution_reason

Bei einer Übernahme testen:

Passende HA-Automation ist vorher on.
SillyHome übernimmt.
SillyHome ist active.
Passende HA-Automation ist off.
Trigger erzeugt erwartete Aktoraktion.
Gegenaktion wird trotz Cooldown ausgeführt.
SillyHome stoppen und Automationen fortsetzen.
SillyHome ist shadow, HA-Automation wieder on.

Rollback

Bevorzugt das vor dem Update erstellte HA-Teil-Backup wiederherstellen. Alternativ vorherige Git-Version in addon/config.yaml veröffentlichen und das Add-on erneut aktualisieren.

2.0 KiB Raw Blame History