Posledním krokem je pravidelná kontrola a testování. Projděte všechny vstupy, včetně skrytých polí, hlaviček a souborů cookie, protože i ty se mohou dostat do dotazu. Do vývojového procesu zařaďte automatické testy, které zkoušejí běžné payloady, a před nasazením proveďte revizi kódu zaměřenou na práci s databází. Bezpečnost není jednorázová úprava, ale opakovaná rutina.
Rozdělení práce mezi vlastní tým zní lákavě: žádné faktury, žádné čekání na cizí lidi, všechno pod kontrolou. Jenže právě tady vzniká většina zpoždění. Nejde o to, že by interní lidé byli horší než externisté. Jde o to, že projekt s vlastním týmem nemá žádné přirozené hranice. Práce se rozplyne do běžného provozu a najednou není jasné, kdo co dělá a do kdy.
Začněte tím, že si každý před prací stáhne aktuální stav hlavní větve. Z ní vytvoří novou větev s krátkým, výstižným názvem podle toho, co řešíte. Do větve dělejte malé commity, ideálně několik za den. Jeden commit má obsahovat jednu logickou změnu. Když do jednoho commitu zamícháte opravu překlepu, změnu konfigurace a novou funkci, při pozdějším hledání chyby budete litovat. Zpráva commitu má říct, co změna dělá, ne jak jste se u toho cítili.
Poslední vrstvou je omezení práv databázového účtu. Aplikační účet nemá mít právo měnit strukturu, vypínat triggery ani přistupovat k tabulkám, které nepotřebuje. Když se injektáž přesto prosadí, škoda zůstane omezená. Kontrolu dělejte pravidelně, ne jednou při nasazení. Práva se v čase rozšiřují a zapomenuté granty zůstávají. Bezpečnost není jednorázové nastavení, ale rutina, která přežije i vaše další vydání.
Třetí pravidlo se týká velikosti změn. Integrujte často a po malých částech. Pokud je to možné, slučujte hotové dílčí části funkce do hlavní větve průběžně, ne až na konci. Velká větev s desítkami commitů je noční můra při řešení konfliktů. Menší, častější sloučení znamenají menší konflikty a snadnější identifikaci chyby. Pokud funkce není hotová, použijte feature flag a sloučte neaktivní kód. Aktivujete ho, až bude vše připraveno.
Čtvrté pravidlo: konflikty řešte okamžitě a lokálně. Jakmile se objeví konflikt při sloučení, nenechávejte ho na později. Otevřete soubor, pochopte, co se změnilo v obou větvích, a rozhodněte se vědomě. Nikdy neklikejte na automatické přijetí všech změn z jedné strany. Typická chyba je slepé přijetí vlastní verze, čímž se ztratí práce kolegy. Po vyřešení konfliktu spusťte testy. Konflikt může být vyřešen syntakticky správně, ale logicky špatně.
Testování mobilních aplikací stojí na dvou pilířích: ručním průzkumu a automatizaci. Rozdíl mezi nimi není v tom, který je lepší, ale v tom, co který dokáže odhalit. Ruční testování vyniká tam, kde jde o vzhled, plynulost a chování při reálném používání. Automatizace zase zvládne opakovat stovky scénářů bez únavy. Rozhodující je pochopit, kdy nasadit který přístup.
Prvním krokem je stanovit, co je hlavní větev. Obvykle to je stabilní linie, do které se integrují hotové funkce. Z ní vždy odbočujete a do ní se vracíte. Nikdy necommitujte přímo do hlavní větve, pokud na ní pracuje více lidí. Druhé pravidlo zní: než začnete novou větev, aktualizujte si lokální kopii hlavní větve. Tím zajistíte, že odbočujete z nejnovějšího stavu, a snížíte riziko, že budete muset řešit konflikty, které už dávno vyřešil někdo jiný.
Rebase místo merge a kdy ho použít Pro udržení čisté historie používejte rebase své funkční větve na hlavní linii. Rebasing přepíše vaše commity tak, jako byste je vytvořili až po posledních změnách v hlavní větvi. Výsledkem je lineární historie bez zbytečných merge commitů. Pozor ale na jednu věc: nikdy nedělejte rebase větve, kterou už někdo jiný stáhl a pracuje na ní. Přepíšete tím jeho historii a způsobíte chaos. Rebase je bezpečný pouze pro vaše lokální, nesdílené větve.
Práce na několika funkcích současně je běžná realita, ale bez jasných pravidel vede k nekonečnému řešení konfliktů a ztracené práci. Základem je krátkodobé větvení. Každá funkce dostane vlastní větev, která vychází z aktuální hlavní větve. Nevytvářejte dlouho žijící větve, do kterých se měsíce přidávají další a další změny. Čím déle větev žije, tím větší je riziko, že se rozejde s hlavní linií a sloučení bude bolet.
Projekty s vlastním týmem nepadají na nedostatku schopností, ale na nedostatku hranic, rozhodnutí a průběžné kontroly. Kdo si tyto tři věci nastaví předem, mívá projekt hotový v rozumném čase i bez externí pomoci.
Na co si dát pozor: nesnažte se rebasovat větev, která obsahuje merge commity z jiných větví. Výsledek je nepředvídatelný. Dále nikdy necommitujte konfigurační soubory, které se liší stroj od stroje. Používejte lokální konfiguraci, která není součástí repozitáře. A pokud pracujete na více funkcích současně, přepínejte větve jen s čistým pracovním stromem. Necommitnuté změny si před přepnutím buď commitněte, nebo odložte stranou. Jinak si je přenesete do špatné větve a budete je pracně hledat.