A szoftveres verziókezelő rendszer

A fájlok biztonsági másolatának készítése alapvetően az a folyamat, amely során a szóban forgó fájlok olyan helyre kerülnek, ahol (legalább egy bizonyos szinten) védelmet élveznek a véletlen adatvesztés ellen. Mivel a 21. században szinte mindenki, mindenhol fájlokkal dolgozik, ez kiváltképp fontos folyamat.

Az okostelefonok és a modern asztali operációs rendszerek nagyon jól automatizálják ezt, és leveszik a felhasználó válláról a teher nagy részét.
Egy egyszerű példa a fentebbi mondatra: hogyan menti le az okostelefon a kapcsolatlistánkat? Manapság szinte senki sem tárolja a kapcsolatai telefonszámait, e-mail címeit kizárólag a mobilján, hanem például a Google, vagy Apple Contacts használatával gondoskodik erről. A szolgáltató ezen információkat a szerverein tárolja (Az adataink tárolásával kapcsolatosan felmerülő etikai és morális kételyek egy másik vita tárgyát képezik), így ha elveszíti vagy megrongálódik a mobiltelefon, akkor a névjegyzékünk továbbra is érintetlen marad a szerveren, és új készülékén egy alkalmazás visszaszinkronizálja azt.

Rendben, de mi a helyzet azokkal a fájlokkal, amelyeken naponta dolgozunk, például Excel-táblázatok, Word-dokumentumok a számítógépünkön?

Valójában nagyon jó esély van arra, hogy ezek a fájlok egyáltalán nincsenek mentve. Csak hogy bebizonyítsam ezt, feltételezem, hogy mindannyiunkkal előfordult már az a bizonyos "A fenébe!" pillanat, amikor véletlenül töröltünk egy fontos dokumentumot, és nem lehetett visszaállítani. Néha csak újra létre kell ezt hozni, de vannak olyan esetek, amikor a fájl elvesztése súlyos következményekkel járhat: ha valaki üzletkritikus adatokat töröl, akkor a fájl újrateremtése talán lehetetlen, és még ha lehetséges is, az nagy erőfeszítést igényelhet. A fontos adatok elvesztése biztosan pénzbe kerül, de egyéb, akár súlyosabb következményei is lehetnek (például az ügyfelek bizalmának elvesztése, peres eljárások stb.)

Az adatvesztés kockázatának minimalizálása érdekében a fájlok biztonsági másolatának készítése kritikus fontosságú.

30 éves tapasztalatom alapján az emberek és a számítógépekkel foglalkozók körében általában három közös kategóriája van a biztonsági mentések készítésének módjában:

1. • Az első típus egyáltalán nem készít biztonsági mentéseket. Vannak emberek, akiknek tényleg nincs szükségük biztonsági mentésre, és számukra csak terhet jelentene. Azonban azt tapasztaltam, hogy a biztonsági mentést NEM készítő emberek viszonylag magas százaléka valójában rászorulna erre, csak lusta vagy nem tudja, hogyan kell megtenni.
2. • A második típus az, aki helyi biztonsági mentéseket készít. Ez már nagy előrelépés az első típushoz képest. Ezek az emberek rendszeresen (ez relatív) másolják a fájljaikat valahová a helyi merevlemezükön. Ha több fájlal dolgoznak, akkor általában egyszerre mindegyiket másolják és tömörítik. Bár ennek a folyamatnak számos hátulütője lehet, és nem tekinthető biztonságosnak (mi van, ha véletlenül törli a biztonsági mentési mappát?), az a véleményem, hogy ez végtelenül jobb, mint a nincs biztonsági mentés hozzáállás.
3. • A harmadik típus hasonló a másodikhoz, de a biztonsági mentéseket felhőbe vagy hálózati meghajtóra menti. Ha jól csinálják, ez a módszer tovább növeli a biztonságot a biztonsági mentések helyi PC-n kívüli tárolása révén. Fontos, hogy helyesen csináljuk: olyan helyre a legjobb menteni, ahol csak Ön vagy nagyon kevés ember férhet hozzá, ellenkező esetben az adatainak biztonságának csökken, hiszen mások módosíthatják vagy törölhetik a fájljait.

A szoftverfejlesztők - mint mi, az Omega Byte - sokkal nagyobb méretű biztonsági mentési problémával szembesülnek.

Egy tipikus projekt során nem csak egy-két, vagy talán tucatnyi fájlról beszélünk, hanem legalább ezrekről, így nem lehet csak egyszerűen összenyomni az összes fájlt, mert az túl gyorsan megtölti a merevlemezt vagy a hálózati tárolót. Ráadásul a fejlesztés során a projekt fájljai gyorsan változnak.

Ideális esetben minden új funkció fejlesztésekor, hiba javításakor vagy valami átnevezésekor biztonsági másolatot kellene készítenünk, függetlenül attól, milyen nagy volt a változtatás. Ha ezt nem tesszük meg, akkor amikor végre elhatározzuk magunkat egy biztonsági mentés elkészítésére, akkor több változtatást is biztonsági mentünk egyszerre. Ez sosem jó szokás, mert ha véletlenül hibát vétettünk korábban, akkor vagy vissza kell vonnunk az összes változtatást (beleértve a jó változtatásokat is), vagy meg kell oldanunk az új hibát, ahelyett hogy csak visszatérnénk az előző állapotba, amely nem tartalmazta azt. A következő tényező az, hogy egy projekt írása szinte sosem egy ember munkája. Több fejlesztőnek kell dolgoznia ugyanazon fájlkészleten anélkül, hogy befolyásolnák egymást.

Ez nem lehetséges a hagyományos biztonsági mentési módszerekkel.

Szerencsére ezt a problémát már az 1980-as évek elején felismerték, és megoldások születtek (némelyik sikeresebb, mint a másik) a Software Version Control (SVC) összefoglaló neve alatt. Az SVC nagyon fontos, erősen hiszem, hogy egyetlen szoftverfejlesztő csapat sem lehet sikeres enélkül. Ráadásul az SVC folyamat használata fontosabb lehet, mint maga a programozási nyelv, mivel a legtöbb probléma megoldható sok programozási nyelven, de ha az SVC-t nem használjuk, az nagyban növeli a rossz kódminőség, a késedelmes szállítás és a projekt kudarcának esélyét. Mielőtt elmagyaráznánk az elméletet, érdemes megjegyezni, hogy egyik műveletet sem kell manuálisan elvégezni az alábbiak közül, alkalmazások lettek kifejlesztve, hogy ezt helyettünk megtegyék. Emellett bár egy SVC képes lehetővé tenni a biztonsági mentések tárolását helyi PC-n, ez nem jellemző, a legtöbb esetben a mentéseket a felhőben tároljuk.

Az SVC használata a következőképpen történik:

1. A fejlesztő letölti a projektet a szerverről (ezt "checkout"-nak nevezzük)
2. Módosít néhány fájlt.
3. Készít egy pillanatképet a változásokról (ezt "commit"-nak nevezzük)
4. Feltölti a commitot a szerverre (ezt "push"-nak nevezzük)

Az SVC itt ragyog: amint elkészült a változtatás, az SVC nem biztonsági menti az egész projektet, csak a valóban megváltozott fájlokat. Képzelje el, hogy dolgozik egy olyan projekten, amelynek 1000 fájlja van, és javítania kell egy elírást egy párbeszédablakban. Az SVC használatával nem kell mind az 1000 fájlt feltöltenie a szerverre, elég csak az egyet megváltoztatni.

Minden commit mellé rövid leírást (ezt "message"-nek nevezzük) lehet csatolni, amely összefoglalja a változást. A legtöbb esetben, amikor egy commit listáját nézzük, nem érdekelnek minket az egyes fájlokban történt változások, csak egy gyors mondatot szeretnénk látni arról, hogy mi változott, hogy megértsük, miért hozták létre ezt a commitot.

Amint feltöltötte a commitot a szerverre, a commit védve van a véletlen adatvesztéstől, mivel amint egy commit létrejön, azt nem lehet módosítani vagy törölni. Bármikor visszatérhet bármelyik commit-hez, így helyreállíthatja a projekt korábbi állapotát, ha szükséges.

A csapatmunka javára: az SVC lehetővé teszi a fejlesztők együttműködését. Mivel a commitok a szerveren vannak tárolva, semmi sem akadályozza meg a fejlesztőket abban, hogy ugyanazt a commitot lehúzzák a PC-jükre és egyszerre dolgozzanak a projekten (ezt hívják: "branchelés"-nek). Mindenki dolgozhat különböző változtatásokon és feltöltheti a változtatásait a szerverre.

Az egyszerre létrehozott változtatásokat később össze lehet vonni / mergelni.

Röviden összefoglalva:

A fájlok biztonsági mentése szinte mindenki számára fontos. Az SVC egy kifinomult biztonsági mentési folyamat, amelyet bárki használhat, de a szoftverfejlesztők számára kötelező. Az Omega Byte-nál az SVC-hez a GIT-et használjuk, amely a szakemberek 96%-ának választása. (https://survey.stackoverflow.co/2022/#section-version-control-version-control-systems). Ez a cikk egy magas szintű leírása az SVC folyamatnak, így a fogalmak eléggé általánosak. Egy részletesebb technikai dokumentum következik a jövőben.

Bátran vegye fel velünk a kapcsolatot, ha kérdése van erről a témáról.