System do obsługi cyklu dydaktycznego w Instytucie Informatyki Uniwersystetu Wrocławskiego. Za pomocą tego systemu: Nauczyciele tworzą swoje propozycje nowych przedmiotów; Studenci kształtują ofertę dydaktyczną poprzez głosowanie na te propozycje; Dyrekcja Instytutu przydziela zajęcia prowadzącym; Studenci zapisują się na zajęcia; W końcu studenci oceniają swoich nauczycieli w anonimowych ankietach. System zarządza też tematami prac dyplomowych i pozwala studentom je rezerwować.

Do postawienia developerskiej wersji systemu zapisów musimy mieć zainstalowanego Vagranta oraz Virtualboxa. Klonujemy niniejsze repozytorium na nasz komputer i odpalamy z niego polecenie vagrant up. Na naszym komputerze zostanie skonfigurowana maszyna wirtualna z uruchomionym testowym serwerem, który można odwiedzić pod adresem 0.0.0.0:8000. Folder projektzapisy na naszym komputerze jest współdzielony z maszyną wirtualną (folder /vagrant), więc serwer łapie na żywo wszystkie zmiany w robione przez nas w kodzie. Więcej informacji o maszynie developerskiej można przeczytać w instrukcji.

Jeżeli zamierzasz zajmować się frontendem, warto zapoznać się też z opisem systemu plików statycznych.

System Zapisów jest podzielony na moduły (zwane aplikacjami). Każda aplikacja definiuje swoje własne typy danych (modele), którym odpowiadają automatycznie obsługiwane tabele w bazie danych. Każda aplikacja dba o swoje własne ścieżki (URL-e) i implementuje funkcje odpowiadające na zapytania HTTP (zwane widokami). Powiązania między aplikacjami są realizowane poprzez importowanie kodu z jednego modułu do drugiego oraz przez klucze obce w bazie danych. Zwięzły opis wszystkich aplikacji w naszym systemie tutaj.

Każda zmiana w modelach musi zostać odzwierciedlona w schemacie bazy danych, co Django rozwiązuje migracjami — małymi skryptami w Pythonie, które mówią, jak ma się zmienić schemat bazy danych. Migracje można automatycznie wygenerować poleceniem python zapisy/manage.py makemigrations (w maszynie wirtualnej), ale czasem trzeba je ręcznie przerobić, jeśli zmiana w modelach wymaga transformacji danych.

Proces instalacji i konfiguracji maszyny produkcyjnej jest mocno zautomatyzowany dzięki narzędziu Ansible. Instrukcje w katalogu infra/.

Zespół Systemu Zapisów tworzą w każdym semestrze studenci uczęszczający na przedmiot Rozwój Systemu Zapisów. Lider projektu jest zarazem prowadzącym przedmiot. W naszej pracy używamy następujących narzędzi:

• Slack — nasz główny komunikator.
• Rollbar — raportuje o błędach (wyjątkach) pojawiających się na produkcji.
• Travis CI — testowanie kodu.
• New Relic — monitorowanie wydajności serwera.

1. Gdy zaczynamy pracować nad jakimś zadaniem, tworzymy gałąź, która odgałęzia się od master-dev. W swojej własnej gałęzi możemy przepisywać historię, szczególnie jeśli ma nam to pomóc zaktualizować się w stosunku do master-dev.
2. Po ukończeniu tworzymy Pull Requesta z bazową gałęzią master-dev. Zaznaczamy lidera projektu do code-review. PR musi być ładnie i jasno opisany — opis ten może w przyszłości pomóc komuś zrozumieć intencje stojące za zmianą w kodzie.
3. Proces code-review, dyskusji i nanoszenia poprawek zazwyczaj składa się z więcej niż jednego etapu. Należy na niego zarezerwować z grubsza tyle czasu, co na przygotowanie PR-a.
4. Zaakceptowane Pull Requesty będą scalane przez lidera projektu za pomocą git merge --squash. Nie musimy się zatem wstydzić rewizji (commitów) w naszej gałęzi.
5. Co jakiś czas (około dwóch tygodni-miesiąca) robiony jest deploy na produkcję. Gałąź master przechowuje wersję produkcyjną.