A kibocsátás menedzsment három fő tendenciája, figvam
IT A megbízható kiadáskezelő eszközöket létrehozó vállalatok ma jelentős versenyelőnyt élveznek. Ebben a cikkben a Surinderpal Kumar a kiadáskezelés három legfontosabb tendenciájáról beszél, amelyet bármely informatikai vállalat profitálhat.
A piac fokozott nyomása kapcsán a vállalatok a lehető legjobban megpróbálják termékeiket előállítani a versenytársak előtt. Az ilyen gyakori kiadások lehetővé teszik a csoportoknak, hogy korábban ellenőrizzék a funkcionalitást és könnyebben azonosítsák a hibákat Ezenkívül egy kisebb kibocsátás-ciklus nagyobb rugalmasságot biztosít, lehetővé téve Önnek, hogy indokolatlan költség nélkül indítsa el a nem kívánt változásokat. Ennek eredményeképpen az ilyen kibocsátási rendszerrel rendelkező vállalatok jelentős versenyelőnyt kapnak.
Az ilyen technikák végrehajtásának folyamata azonban sokkal könnyebben leírható szavakkal, mint ténylegesen megvalósítani a vállalatnál, mert minden nap egyre bonyolultabbá és bonyolultabbá válik a szoftverfejlesztés. Legalább azért, mert folyamatosan elavult kód jelenik meg, az erőforrások változnak, a csapatokat a világ minden táján forgalmazzák, és a támogatott platformok száma növekszik. Ebben a cikkben fogok beszélni a három fő trendet, hogy minden informatikai vállalat részesülhet.
Az első tendencia: rugalmas módszerek bevezetése a kernel szintjén, beleértve az automatizálást is. Nem lesz elegendő minden reggel a stand-up ülések tartására. Igen, a sprintek és az iterációk tervezése, valamint a felülvizsgálat és a visszahívás is fontos elemei a sikeres kiadásoknak. Annak érdekében azonban, hogy a sprintekre felszabadított időtartamra jelentős, jelentős történeteket vagy szolgáltatásokat bocsássanak ki, a vállalatok kénytelenek lesznek automatizálni.
Az automatizálás hiánya a fejlesztőcsapat terhelését eredményezi, és emberi tényezőt hoz a környezetbe, ami a csapat sebességét és hatékonyságát is érinti. A helyes automatizálás változatlan megismételhető folyamatot eredményez, csökkentve a hibák számát és a kiadási időt. A rugalmas módszerek - legyen szó akár forgácsról, akár sovány - mindenképpen javasolják az összeszerelés automatizálását, a tesztautomatizálást, a szállítási / kézbesítési automatizálást és a visszacsatolás / visszacsatolás automatizálását. Különösen fontos, hogy az automatizálás felszabadítsa a fejlesztői csoportokat a felesleges kézi konfigurációtól, lehetővé téve számukra, hogy a kódra és a termékfejlesztésre összpontosítsanak.
Például, amint a fejlesztő változtatásokat hajt végre a verziókezelő rendszerben, a változások automatikusan integrálódnak a többi modulhoz. Ezután a már összeszerelt alkalmazás automatikusan bekerül a tesztkörnyezetbe. Az összeszerelt modulokat ezután automatikusan a tesztkörnyezetbe helyezi. Ha változások történtek a platformon vagy a környezetben, akkor ezek a változtatások automatikusan megtörténnek, és átkerülnek a tesztplatformra. A következő lépés automatikusan ellenőrzi az ilyen egység alkalmazhatóságát, amely magában foglalja a teljesítmény, a megbízhatóság és a kapacitás tesztjeit is. A fejlesztők és / vagy a vezetők csak hiba esetén értesítést kapnak. Azonban a fő hangsúly a rendszermag fejlesztésén, és nem csak a további szükségtelen tevékenységeken múlik. Természetesen némi kézi csekk mindenképpen megmarad, a kiadáskezelő csapatnak a következő lépések végrehajtása végett kell elvégeznie, de a de-file folyamat folyamatában szinte minden tevékenység többé-kevésbé automatizált.
Ahogy keresztül QA tesztek, az eredeti kiadás a termék automatikusan átkerül a felszabadulást adattár, amely az új verzió lehet eltűnni automatikusan más rendszerek, vagy letölthetők az ügyfelek. Számos technológia áll rendelkezésre a piacon minden ilyen szakaszok, beleértve az automatizálás épít (például Ant, Maven, Make), folyamatos integráció (Jenkins, Sebességtartó Automatika, bambusz), tesztelés automatizálása (Silk Test, padlizsán, Test Complete, Kódolt UI ) és egy folyamatos demó (Bambusz, Prism, Jenkins). A bevált gyakorlatok bevezetése általában stratégiai tervezést és időbefektetést igényel a projekt korai szakaszában. Ez azonban csökkenti a szervezeti költségeket és a változások végrehajtásának költségeit a későbbi szakaszokban.
A második tendencia a virtualizáció és a felhőplatformok használata mint fejlesztési és tesztkörnyezet. Ma a legtöbb szoftver több platformot támogat, legyen az operációs rendszerek, alkalmazáskiszolgálók, adatbázisok vagy internetes böngészők. A fejlesztő csapatoknak mindegyik környezetben meg kell vizsgálniuk termékeiket, mielőtt a piacra bocsátják őket.
Azonban nehéz mindezen környezetek létrehozását, valamint támogatást nyújtani. Ezek a nehézségek növelik a komplexitást, különösen, mivel a fejlesztési és tesztelési csoportok egyre inkább földrajzi eloszlásúak. Ilyen körülmények között a virtualizációs és felhőplatformok használata nagyon kényelmes lehet, és az ilyen informatikai platformokat a közelmúltban széles körben alkalmazták az informatikai iparágban.
Egyes vállalatoknál a felszabadítási menedzseri csapatok elindítják a deautomatizálást virtuális és felhő platformokra. Ebben az esetben, csakúgy, ahogy támogatjuk a kódváltozások és az alkalmazáskonfiguráció történetét, támogatjuk az összes támogatott platform változatát.
Például korábban leírtuk a kód ellenőrzési folyamatát a fejlesztő által, és automatikusan elindítottuk a szükséges tesztkörnyezetek felépítését és hibakeresését. Hasonlóképpen, ha a kibocsátás vagy a beépítés mérnökei megváltoztatják a célplatform (OS, adatbázis vagy alkalmazáskiszolgáló beállítások) konfigurációját - az egész platform teljes mértékben elképzelhető, és a rendszer képét létrehozza és felhasználja a megfelelő platformon. Más szóval, ha VMWare virtualizációt használ, a virtuális gép automatikusan kibontakozik a mögöttes operációs rendszer képéről, a megfelelő konfigurációkat lefektetik, és a többi platform és alkalmazás összetevője automatikusan létrejön.
Ugyanez vonatkozik a felhő környezetre (mind az IaaS, mind a PaaS). Amint új konfigurációk jelennek meg, egy új példányt emelnek ki, fejlesztési környezetként és tesztkörnyezetként. Ez kritikus a teljesítmény szempontjából, ellenkező esetben hetekig tarthat a konfigurációs változásokhoz való alkalmazkodás. Az automatizálással a folyamat gyorsan megismételhetővé válik, és nincsenek buktatók a különböző fejlesztőcsapatok közötti kommunikációban.
A harmadik tendencia az elosztott verziókezelő rendszerek használata. Hasonló rendszerek, mint a git, a higany, a perforce - egyre inkább népszerűvé válnak, mivel a rugalmasságot a csapatok kölcsönhatásba hozzák a kód szinten. Az ilyen rendszerek alapvető alapja az, hogy minden felhasználó megőrzi a tároló egy változatát a számítógép teljes történetében. Nincs szükség különálló mesterkészletre, de a legtöbb csapat a legjobb gyakorlatot használja. Az elosztott rendszerek lehetővé teszik a programozók offline működését és helyben végzik el a változásokat.
Miután a fejlesztők befejezték a részüket, a változásokat a központi raktárba RC-be fogják tenni. A DVCS alapvetően új interakciós megközelítést biztosít, így minden fejlesztő gyakran küldheti meg változásait, anélkül, hogy befolyásolná a mögöttes kódbázist vagy csomagtartót. Ez nagyon hasznos, ha a csapatok új ötleteket vagy kísérleteket fedeznek fel.
A DVCS felhasználóbarát lesz a fejlesztői csapatok számára, amelyek rugalmas szolgáltatás-alapú ágazati stratégiát alkalmaznak. Ez arra ösztönzi a fejlesztőket, hogy folytassák munkájukat az ágakon (jellemzők) a készenléti állapotig, hogy a változásokat helyileg teszteljék, majd töltsék be őket a kiadási láncba. Ebben a rendszerben a fejlesztők együttműködhetnek egymással a készlet helyi példányában.
Csak a szabványos felülvizsgálatok és a minőségbiztosítási tesztek után - a fő adattáron változtatnak. Ha a szoftver fejlesztése több projektcsapatot, elosztott csapatot vagy fejlesztésen alapuló fejlesztést tartalmaz, a DVCS-t figyelembe kell venni.
A kibocsátás menedzsment e három fő irányzatának bevezetése nagyon jó tartalékot teremt a jövő számára bármely informatikai vállalat számára.