Egy cikk a tool telepítésétől a használatán keresztül az elemzésekig.
Analyzing website performance with the Windows Performance Toolkit
Egy cikk a tool telepítésétől a használatán keresztül az elemzésekig.
Analyzing website performance with the Windows Performance Toolkit
Egy részletes összefoglaló a témában az Akka.NET-hez (az actor model eredeti Java/Scala Akka framework nyílt forráskódú .NET átirata) kereskedelmi támogatást és tréningeket kínáló cégtől.
The Business Case for Actors and Akka.NET
Előző fejezet: 2. Függőségek kezelése
Következő fejezet: 4. Háttérszolgáltatások
Mai bejegyzésünk a 12 tényezős alkalmazásfejlesztés harmadik pontjával foglalkozik.
3. Beállítások, konfigurációkezelés
Az alkalmazás konfigurációja minden, ami valószínüleg változik az egyes telepítések között (tesztelés, éles, fejlesztői környezetek, stb.). Ideértve
Az alkalmazások néha konstansként tartalmaznak beállítási információkat. Ez megsérti a 12 tényezős alkalmazásfejlesztési alapelveket, aminek teljesítéséhez szigorúan szét kell választani a konfigurációs értékeket a forráskódtól. A konfiguráció telepítésenként jelentősen különbözik, a forráskód nem.
Ennek a szigorú szétválasztásnak egy jó lakmusz-próbáját teljesíti az alkalmazásunk, ha a kódbázis bármelyik pillanatban nyílttá tehető anélkül, hogy érzékeny információ kompromittálódna.
Figyelem, a konfigurációnak ez a definíciója nem terjed ki az alkalmazások belső konfigurációjára, mint a Rails esetében a config/routes.rb, vagy a Spring esetében ahogy az egyes modulok kapcsolódnak, mert ezek az információk a különböző telepítések esetében nem különböznek.
A konfiguráció egy másik megközelítése, ha a konfigurációs állományainkat, mint a Railsnél a config/database.yml nem adjuk hozzá, így nem is tároljuk a kódtárunkban. Ez a konstansok használatához képest egy nagy előrelépés, mivel azokat kódtárban tároljuk, azonban továbbra is gyenge pont: nagyon könnyű véletlenül vagy figyelmetlenségből felvenni a kódtárunkba az egyik checkin-nél. És könnyen vezethez ahhoz az állapothoz, amikor a konfigurációs információink szétszórva, különböző helyeken és különböző formátumokban szaporodnak, egyre nehezebben áttekinthetővé téve a beállításokat. Továbbá, ezek a formátumok általában nyelvhez és keretrendszerhez igazodó formát vesznek fel.
A 12 tényezős alkalmazás a konfigurációs információkat környezeti változókban tárolja. Ezeket gyakran rövidítjük angolul az Environment Variables után env vars-nak vagy env-nek. A környezeti változókat (ellentétben a konfigurációs állományokkal) igazán könnyű telepítésenként különböző értékkel beállítani, kevés esélyünk van a kódtárba véletlenül felvenni, és a speciális konfigurációs állományokkal (vagy más konfigurációs módszerrel, mint például a Java System Properties) ellentétben, nyelv és operációs rendszertől független megoldás.
Még egy érdekes nézőpontja a konfigurációkezelésnek, a csoportosítás. Néha az alkalmazások a konfigurációt nevesített csoportokba szervezik (gyakran hívják az ilyet "környezetnek"), az egyes telepítések után elnevezve, mint a development, test vagy a production környezet a Rails-nél. Ez a megoldás nem skálázható tisztán: amikor az alkalmazásból új telepítés készül, az új környezetnek új név kell, mint például: staging, qa. És ahogy a projekt bővül, a fejlesztők saját változókat hoznak létre, mint például tamas-staging, peter-staging, stb, ez kombinatorikus robbanáshoz vezethet, ami nagyon törékennyé teszi az alkalmazás konfigurációinak az egységes kezelését.
A 12 tényezős alkalmazásfejlesztésben a környezeti változók a beállítás egységei, mindegyik teljesen független a többi a többi környezeti változótól. Soha nincsenek "környezetenként" csoportosítva, helyette mindegyiket telepítésenként külkön kezeljük. Ez a megoldás az alkalmazás az élettartama alatt a telepítések számával együtt könnyen skálázható.
Korábban már volt róla szó, Ezzel a NuGet-tel csomagban használhatjuk: Simple, reliable feature toggles in .NET
Az apropót az adja, hogy kijött a 3.4: New FeatureToggle Release: v3.4 With Fluent Syntax