Sprint 2

Sprintin tavoitteet projektille:

• Samat tavoitteet kuin edellisellä sprintillä.
• Ainakin osassa feature-haarojen pull requesteissa on tehty koodikatselmointeja ja ne on mergattu päähaaraan vasta koodikatselmoinnin jälkeen. How to Review a Pull Request in GitHub the RIGHT Way -video esittelee GitHubin koodikatselmointiprosessia.
• ⭐ Bonus: Voitte halutessanne hyödyntää joissakin koodikatselmoinneissa GitHubin Copilot-tekoälyagenttia. Tämä vaatii GitHub Education -lisenssin aktivointia.
• Sovellukselle on toteutettu joitain testejä ja ne suoritetaan onnistuneesti jatkuvan integraation avulla.
• Sovellus on julkaistu tuotantoympäristössä ja linkki julkaistuun sovellukseen on lisätty README.md-tiedostoon.
• README.md-tiedostossa on dokumentoitu toteutusteknologiat (ohjelmointikielet, sovelluskehykset ja olennaisimmat kirjastot) ja tekniset käyttöohjeet (esim. sovelluksen käynnistäminen ja testien suorittaminen komentoriviltä).
• REST API endpointit (jos toteutettu) on dokumentoitu hyödyntäen esim. Swagger-työkalua.

Viikko 1

“The mad sad glad retrospective frames discussion around the emotional journey of by your team during the previous sprint, and is a great way to identify opportunities to improve team morale and job satisfaction. The retrospective asks participants to share what made them feel frustrated or annoyed (mad), disappointed (sad) and what made them feel happy or proud (glad).” ⎯ Mad Sad Glad Retrospective (TeamRetro)

• Valitkaa sprintille uusi scrum master.
• Järjestäkää scrum masterin johdolla retrospektiivi Mad, sad, glad -formaatissa, jossa käsittelette edellisen sprintin onnistumisia ja haasteita.
  • Hyödyntäkää jotain valkotaulusovellusta, kuten Flinga, retrospektiivin järjestämisessä. Tässä esimerkki retrospektiivitaulusta Flingassa.
  • Kerätkää retrospektiivitaululle sprintin aikaisia kokemuksia ja keksikää yhdessä konkreettisia parannusehdotuksia prosessillenne tulevaa sprinttiä varten.
• Muodostakaa sprinttiä varten user storyja sekä niihin liittyviä taskeja ja lisätkää ne backlogille.
• Alkakaa toteuttamaan backlogin user storyja.

Viikko 2

• Julkaiskaa sovellus tuotantoympäristössä. Tässä ohjeita julkaisuun:
  • Spring Boot backend sovelluksen julkaisu
  • Vite frontend sovelluksen julkaisu
• Lisätkää linkki julkaistuun sovellukseen README.md-tiedostoon.
• Dokumentoikaa README.md-tiedostossa toteutusteknologiat (ohjelmointikielet, sovelluskehykset ja olennaisimmat kirjastot) ja tekniset käyttöohjeet (esim. sovelluksen käynnistäminen ja testien suorittaminen komentoriviltä).
• REST API endpointtien dokumentoinnissa kannattaa hyödyntää Swagger-työkalua.
  • Tässä esimerkki, miltä Swaggerin avulla generoitu dokumentaatio näyttää.
  • Esimerkkisovelluksesta löytyy esimerkkejä Swaggerin käytöstä.
  • Lisätkää README.md-tiedostoon linkki Swagger-dokumentaatioon (Rahti-sovelluksessa muotoa https://nameofyourrahtiapp.2.rahtiapp.fi/swagger-ui/index.html).
• Toteuttakaa sovelluksen joitakin automatisoituja testejä. Esimerkkisovelluksesta voi ottaa mallia REST API endpointtien integraatiotestaukseen.

Viikko 3

“Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project. It’s a primary DevOps best practice, allowing developers to frequently merge code changes into a central repository where builds and tests then run. Automated tools are used to assert the new code’s correctness before integration.” ⎯ What is continous integration? (Atlassian)

• Valmistelkaa lyhyt demo sprintin tuotoksista seuraavan opetuskerran sprintin katselmointia varten. Varmistakaa, että tuotantoympäristössä on sovelluksen toimiva versio ennen sprintin katselmointia. Jos mahdollista, esitelkää katselmoinnissa sovelluksen toiminnallisuuksia tuotantoympäristössä.
• Jatkuva integraatio (continuous integration) mahdollistaa automatisoidun laadunhallinnan ohjelmistoprojekteissa. Lukekaa GitHubin Continuous integration -ohje ja ottakaa projektissanne käyttöön jatkuva integraatio GitHub Actions -palvelun avulla. Jatkuvan integraation tulee ainakin suorittaa testit ja varmistaa, että ohjelma kääntyy (esim. JARin muodostus Maven-projektissa ./mvnw package-komennolla). Esimerkkisovelluksesta löytyy GitHub Actions workflow-esimerkki.
• Lisätkää GitHub Actions workflow status badge README.md-tiedoston alkuun.
• Tehkää sprintin päätteeksi sprintille GitHub release. Lisätkää releasen kuvaukseen lyhyt kuvaus sprintin aikana toteutetuista toiminnallisuuksista.