Következő fejezet: 3. Beállítások, konfigurációkezelés
Egy korábbi bejegyzésben elkezdtük feldolgozni a szoftverpusztulás elkerüléséhez tanácsolt lépéseket. Most lépjünk a következő pontra:
2. Függőségek kezelése
A tanács: mindig explicit módon deklaráljuk és különítsünk el a függőségeket.
A legtöbb programozási nyelvben rendelkezésre áll már csomagkezelési megoldás, ami támogatja könyvtár modulok becsomagolását és csomagban terjesztését. A .NET világban a NuGet (egy régebbi, de részletes cikk erről) megoldását használjuk, Ruby nyelven fejlesztőknek ott a Rubygems. És a teljesség igénye nélkül néhány példa még: A Phyton-nál a Pip és a Virtualenv, a nodejs-nél az npm, a PHP-t nem ismerem túl jól, de a Composer és a Packagist lennének az első jelöltjeim. A JavaScriptnél pedig ezekből választhatunk: npm, bower, Ender, volo, component és jam.
A csomagkezelő megoldásunk segítségével egyrészt telepíthetjük a könyvtárainkat rendszer szinten, ekkor minden telepített alkalmazás használhatja őket (ilyesmi például a .NET global assembly cache, vagy többféle nyelven a "site package"). Vagy telepíthetjük a könyvtárainkat az alkalmazásunkkal együtt, egy csomagban, kizárólagos használatára (ilyenek az alkalmazásunkhoz telepített nuget csomagok például).
A 12 tényezős alkalmazásfejlesztés soha nem feltételez rendszerszinten rendelkezésre álló könyvtárakat.
(Erre jó példa a .NET Core/ASP.NET Core újdonságai közül például, hogy a .NET futtató környezetet az új .NET alkalmazásokhoz NuGet csomagokkal telepíthetjük. Erről némi információ: NuGet is a .NET framework release vehicle és ASP.NET vNext will let you deploy your own version of the .NET Framework on an app-by-app-basis,)
Az alkalmazás, (ami követi a 12 tényezős alkalmazásfejlesztés tanácsait) az összes függőségét pontosan deklarálja a függőségi deklarációs jegyzékében (pl.: NuGet csomagkezelő esetén a package.config állományban). Ezen túlmenően az alkalmazás a függőségeket elkülönítő megoldást használ a futtatás során, ami biztosítja, hogy hogy nincs implicit (nem pontosan definiált, csak valamilyen egyéb körülményből következő) függőség, ami a környezetből "beszivárog". (mondjuk Microsoft Office alkalmazás osztályok használata, mivel a fejlesztő gépén telepítve van az Office).
Például a Ruby a Gem Bundlert adja a Gemfile-ok (függőségi deklarációs jegyzék) létrehozásához, és a bundle exec-et használja a környezet leválasztásához. A Phyton fejlesztők a Pip-et használják a deklarációs jegyzék létrehozásához, és a Virtualenv-et a leválasztáshoz. Még C nyelven is megoldható az Autoconf segítségével a jegyzék gyártása, és statikus linkeléssel pedig a környezet leválasztása. Nem számít, hogy milyen kombinációt alkalmazunk, a függőségek jegyzékbe vétele és a környezet leválasztása mindig együtt kell, hogy jelen legyen az alkalmazásfejlesztés során. Ha csak az egyiket használjuk, nem teljesítjük a 12 tényezős alkalmazásfejlesztés követelményeit.
Az egyik nagy előnye a függőségek megfelelő kezelésének az, hogy ha új fejlesztő csatlakozik, akkor a környezet telepítése egyszerűen a kódbázis letöltését jelenti a gépére, ezen túlmenően csak a programozási nyelvre és a csomagkezelőre van még szükség semmi egyébre. Ezzel a fejlesztő egy egyértelmű build paranccsal tudja az alkalmazást futtatni. Például Visual Stúdióból az első BUILD előtt minden szükséges NuGet csomag automatikusan letöltődik (a nuget.exe restore parancs segítségével). A Ruby fejlesztők a bundle install parancsot, a Clojure fejlesztők pedig a lein deps parancsot használják.
Egyéb, a futtatókörnyezetben létező rendszereszközök használata sem megengedett. Így curl, cmd.exe vagy bash parancsok hívása sem. Bár a legtöbb rendszeren ezek az eszközök léteznek, nincs rá garancia, hogy minden rendszeren léteznek illetve a jövőben mindig létezni fognak, valamint ha léteznek, a verziójuk mindig alkalmas lesz az együttműködésre alkalmazásunkkal. Ha ilyesmit használni szeretnénk, akkor az alkalmazás mellé kell csomagolnunk és alkalmazásunkkal együtt telepítenünk.
