MVN ve PVN texnologiyaları - Mərkəzləşdirilmiş Versiyaya Nəzarət Texnologiyaları ve PaylasdırılmışVersiyaya Nəzarət Texnologiyaları Versiyaya Nəzarət Texnologiyalarının iş dünyasında xüsusilə də proqramlaşdırma sahəsində olduqca geniş yayılmışdır və demək olar ki, hər bir proqramçı öz kariyerasının müxtəlif mərhələsində və ya mütəmadı olaraq hər hansısa bir VNT-dən istifadə edir. VNT-lərin bir çox növləri olsa da onlar ümumi olaraq iki təməl qrupa ayrılır: Mərkəzləşdirilmiş Versiyaya Nəzarət Texnologiyaları və Paylaşdırılmış Versiyaya Nəzarət Texnologiyaları. İnglis dilli ədəbiyyalatlar bu yanaşmalar ardıcıl olaraq "Centralized Version Control Systems" və "Distributed Version Control Systems" adları ilə qeyd edilir [1]. Adlarından da aydın olduğu kimi hər iki texnologiya ümumi olaraq versiyaya nəzarət mexanizminə olan yanaşmalarına görə bir-birilərindən fərqlənir. Mərkəzləşdirilmiş Versiyaya Nəzarət Texnologiyaları (MVNT) Bu yanaşmaya əsasən tək bir mərkəzi kompüterdən və ya serverdən istifadə edilir. Layihənin bütün versiyaları, nüsxələri və faylları sadəcə bu mərkəzi kompüterdə saxlanılır. İstifadəçilər layihə üzərində işlədikləri zaman həmin layhiəyə aid olan müəyyən fayllara və ya bütün layihəyə bütün fayllara xüsusi “pull” əmrindən istifadə edərək çata bilərlər. "Pull2 əmri ümumi olaraq versiya nəzarət texnologiyalarında qəbul edilmiş bir əmrdir ki, bunun da əsas məqsədi yuxarıda qeyd edildiyi kimi istifadəçinin lazımı faylları yükləyə bilməsidir [2]. İstifadə edilən versiya nəzarət texnologiyasından asılı olaraq bu əmrin forması və strukturu fərqli ola bilər, lakin mahiyyət demək olar ki, hər zaman eyni qalır. İstifadəçi fayllar üzərindəki işini bitirdikdən sonra mütləq şəkildə bunların hamısını mərkəzi serverə göndərməlidir. Bu prosesin özü də ümumi olaraq "update" adlanır. Onu da qeyd etmək lazımdir ki, MVNT-lərdə sadəcə layihənin ən son versiyası yadda saxlanılır və məhz buna görə də hər bir istifadəçi mütləq şəkildə öz işini tamamladıqdan sonra etdiyi dəyişiklikləri ümumi serverə göndərməlidir. Mərkəşləşdirilmiş versiya nəzarət texnologiyalarının iki böyük mənfi cəhəti mövcuddur [3]. Bunları aşağıdakı kimi izah etmək olar: 1. Tək mərkəzli yanaşma riski. Adından da aydın olduğu kimi MVNT-lərdəku bütün fayllar tək bir mərkəzi kompüterdə toplanır ki, bu da özlüyündə olduqca ciddi risklər yaradır. Əgər mərkəzi serverdə və ya kompüterdə hər hansısa bir xəta baş verərsə bütün layihə fəaliyyətini dayandırmalı olacaq. Bu da böyük korporativ layihələrdə görülən işlərin bəzən günlərlər təxirə salınması ilə nəticələnə bilər. 2. Aşağı sürət. Daha əvvəl də izah edildiyi kimi hər bir istifadəçi öz işini bitirdikdən sonra mərkəzi serverə “pull”, “update” və ya müxtəlif tipli əmrlər göndərməli olur. Bu əmrlərin proqramlaşdırmanın hər addımında baş verdiyindən böyük komandası olan layihələrdə əlavə problemlər yarada bilər. Bu tip tək bir mərkəzə yönəlmiş əmrlər serverdə yüklənmələr yarada bilər və beləliklə istifadəçi bir əmri verdikdə onun bitməsi üçün bəzən uzun saatlar gözləməli ola bilər. Paylaşdırılmış Versiya Nəzarət Texnologiyaları (PVNT) Paylaşdırılmış versiya nəzarət texnologiyası daha əvvəl izah edilən MVNT-yə alternativ olaarq yaradılmış bir yanaşmadır. Bu texnologiyanın əsas fərqi adından da aydın olduğu kimi tək bir mərkəzi server və ya kompüterdən asılı olmamasıdır. Bu da öz növbəsində o deməkdir ki, hər bir istifadəçi layhiənin bütün faylalrını asandlıqla endirib mərkəzi serverlə əlaqə saxlamağa ehtiyac durmadan sərbəst şəkildə öz işlərini davam etdirə bilər. Bundan əlavə PVNT-də verilən əmrlərin heç bir mərkəzi server və ya kompüterlə əlaqə saxlamağa ehtiyacı olmadığından istifadəçilər əməliyytaları çox daha sürətli və effektiv formada icra edirlər. Mərkəzi serverlə əlaqə saxlamağa ehityac olmasa da istifadə zamanı dəyişiklərin hər kəslə bölüşülə bilməsi üçün MVNT-də olduöu kimi burda da müxtəlif formada olan “pull”, “update” və s tili əmrlərin icrasına ehtiyac duyulur. Bu əmrləri icra edərkən aparılan dəyişikliklər budaqlar adlanan "branch"lardan istifadə edilir. Budaqların mahiyyəti və növləri haqqında növbəti paraqraflarda daha ətraflı məlumat veriləcək [4]. Hər bir texnologiya da olduğu kimi bütün bu üstün cəhətlərinə baxmayaraq MVNT-də də müəyyən məbfi xüsusiyyətlər mövcuddur. Bunların arasında ən önəmlisi yaddaş problemidir. Bir çox hallarda istifadəçilər tam sərbəst işləyə bilmək üçün bütün layihəni öz kompüterlərinə yükləməli olurlar ki, bu da çox böyük layihələrlə işləyərkən əlavə yaddaş problemləri yaradır. Bütün bunlara baxmayaraq bir çox sahədə MVNT daha əlverişli və istifadə uyğun sayıldığından olduqca geniş yayılmışdır. Məhz buna görə də bu sahə ilə bağlı bir çox məşhur platforma və şirkətlər mövcuddur. Bu platformaların hər birinin özünə məxsusu xüsusiyyətləri var. Onları qısaca olaraq aşağıdakı kimi təsvir etmək olar: • GitHub; • Beanstalk; • Helix core; • Gerrit; • Mercurial; GitHub. Yuxarıda adları sadalanan MVNT-lər arasında ən aparıcı rola və bazar böyüklüyünə sahib olan GitHub portalıdır. GitHub-ın əsas xüsusiyyəti açıq qaynaq kodlarının saxlanılması və komanda üzvləri arasında əməkdaşlığın artırılmasıdır. GitHub olduqca məşhurdur və ən son hesablamalara əsasən bazarın təxmini olaraq 85%-i bu platformanın əlindədir [5]. Bu rəqəmin nə qədər böyük olduğunu daha aydın izah etmək üçün onu da qeyd edək ki, hal hazırda GitHub-ın 100 milyondan çox istifadəçisi var və platforma daxilində ümumi olaraq 372 milyondan çox layihə saxlanılır [6]. Beanstalk. Bu platformanın GitHub-dan başlıca fərqi daha çox gizli layihələr üçün istifadə edilməsidir. Burada “gizli” dedikdə qaynaq kodları açıq şəkildə paylaşılmayan və bir çox hallarda da kommersiya əhəmiyyəti daşıyan layihələr nəzərdə tutulur. Məhz buna görə də Beanstalk professional biznes mühitində GitHubla rəqabət apara biləcək və ona alternativ bir platforma kimi görünən ən böyük texnologiyalardan biridir [7]. Helix core. Versiya nəzarət platformaları arasında hələ də MVNT istifadə edən nadir platformalardan biridir. Məhz bu xüsusiyyətinə görə də öz iş strukturunda sırf bu yanaşma istifadə etmək istəyən istifadəçilər arasında olduqca məşhur bir platformadır [8]. Gerrit. Gerrit platformasının ən böyük xüsusiyyətlərindən biri işçilər arasındakı kollaborasiyanı artırmasıdır. Bu xüsusiyyət daha çox proqramşaldırma mühitində daha faydalı olur. Beləki Gerrit daxilində istifadəçilərin bir-birilərinin yazdıqları kodları müqayisə və müzakirə etməsi çox da rahat şəkildə baş tutur. Bu funksiya GitHub platformasında da mövcuddur lakin daha operativ şəkildə istifadə edilə bilməsi üçün mütləq şəkildə əlavə vasitələrdən (köməkçi proqramlardan) istifadə edilməsi məsləhət görülür [9]. Mercurial. Mercurial platformasının ən böyük üstünlüyü onunla işləyə bilmək üçün lazım olan öyrənmə periodunun digər platformalarkından çox daha az olmasıdır. Bunun ən vacib cəhətlərindən biri platformanın olduqca sadə olan istifadəçi sahifəsidir [10]. Budaq strategiyaları. Budaq startegiyası və ya inglis dilli ədəbiyyatda “branching” adlanan bu yanaşmanın əsas mahiyyəti layihənin klonunun yaradılaraq işlərin onun üzərində aparılmasıdır. Proqramçı öz işini bitirdikdən sonra yalnız yeni dəyişikliklərin tam problemsiz bir şəkildə işlədiyinə əmin olduqda öz dəyişikliklərini əsas layihəyə əlavə edir. Bunun sayəsində proqrmalaşdırma zamanı hər hansısa bir xəta yaranarsa əsas qaynaq kodlarına heç bir ziyan gəlmir və proqramçılar sərbəst şəkildə layihə klonunun üzərində çalışmağa davam edirlər [11]. Müxtəlif budaq strategiyalarına keçid etməzdən öncə proqramlaşdırma mühitində daha çox hansı budaq növlərindən istifadə edildiyini müzakirə etmək lazımdır. Ümumi olaraq proqramlaşdırma mühitində 6 növ budaq mövcuddur: • Əsas budaq (“Main branch”); • Buraxılış (“Release”); • Eksperiment (“Experiment”); • Funksionallıq (“Feature”); • Xəta düzəltmə (“Bug fixing”); • Əlavələr (“Contributor”); Əsas budaq. İlkin olaraq Əsas budaq olaraq adalanan budaq növünü izah edək. Bu budaq daha çox layihənin təməl qaynaq kodlarının saxlamaq üçün istifadə edilir. Buraya digər bir bütün budaqların çıxış nöqtəsi kimi də yanaşmaq olar. Demək olar ki, istənilən layihə strukturunda proqramçılar öz işlərini bitirdikdən sonra etdikləri dəyişiklikləri bu təməl budağa əlavə edirlər. Buraxılış. Bu budaq növündə əsasən layhiənin artıq istehsala tam hazır olan versiyası saxlanılır. Burdan da anlaşıldığı kimi bu olduqca əhəmiyyətli bir budaq növüdür və bir çox hallarda layihələrdə sadəcə yüksək vəzifəli idarəçilərin bu budağa giriş icazəsi olur. Eksperiment. Eksperiemnt budaq növü bəzi hallarda “Sandbox” olaraq da adlandırlır. Bu budaq daha çox proqramçıların layihə ilə bağlı öz şəxsi fikir və təkliflərini hazırladıqları bir yerdir. Funksionallıq. Bu budaq proqramlaşdırmada ən geniş yayılmış budaq növlərindən birdiri və ümumi olaraq budaq strategiyasının niyə yarandığının ən gözəl nümunəsidir. Burada layihəyə əlavə edilməsi planlaşdırılan yeni funksionallıqlar hazırlanır və test edilir. Yeni funksionallıq əgər tam qüsursuz bir formada işləyirsə yalnız onda Funksionallıq budağından Əsas budağa əlavə edilir. Xəta düzəltmə. Bu növ də əvvəlki kimi geniş yayılmışdır. Aydın məsələdir ki, layhiə nə qədər diqqət və ehtiyatla hazırlansa da hər zaman xəta baş verə bilər. Məhz bu tip xətalar baş verdikdə onların düzəldilməsi üçün xəta düzəltmə budağı yaradılır. Proqramçı xətanı bu budaqda düzəldib artıq heç bir problem olmadığına tam əmin olduqdan sonra etdiyi yeni dəyişiklikləri əsas budağa daxil edir. Təməl budaq strategiyaları. Bir çox budaq strategiyaları olduğu halda biz ən məşhur olan təməl üç yanaşmadan danışacayıq. Bu strategiyalar Trunk-based, GitHub Flow və GitFlow olaraq adlandırılır. Bu strategiayaları bir-birindən ayıran ən təməl cəhətləri istifadə etdikləri budaq növləri və proqramlaşdırma prosesinə olan yanaşmalardır [12]. Trunk-based. Bu budaq strategiyası digərlərinə nəzərən ən sadəsi hesab olunur. Daha əvvəlki paraqraflarda izah etdiyimiz budaq növlərindən sadəcə biri olan Buraxılış budağı istifadə edilir. Bu da o deməkdir ki, istənilən funksionallıq və xətalar yalnız bu budağın üzərində tətbiq edilə bilər. Bu strategiya ilə işləmək bir çox hallarda olduqca riskli hesab olunduğundan əsasən sərbəst proqramçılar tərəfindən qeyri kommersiyalar layihələrdə istifadə edilir. Əlavə olaraq onu da qeyd edək ki, bəzi hallarda Trunk-based strategiyasında Funksionallıq və ya Xəta düzəltmə budaqları istifadə edilsə də bu sadəcə xüsusi hallarda baş verir. GitHub Flow. Bu budaqlanma strategiyası daha əvvəlkindən nisbəətn daha mürəkkəb xarakterə və sistemə malikdir. Beləki daha əvvəlki strategiyada sadəcə xüsusi hallarda istifadə edilən funksionallıq və xəta düzəltmə budaqları burda mütəmadi olaraq istifadə edilir. Bunlardan əlavə olaraq buraxılış budağı da bu strategiyada geniş şəkildə istifadə edilir. Ümumi iş prinsipinə əsasən proqramçılar öz işlərini funksionallıq və xəta düzəltmə budaqlarının üzərində tamamladırdan sonra dəyişiklikləri əsas budağa yönləndirirlər. Testlər bitdikdən sonra isə dəyişiklər Buraxılış budağından yönləndirilir. GitFlow. GitFlow strategiyası daha əvvəl izah etdiyimiz hər iki strategiyadan çox daha kompleks və qarışıq bir sistemə malikdir. Burda demək olar ki, yuxarıda adları sadalanan bütün budaq növləri aktiv şəkildə istifadə edilir. Aparılan araşdırmalar onu göstərir ki, bu strategiyadan daha çox kommersial xarakterli və profesional layihələrdə istiadə edilir.

İstinadlar

1. https://www.sciencedirect.com/science/article/pii/S1877050918314819

2. https://dl.acm.org/doi/abs/10.1145/2568225.2568322

3. https://ieeexplore.ieee.org/abstract/document/5071408

4. https://runtimerec.com/best-version-control-systems/

5. https://6sense.com/tech/source-code-management/github-market-share

6. https://en.wikipedia.org/wiki/GitHub

7. https://www.trustradius.com/compare-products/beanstalk-vs-github#pricing

8. https://www.softwareadvice.com/project-management/github-profile/vs/helix-core/

9. https://medium.com/compass-true-north/from-gerrit-to-github-cebc463ec01b

10. https://www.geeksforgeeks.org/difference-between-mercurial-and-git/

11. https://www.techrxiv.org/doi/full/10.36227/techrxiv.172565536.64854061

12. https://cames.ippt.gov.pl/index.php/cames/article/view/1372

Tarix : 30 noyabr 2024