Continuous integration serverless aplikace založené na AWS Lambda — 2.část — jak pracujeme s gitem

Adam Šenk
Feb 20, 2018 · 4 min read

Git, jak známo, je verzovací nástroj, který slouží ke správě změn zdrojového kódu. Rád bych vás nejdříve seznámil s naším stylem práce s gitem a pravidly, kterými se všichni vývojáři řídí, tak abychom zaručili co nejlepší kvalitu produkovaného kódu (ve smyslu co nejmenší chybovosti, dobré strukturovanosti, jednotného code-stylu apod.)

Úvodní díl najdete zde.

Základní git setup

Náš repozitář obsahuje tři základní větve, které odpovídají i běhovým prostředím. Jsou to: dev, test a master (production). Tyto větvě jsou chráněné (protected), takže není možné aby jakýkoliv vývojář do nich pushoval. Změny mohou být provedeny pouze mergem s jinou, změnovou větví.

Nové featury, či opravy bugů, jsou nejprve přidány do větve dev. Teprve po důkladném otestování jsou tyto změny zamergovány do větve test případně master. To znamená, že větve master a test jsou vždy pozadu oproti větvi dev, případně jsou v naprosto totožném stavu.

Git worflow

Vývoj featury / fix bugy na separátní větvi

Každý vývojář který pracuje na implementaci nové featury, případně opravuje nějaký bug, pracuje na vlastní větvi.

  • Vývojář si stáhne do svého PC aktuální verzi repozitáře.
  • Vytvoří si vlastní branch. Branch vychází z aktuálního stavu větve dev. Název branche odpovídá číslu ticketu issue_2, případně aspoň vyjadřuje o co se jedná — například hotfix_login.
  • Vývojář změny jsou průběžně commituje. Jednotlivé commity jsou atomické, a popsány adekvátní commit message.

Push větve do centrálního repozitáře

  • Ve chvíli kdy je práce dokončena je nutné zamergovat změny, které mohli proběhnout na centrální repozitoři, ve větvi dev. K tomu použijeme příkaz git rebase.
  • Pokud dojde ke konfliktům je nutné, musí vývojář konflikty vyřešit, změny commitnout a vrátit se k předchozímu kroku.
  • Ve chvíli kdy je větev rebasovaná a nejsou v ní konflikty je možno jí pushnout do centrálního repozitáře.

Merge request

  • Merge request vytvoříme buď přímo v gitlabu, nebo přes odkaz, který nám vrátí gitovský CLI (command line interface)
  • Merge request posuzuje vývojář, který daný kód nevyvíjel.

Základní přínosy Merge Requestů

Pravidlo, že každá změna projde schvalovacím procesem, ve kterém změněný k prohlédne programátor, který ho neprogramoval, jsme zavedli z několika důvodů. Jsme přesvědčení, že tento proces pomáhá jak samotnému projektu, tak i všem programátorům. Zde je shrnuto proč:

  • Merge request a jeho schválení druhým člověkem je další možnost jak odhalit chybu během softwarového vývoje. Samozřejmě je nutné veškerý nový kód řádně otestovat, přesto můžeme nějaký problém přehlédnout. Tato šance je mnohem menší, pokud veškeré změny prohlídne další člověk.
  • Tento proces také způsobí, že se jednotliví členové více dozvídají o práci druhých. Vědí tak mnohem více i o částech projektu, na kterých zrovna nepracují a to jim umožní snadněji a rychleji se zorientovat v kódu, který nepsali, ve chvíli, kdy je to nutné.
  • Třetím významným přínosem je rychlejší šíření znalostí v týmu. Tím mám namysli například situaci, kde jeden kolega začne používat novou knihovnu. Další člen týmu, který schvaluje merge request ve kterém je knihovna použita, se tak o její existenci doví. Nebo i naopak. Při schvalování merge requestu narazím na místo, které by šlo vyřešit elegantněji za použití nové knihovny, ale jak je vidět, ostatní kolegové ji ještě neznají.. Mohu tedy ihned o ní dalším členům týmu říci.

Gitlab vs AWS CodeCommit

Pro správu zdrojových kódů našeho projektu jsme se rozhodli použít GitLab. Ačkoliv Amazon AWS má vlastní službu, s názvem CodeCommit, poskytující git repozitář, uvedu zde důvody proč nakonec vyhrál GitLab:

  • GitLab nabízí nejen git repozitář, ale další podpůrné služby jako Wiki nebo Issues (správa ticketů), které používáme.
  • Líbí se nám uživatelské rozhraní a funkcionalita GitLabu, která umožňuje dobře pracovat s merge requesty, komentovat jednotlivé změny, zveřejňovat code snippety atd. Některé funkcionality nabízí i CodeCommit ale Gitlab se jeví uživatelsky přívětivější.
  • Základní funkce a hostování projektů na gitlabu je zdarma. Pokud budete chtít, můžete GitLab (který je mimochodem open-source), nasadit na svých serverech.
  • Obecně se kloníme k názoru, že je lepší mít git repozitář vyčleněný mimo AWS, kdyby z nějakého důvodu člověk k běhu svých aplikací nechtěl využívat pouze Amazoní služby.
  • A nakonec, jsme na GitLab zvyklí, což je také podstatná motivace.

Osobně nepovažuji volbu konkrétního git řešení za podstatnou, vyberte si jednoduše tu, která vám vyhovuje a kterou budete rádi používat. AWS je možno integrovat se všemi rozšířenými řešeními.

Git, AWS a Continuous Integration

V příštím díle se budu věnovat tomu jak propojit git a AWS tak, aby všechny provedené změny byly co nejdříve nasazeny do příslušného prostředí. Díky této integraci se nemůže stát, že nasazená verze kódu neodpovídá stavu kódu v gitu, což je jeden z nejnepříjemnějších problémů při odhalování bugů.

Tleskejte, komentujte, dejte mi zpětnou vazbu. Díky.

Následující díl najdete tady!

MessageOk.com / devblog

Zajímavosti a zprávy ze zákulisí messageok

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store