CI setup - gode-ting/hackerNews-clone-project GitHub Wiki

Vores CI setup.

• Udviklerne

Udvikleren har hver deres kopi af source koden. De vil løbende pull eller push vha. git til et github, som er samlingspunkt for vores source kode, og en stor brik i vores CI-chain. Det gør de ved brug af branches og pull requests på github.

• Github.

Central for source koden, som fungerer som bindeled mellem udviklerne og den videre process af den kode, som udviklerne pusher hertil. Vi arbejder med branches, så vi kan foretage ændringer i vores kodebase og følge vores resterende CI setup uden, at vi pusher direkte til master branchen, som er “produktionskoden”. En branch er første step for udvikleren på Github, som bindeled mellem dem og de resterende CI steps. Vi bruger pull-requests til at få code reviews og få testet vores kode. Ved brug af pull-request er det nemt for gruppens resterende medlemmer, at give inputs og feedback på de ændringer som er foretaget. Samtidig overvåger Travis pull-requests, og kører testene på disse så snart de bliver oprettet. Derved kan man hurtigt som om der er tests der fejler, som skal rettes inden kode ændringer kan gå videre til næste CI step.

• Travis.

Hjælper med at bygge vores projekt, og teste det (vi mangler flere automatiserede tests). For at benytte os af praksissen, har vi benyttet os af forskellige værktøjer. Værktøjerne har haft til formål, at hjælpe os med at kunne fuldbyrde praksissen så godt som muligt. Af de værktøjer vi har benyttet os af, kan nævnes: Git og Github. Git giver os mulighed for at have en shared codebase og et versionsstyringssystem. Github giver os mulighed for at hoste vores git projekt. Vi kommer nærmere ind på disse to i et senere afsnit.

• Travis.

Automatiseret testing af vores kode base, sammen med Github. Travis er koblet op på github, og det gør, at vi nemt og hurtigt kan teste vores kode. Vi har ikke nået at skrive nogen nærmere integrations- eller unit tests, som havde forbedret vores continuous integration væsentligt, men princippet er stadig det samme; inden de ændringer udviklerne foretager bliver pushet til produktion, bliver de testet på en bygge server. Hvis der er fejl heri, vil bygge serveren stoppe processen.

• Waffle.

Minder lidt om et scrumboard. Integrerer med Github, og bruges til at arbejde med Github issues. Har hjulpet os med at strukturere projektudviklingen, så alle gruppemedlemmer kunne se hvem der arbejdede på hvad, og udvælge sig en task/issue ud fra hvad der var næste i rækken