A kezelő bináris objektumok letétbe helyezése (angolul bináris repository manager ) egy szoftver eszköz, amelyet a szoftverfejlesztés keretében használt és előállított bináris objektumok (általában fájlok) letöltésének és tárolásának optimalizálására fejlesztettek ki. Központosítja a szervezet szoftverei (szoftverkiadó) által létrehozott és használt összes műtárgy kezelését. Lehetővé teszi a komplexitás problémájának megválaszolását, amely a bináris objektumtípusok sokféleségéből, a teljes munkafolyamatban elfoglalt helyzetükből , valamint a köztük lévő függőségekből fakad .
A bináris objektumtár a szoftverek tárháza a csomagokhoz, a melléktermékekhez és azok metaadatához. Használható a szervezet által előállított bináris fájlok (köztes termékkibocsátások és -építések) tárolására, vagy harmadik féltől származó bináris fájlok (függőségek) tárolására, amelyeket technikai és jogi okokból eltérő módon kell kezelni.
A szoftverfejlesztés bonyolult folyamat lehet, sok fejlesztőt bevonva, esetleg több országban (időzónás kérdés, nyelvi akadály stb.). Ezeknek a fejlesztői csoportoknak ugyanazok a kódtárak vannak , ugyanazokhoz a buildeszközökhöz férnek hozzá, közös bináris erőforrásokat töltenek le és használnak, és ugyanazokat az összetevőket telepítik ugyanazon a szoftveren belül.
A bináris objektumtárház-kezelő azért jött létre, hogy központosítsa azokat a bináris tárgyakat, amelyeknek az alkalmazásokat fel kell építeniük (össze kell állítaniuk), tesztelniük és végrehajtaniuk kell.
A szoftverfejlesztésben a forráskód fájlok kezeléséhez a szervezetek általában a felülvizsgálat vezérlését használják . Ennek a szoftvernek a célja a szoftver forráskódjának központosítása, lehetővé téve, hogy több ember dolgozzon rajta egyszerre, és lehetővé tegye (egyéb funkciók mellett) az egyes fájlokon végrehajtott módosítások előzményeinek megőrzését is. Ehhez a menedzserek integrálnak vagy használnak olyan eszközöket, mint a szövegösszehasonlítók ( diff ).
Ez a sok forrásfájl végül egy vagy több bináris műtárgyba van integrálva (lefordítva vagy sem), és egy szoftvertermék alkotóelemét képezi.
Az összetevők összeállításának és felépítésének eredménye ugyanazokra az elvekre vonatkozik, mint a forrásfájlok (fenntarthatóság, elérhetőség, előzmények stb.). A bináris objektumtárkezelő ezért konvergál a verziókezelők felé, és a bináris objektumok verziókezelőjének tekinthető. Ezáltal leküzdi azt a korlátozást, amely a (szöveges) verziókezelőknek a bináris tartalmak kezelésében van, amelyeket kötelesek tárolni, mivel nem tudják elemezni tartalmukat, és így sok helyet foglalnak el nem adatbázisokban. a tartalom típusa.
Ezenkívül a szoftver használhat külső (egy vagy több harmadik fél által elérhetővé tett) tárgyakat, amelyeket letöltöttek a tárolókból (ingyenes, nyílt forráskódú vagy saját tulajdonúak) és / vagy beszereztek (ingyenesen vagy kereskedelmi forrásokból vásároltak). Így a szoftver több tíz, száz vagy akár több ezer bináris objektumot tartalmazhat, amelyeket kezelni kell a koherens és funkcionális egész hatékony fenntartása érdekében.
A verziókezelőkhöz hasonlóan a bináris objektumtárház-kezelőket is különböző fejlesztői csoportok osztják meg, ezzel biztosítva, hogy mindenki ugyanazokat az erőforrásokat használja.
A bináris objektumtárkezelő abban különbözik a verziókezelőktől, hogy integrálnia kell egy olyan elemkészletet, amely nem a szervezet tulajdona (figyelembe kell venni a jogi korlátokat). Valójában ezért felelős egy olyan történelmi kontextus (környezet) megalkotásáért és fenntartásáért, amelyben a szoftver létrejön, amely szükség esetén újrateremtheti azt, anélkül, hogy a belső és harmadik féltől származó alkatrészek életciklusa miatti változások veszélye fennállna.
A verziókezelőktől eltérően a bináris objektumtárkezelőknek nem célja a műtermékek összes közbenső evolúciójának tárolása, mint a forráskódfájlok verziókezelői. Csak az ilyen formában (metaadatokon keresztül) bélyegzett verziók vannak tárolva és elérhetők.
Általános gyakorlat, hogy van egy adott verzió (vagy akár több is, ha a projekt több verziót párhuzamosan kezel), pillanatképnek vagy éjszakai felépítésnek hívják , amelyen a szervezet dolgozik, és amely valószínűleg gyakran változik. Ezt a verziót általában nem teszik elérhetővé más fejlesztői csapatok számára, és előzményeit sem őrzik, csak a legutóbb létrehozott verzió érhető el, a többit felülírják.
Ha a verzió lefagyasztva van (érvényesítve), akkor egy végleges verziószám jön létre, és a bináris objektumok tárház-kezelője eltárolja az adott műtárgyban létrehozott elemeket, és az egész tovább nem fog fejlődni. A hibajavításokat külön verzióban hajtják végre, amelyet egy másik verziószám azonosít.
A bináris objektumtárkezelő ezért nem kezeli az ág fogalmát, mint a verziókezelők, mivel nem lehet ágakat vagy összehasonlításokat egyesíteni. Mindegyik ág ( verzió a bináris objektumtárház-kezelő értelmében) teljesen független a szoftver többi verziójától, míg a verziókezelő számára az ág tartalma csak a fájlokban végrehajtott módosítások összege az ág létrejött (az ág ezért csak a történelem korábbi elemeivel együtt használható).
A szoftveripar folyamatosan fejlődik. A bináris objektumok kezelői nem jelentenek kivételt a szabály alól, és fokozatosan haladnak az univerzális csomagkezelők felé. Ezeknek a csomagkezelőknek az a célja, hogy egységesítsék a vállalatok hozzáférését és az összes szükséges csomag használatát a fejlesztési folyamat során. Eszközöket nyújtanak a műtárgyak biztonságának és kompatibilitásának elemzéséhez. Az univerzális csomagkezelők központi szerepet töltenek be a szervezetek által kihasznált fejlesztési eszközök (fordító rendszerek, csomagolók, dokumentációs eszközök, kódelemzés, kézbesítés ...) láncában.
Néhány ismert univerzális csomagkezelő:
A szoftverfejlesztés életciklusának részeként a forráskódot rendszeresen bináris objektumokká fordítják a folyamatos integrációs folyamat során .
Ennek a műveletnek a során a kódkezelő rendszer kölcsönhatásban áll a bináris objektumtárház kezelőjével, hogy megszerezze a fordításhoz, a feldolgozáshoz és a végrehajtáshoz, valamint a lerakaton belüli letétbe helyezéshez szükséges függőségeket. A bináris objektumok saját gyártását (publikációról beszélünk). Ez a kommunikáció olyan műtárgyak felhasználásával jár, amelyek lehetővé teszik a szükséges erőforrások azonosítását és a létrehozott bináris objektumok elérhetővé tételét más eszközök vagy szoftverek számára.
Ez a szoros interakció a folyamatos integrációs szerverekkel lehetővé teszi a következő metaadatok tárolását :
A műtárgyak és a csomagok két eredendően különböző dolog.
Az artefaktumok olyan elemek halmazát jelentik (néha egyetlen bejegyzésre redukálva) (általában olyan fájlok, mint a JAR , WAR , EAR , DLL , SO, ZIP ...), amelyek egyike metaadatokat tartalmaz (például a Maven- i POM ), lehetővé téve számukra, hogy egyedileg azonosíthatók (azonosító, csomag, verzió, licenc és mások ...).
Ezzel szemben a csomagok egyetlen archív fájlból állnak, jól definiált formátumban (például NuGet a Microsoft-tól , RPM a Red Hat-tól vagy DEB a Debian-tól ). Ez az archívum tartalmazza a formátum által biztosított összes fájlt (például DLL, PDB stb.).
A műtermékeket általában építések generálják. A csomagok lényegében szoftverkönyvtárak vagy alkalmazások.
A forrásfájlokhoz képest a bináris műtermékek sokkal nagyobbak. Ritkán törlik vagy módosítják őket (kivéve a fejlesztés alatt álló műtermékeket, amelyeket rendszeresen felülírnak a frissítések, és amelyek hivatalosan nem állnak rendelkezésre harmadik felek számára).
A metaadatok bináris műtárgyat írnak le. Maguktól a műtárgyaktól elkülönítve tárolják őket, és különböző felhasználási lehetőségekkel rendelkezhetnek.
Az alábbi táblázat a leggyakoribb metaadattípusokat és azok felhasználását mutatja be.
Típusok | Használ |
---|---|
Elérhető verziók | lehetővé teszi az emelkedő (frissítés) vagy csökkenő (alacsonyabb szintű) frissítést |
Függőségek | meghatározza azokat a tárgyakat, amelyeken a leírt tárgy függ |
Hatásfüggőségek | megadja a műtárgyak listáját a leírt műtárgy függvényében |
Engedély | a leírt tárgy tárgyát képező jogi licenc tartalma (vagy hivatkozása) (például: GPL , CC , Apache ...) |
Dátum és idő összeállítása | lehetővé teszi a mű nyomon követhetőségét |
Dokumentáció | elérhetővé teszi a műtárgy offline dokumentációját |
Jóváhagyási információk | a műtárgy-hitelesítési és jóváhagyási folyamat nyomon követhetőségét jelzi |
Intézkedések | összesíti a kód minőségével, az igények fedezésével, a teszt eredményeivel stb. kapcsolatos információkat |
Felhasználói metaadatok | felsorolja a fejlesztők által nyújtott további információkat (jelentések, műszaki dokumentáció, folyamat stb.) |
Az alábbiakban felsoroljuk a bináris objektumtárház-kezelők által biztosított főbb szolgáltatásokat, amelyeket figyelembe kell venni az ilyen rendszerek átvételekor: