Entwicklung
Einrichtung
Generelle werden folgende abhängigkeiten benötigt:
Nach der Installation von Python und Pip können wir nun das Projekt einrichten.
Dazu öffnen Sie bitte ein Terminal ein und navigieren mit dem Befehl cd zu einem Ordner, in dem Sie das Projekt ablegen wollen.
Nachdem Sie dies gemacht haben, holen Sie sich die Projekt Dateien mit folgendem Befehl:
git clone https://git.sh-edraft.de/sh-edraft.de/kd_discord_bot.git
Nun müssen Sie in den Ordner des Projektes gehen.
cd kd_discord_botld
Als nächstes erstellen und aktivieren Sie ein VirtualEnv von Python:
# erstellen:
python -m venv venv
# aktivieren:
# linux:
source venv/bin/activate
# windows:
.\venv\Scripts\activate
Nachdem das venv nun erstellt wurde, benötigen noch die CPL. Diese Installieren Sie in der Virtuellen Umbebung nach dieser Anleitung.
Führen Sie den Befehl cpl v aus, um zu sehen ob alles richtig installiert wurde.
Wenn der Befehl bei ihnen lief, können Sie nun weitere Pakete des Bot installieren.
cpl install
Der Befehl installiert alle Abhängikeiten, die in der Projektdatei angegeben sind.
Um zu testen, ob Sie alles richtig eingerichtet haben, können Sie den folgenden Befehl Ausführen.
Dieser sollte einen Ordner ```dist``` erstellen.
```sh
cpl bui
Nach der Installation starten Sie den Bot:
```sh
cpl start
# Wenn Sie Entwickeln wollen:
cpl dev
# Wenn Sie Testen wollen:
cpl test
# Wenn Sie im Production Modus testen wollen:
cpl prod
Nun richten Sie die IDE ein, die Sie verwenden wollen.
VS Code
Um adequat mit Python arbeiten zu können benötigen Sie ein paar Extensions:
- Pylance
- Python
- Python Docstring Generator
- Python Test Explorer for Visual Studio Code
- python-snippets
- Importmagic
Sie sollten für Importmagic ein Keyboard Shortcut anlegen:
ImportMagic: Resolve Import -> Alt+Enter
VS Code sollten Sie dann einmal neustarten und die Entwicklung kann ab dann losgehen.
Bot Einstellungen
Nachdem Sie nun das Projekt auf ihren PC Kopiert haben und alle Schritte bfolgt haben, sollten Sie folgende Ordnerstrucktur vorfinden:
kd_discord_bot/
dist/
src/
bot/
bot_cli/
bot_core/
bot_data/
modules/
tools/
venv/
.gitignore
cpl-workspace.json
LICENSE
README.md
In den Ordner src/bot/ müssen die Einstellungen in den Dateien Appsettings gespeichert werden.
Sie sollten nur die Datei appsettings.json sehen, in dieser Datei können Sie ihre Einstellungen auch vornehmen dies ist jedoch nicht zu Empfehlen.
Sie sollten eine Datei erstellen, die anstatt des Platzhalters ihren Rechnernamen oder die Umbebung in der Sie arbeiten enthalten. Beispiele:
Umgebung:
appsettings.production.json
appsettings.staging.json
appsettings.development.json
Rechnername:
appsettings.MEIN-PC.json
Standard:
appsettings.json
Sie können folgenden Inhalt in die Datei Kopieren, Sie müssen unbedingt die fehlenden Werte eintragen!:
{
"DatabaseSettings": {
"Host": "",
"User": "",
"Password": "",
"Database": "",
"Charset": "utf8mb4",
"UseUnicode": "true",
"Buffered": "true",
"AuthPlugin": "mysql_native_password"
},
"Discord": {
"Token": ""
},
"Bot": {
"Prefix": "",
"Servers": [
{
"Id": "",
"LoginMessageChannelId": "",
"LoginMessage": "",
"MessageDeleteTimer": 6
}
]
}
}
Versionierung
Major.Minor.Micro
Major wird nur geändert, wenn der neue Stand nicht Kompatibel mit dem alten Stand ist. Minor wird bei jeder neuen Funktion erhöht. Micro wird bei kleinen Änderungen oder Patches erhöht.
Es werden Folgende Versionen vorgesehen:
Bis Ende der Alpha: 0.SprintNummer.StoryNummer
Ab Ende der Alpha Entwicklung: 1.SprintNummer.StoryNummer.aN
Ab Beginn der Beta: 1.SprintNummer.StoryNummer.bN
Ab Ende der Beta: Major.SprintNummer.StoryNummer
Stories
Jede Story bekommt eine Version, anhand der sie auch Identifierzeit werden kann. Es wird während der Entwicklungsphase eine Kennung mit dem Stadium angehangen. Sobald das MVP (Minimum Viable Product, Minimum Viable Product ist die einfachste Konfiguration eines Produkts, die ein Benutzer testen und bewerten kann) bereitsteht, wird die Entwicklungsphase verlassen und ein Release 1.0 erstellt. Ab dem Zeitpunkt fallen die Prefixe für Stories weg.
Stadien:
- Alpha
- Beta
Bsp.:
A-0.6.1 - Beschreibung
B-0.13.4 - Beschreibung
1.0.2 - Beschreibung
Developmental releases
Für Versionen die sich noch in der Entwicklung befinden, jedoch schonmal gebaut werden müssen, wird ein devN angehangen.
Bsp.:
1.2.3.dev1
1.2.3.dev2
1.2.3.dev3
Pre-releases
Alpha und Beta Versionen werden durch ein a|bN markiert.
Für Versionen, die getestet werden müssen, wird ein rcN angehangen.
Wenn Fehler aufreten, werden diese im Rahmen des nächsten rc gefixed. Es wird darauf verzichtet andere Versionsänderungen vorzunehmen.
Bsp.:
1.0.1.a1
1.0.2.a1
1.0.2.a2
1.1.1.b1
1.1.2.b1
1.1.2.b2
1.2.0.rc1
1.2.0.rc2
1.2.0.rc3
Post-releases
Für Änderungen, die kleinere Fehler beheben, jedoch keinen weiteren Einfluss auf das Produkt haben wird ein postN angehangen.
Branches
Alle Änderungen am Code werden auf externen Branches zum master bearbeitet.
Es wird für jeden Sprint ein Branch erstellt.
Es wird für jede Story ein Branch erstellt, sobald diese bearbeitet wird (nicht vorher!). Dieser Branch basiert auf den Branch des Sprints.
Minor Stories also Stories, dessen Version aus zwei ziffen besteht bekommen ebenfalls ein Branch. Micro Stories die auf der Minor Story basieren werden vom Branch der Minor Story abgewandelt.
Bevor die Minor Story wieder auf den Branch des Sprints geführt werden kann, MÜSSEN alle Micro Stories beendet und in den Branch der Micro Story eingefügt sein!
Nach bearbeitung einer Story wird ein Pull Request erstellt. Dieser beantragt das Einfügen der Story in den Sprint.
Das ganze sollte dann so aussehen:
- Sprint: Alpha
- Minor Story: #issue-id
- Micro Story: #issue-id-1
master
|
\
|\
| \
| \
| Alpha
| |
| \
| |\
| | \
| | \
| | #id
| | |
| | \
| | |\
| | | \
| | | \
| | | #id-1
| | | |
| | | /
| | | /
| | | /
| | |/
| | /
| | |
| | /
| | /
| | /
| |/
| /
| |
| /
| /
| /
|/
/
|
Pull Requests
Pull Requests werden erstellt, wenn ein Branch in einen anderen eingefügt werden kann.
Die Pull Requests finden Sie hier.
Pull Requests werden erst überprüft und müssen von einem anderen Entwicker genehmigt werden. Dabei werden letzte Änderungen vorschlagen, damit z.B. Toter Code nicht weiter übermittelt wird. Sobald das Code Review Erfolgreich war, werden die Branches gemerged. Danach wird der Branch gelöscht welcher gemerged wurde.