- Ściągnąć i zainstalować:
- Konfiguracja WildFly
- Uruchomić serwer (/bin/standalone.bat)
- Sprawdzić czy uruchomił się poprawnie (np. czy wszystkie standardowe porty tcp były wolne: 8080, 9990, 9999 itd.)
- Utworzyć użytkownika administracyjnego komendą /bin/add-user.bat
- Sprawdzić czy można się zalogować tym użytkownikiem do konsoli administracyjnej (http://localhost:9999)
- Utworzenie bazy danych
- %JBOSS_HOME%/bin/jboss-cli.bat --connect --file=h2_database.cli
- Zbudowanie aplikacji
- mvn clean package
- Rozproszenie aplikacji na serwerze
- Zalogować się do konsoli administracyjnej, a potem Deployments/Add/Upload a new deployment/Next/Browse.../Znaleźć plik war /openpkw-weryfikator/openpkw-rest/target/
- Sprawdzenie czy aplikacja się rozproszyła
- Postmanem (lub innym klientem REST) wysłać na adres http://localhost:8080/openpkw/test/echo POST z nagłówkiem Content-Type=application/json i body {"test":"OpenPKW Weryfikator zawojuje świat"}
- TEST (automatyczne testy integracyjne i akceptacyjne): http://rumcajs.openpkw.pl:9080/openpkw/
- UAT (ręczne testy integracyjne i regresyjne): http://dobromir.openpkw.pl:9080/openpkw/
- STAGE (ręczne testy regresyjne, demonstrowanie nowych funkcji, szkolenia): jeszcze nie ma
- PROD (wykorzystywane podczas wyborów): jeszcze nie ma
- Zadania definiujemy w Trello. Wszystkie osoby udzielające się w OpenPKW powinny mieć konta w Trello i dostęp do tablic dla poszczególnych komponentów.
- Zadania definiujemy najczęściej podczas spotkań wtorkowych, ewentualnie podczas dyskusji mailowej lub na czacie w Skype.
- Zadania powinny być dobrze opisane, tj. mieć sensowną nazwę i kryteria akceptacyjne.
- Stosujemy prefiksy ułatwiające identyfikowanie zadań: OW-typ_zadania-nr_zadania. OW oznacza openpkw-weryfikator, a typy zadań to: U-user_story (nowa funkcjonalność lub modyfikacja istniejącej funkcjonalności), R-refactoring, B-bug, I-infrastruktura itd.
- Kod tworzony jest na branchach w repozytorium openpkw/openpkw-weryfikator. Wszyscy programiści mają prawa do zapisu do tego repozytorium.
- Nazwy branchy powinny odpowiadać nazwom tasków w Trello, czyli albo sam prefix (np. OW-U-7), albo prefix-opis (np. OW-U-7 Bardzo fajna funkcjonalność).
- Kod przed mergem do brancha master przechodzi proces code review. Celem jest zarówno sprawdzenie czy zaimplementowane jest to, co miało być, jak i sprawdzenie jakości kodu, standardów formatowania, kodowania itd.
- Review rozpoczynamy utworzeniem pull requesta z brancha taskowego do brancha master.
- Code review wykonują inni członkowie zespołu OpenPKW. Komunikacja: github, Skype, email, telefon, co się da. Idealnie jest, jeśli na temat zmiany wypowiedzą się wszyscy.
- W ramach code review koniecznie trzeba zbudować kod z brancha na Jenkinsie, rozproszyć na środowisku TEST i uruchomić automatyczne testy akceptacyjne. Jenkins jest tak skonfigurowany, że zmiany wchodzące na wszystkich branchach są automatycznie budowane i testowane, ale jeśli infrastruktura zawiedzie (a na razie czasem jeszcze zawodzi), trzeba to wykonać ręcznie.
- Po zakończeniu code review akceptujemy pull request w githubie, kod trafia do brancha master i jest automatycznie budowany, testowany, rozpraszany na środowisku TEST itd.
- Jako ostatni krok można pchnąć zmianę na środowisko UAT. Robi się to ręcznie uruchamiając krok 04_Deploy_to_UAT na Jenkinsie.
W katalogu głównym projektu:
mvn clean package
Nie robimy mvn install ponieważ komenda install automatycznie uruchomi komendę integration-test, która wykorzystywana jest do uruchamiania automatycznych testów akceptacyjnych aplikacji rozproszonych na serwerach w środowisku TEST. Jeśli nic nie jest rozproszone w środowisku TEST lub jest tam stara wersja, to komenda integration-test się nie powiedzie. Dlatego do budowania używamy tylko komendy package.
W katalogu openpkw-rest:
mvn wildfly:deploy -Dopenpkw-env:local|vagrant|test|deploy
Parametr openpkw-env określa na które środowisko robimy deployment. Podczas wykonywania tego kroku Maven poprosi o hasło do konsoli administracyjnej WildFly. Należy je wpisać z klawiatury, ewentualnie można je przekazać jako parametr Mavenowi. Ze względów bezpieczeństwa haseł tych nie ma w kodzie źródłowym ani nigdzie indziej na GitHubie. Jest przekazywane wszystkim programistom OpenPKW.
W katalogu głównym projektu:
mvn verify -Dmaven.test.failure.ignore=false -DskipIntegrationTests=false
Komenda ta uruchomi testy względem aplikacji rozproszonej w środowisku TEST (i zawsze na tym, na razie URLe są zahardcodowane).
Przy dodawaniu odpowiednich dependency do pom-ów proszę korzystać z głównego pom-a, gdzie większość została zawarta. W projektach dziedziczących należy dodać do pom-ów tylko groupId i artifactId - wersja i scope zostaną odziedziczone z parenta.
Gdy będzie potrzeba dodania nowej biblioteki do projektu prosiłbym o zgłaszanie do [email protected]. Chciałbym abyśmy zachowali spójność używanych bibliotek.