8-mavzu. Konfiguratsiyani boshqarish

Download 4,12 Mb.
Sana	19.05.2024
Hajmi	4,12 Mb.
	#244010

Bog'liq
8-mavzu. Konfiguratsiyani boshqarish

8-mavzu. Konfiguratsiyani boshqarish
25.1 Versiya boshqaruvi
25.2 Tizimni qurish
25.3 O'zgarishlarni boshqarish
25.4 Relizlarni boshqarish
Dasturiy ta'minot tizimlari ishlab chiqish va foydalanish jarayonida doimo o'zgarib turadi. Xatolar aniqlangan va ularni tuzatish kerak. Tizim talablari o'zgaradi va siz ushbu o'zgarishlarni tizimning yangi versiyasida amalga oshirishingiz kerak. Uskuna va tizim platformalarining yangi versiyalari chiqarildi va siz tizimlaringizni ular bilan ishlashga moslashingiz kerak. Raqobatchilar o'z tizimida siz mos keladigan yangi xususiyatlarni taqdim etadilar. Dasturiy ta'minotga o'zgartirishlar kiritilganda, tizimning yangi versiyasi yaratiladi. Shuning uchun ko'pgina tizimlarni har biriga texnik xizmat ko'rsatish va boshqarish kerak bo'lgan versiyalar to'plami sifatida qarash mumkin.
Konfiguratsiyani boshqarish (CM) o'zgaruvchan dasturiy ta'minot tizimlarini boshqarish uchun siyosatlar, jarayonlar va vositalar bilan bog'liq (Aiello and Sachs 2011). Rivojlanayotgan tizimlarni boshqarishingiz kerak, chunki har bir tizim versiyasiga qanday o'zgarishlar va komponentlar versiyalari kiritilganligini kuzatishni yo'qotish oson. Versiyalar o'zgartirish, nosozliklarni tuzatish va turli apparat va operatsion tizimlar uchun moslashtirish bo'yicha takliflarni amalga oshiradi. Bir nechta versiyalar ishlab chiqilayotgan va bir vaqtning o'zida ishlatilayotgan bo'lishi mumkin. Agar sizda samarali konfiguratsiyani boshqarish tartib-qoidalari mavjud bo'lmasa, siz tizimning noto'g'ri versiyasini o'zgartirish, tizimning noto'g'ri versiyasini mijozlarga etkazish yoki tizimning ma'lum bir versiyasi uchun dasturiy ta'minot manba kodini qaerdan unutib qo'yish uchun kuch sarflashingiz mumkin. komponent saqlanadi.
Konfiguratsiyani boshqarish individual loyihalar uchun foydalidir, chunki bir kishi qanday o'zgarishlar kiritilganligini unutishi oson. Bu dasturiy ta'minot tizimida bir vaqtning o'zida bir nechta ishlab chiquvchilar ishlayotgan jamoaviy loyihalar uchun juda muhimdir. Ba'zida bu ishlab chiquvchilarning barchasi bir joyda ishlaydi, lekin tobora ko'proq rivojlanish guruhlari butun dunyo bo'ylab turli joylarda a'zolar bilan taqsimlanadi. Konfiguratsiyani boshqarish tizimi jamoa a'zolariga ishlab chiqilayotgan tizimga kirishni ta'minlaydi va ular kodga kiritadigan o'zgarishlarni boshqaradi.

Dasturiy ta'minot tizimi mahsulotining konfiguratsiyasini boshqarish bir-biri bilan chambarchas bog'liq bo'lgan to'rtta faoliyatni o'z ichiga oladi (25.1-rasm):
1. Versiyani boshqarish Bu tizim komponentlarining bir nechta versiyalarini kuzatib borish va turli ishlab chiquvchilar tomonidan komponentlarga kiritilgan o'zgarishlar bir-biriga xalaqit bermasligini ta'minlashni o'z ichiga oladi.
2. Tizimni qurish Bu dastur komponentlari, ma'lumotlar va kutubxonalarni yig'ish, keyin ularni kompilyatsiya qilish va bajariladigan tizimni yaratish uchun bog'lash jarayonidir.
3. O'zgarishlarni boshqarish Bu mijozlar va ishlab chiquvchilar tomonidan yetkazib berilgan dasturiy ta'minotga o'zgartirishlar bo'yicha so'rovlarni kuzatib borish, ushbu o'zgarishlarni amalga oshirish xarajatlari va ta'sirini ishlab chiqish va o'zgarishlarni qachon va qachon amalga oshirish kerakligini hal qilishni o'z ichiga oladi.
4. Relizlarni boshqarish Bu dasturiy ta'minotni tashqi nashrga tayyorlash va mijozlar foydalanishi uchun chiqarilgan tizim versiyalarini kuzatishni o'z ichiga oladi.
Boshqarish kerak bo'lgan katta hajmdagi ma'lumotlar va konfiguratsiya elementlari o'rtasidagi munosabatlar tufayli, asboblarni qo'llab-quvvatlash konfiguratsiyani boshqarish uchun juda muhimdir. Konfiguratsiyani boshqarish vositalari tizim komponentlarining versiyalarini saqlash, ushbu komponentlardan tizimlarni yaratish, tizim versiyasi mijozlarining relizlarini kuzatish va o'zgartirish takliflarini kuzatish uchun ishlatiladi. CM asboblari bitta konfiguratsiyani boshqarish vazifasini qo'llab-quvvatlaydigan oddiy vositalardan, masalan, xatolarni kuzatishdan tortib, barcha konfiguratsiyani boshqarish faoliyatini qo'llab-quvvatlaydigan integratsiyalashgan muhitlargacha.
Komponentlar va tizimlar kuniga bir necha marta almashtiriladigan tezkor rivojlanish CM vositalaridan foydalanmasdan mumkin emas. Komponentlarning aniq versiyalari umumiy loyiha omborida saqlanadi va ishlab chiquvchilar ularni o'zlarining ish joylariga nusxalashadi. Ular kodga o'zgartirishlar kiritadilar va keyin sinov uchun o'zlarining kompyuterlarida yangi tizim yaratish uchun tizim qurish vositalaridan foydalanadilar. Ular kiritilgan o'zgarishlardan mamnun bo'lgach, ular o'zgartirilgan komponentlarni loyiha omboriga qaytaradilar. Bu o'zgartirilgan komponentlarni boshqa jamoa a'zolariga taqdim etadi.
Dasturiy ta'minot mahsuloti yoki maxsus dasturiy ta'minot tizimini ishlab chiqish uchta alohida bosqichda amalga oshiriladi:
1. Dasturiy ta'minot konfiguratsiyasini boshqarish uchun ishlab chiqish guruhi mas'ul bo'lgan ishlab chiqish bosqichi va dasturiy ta'minotga yangi funksiyalar qo'shiladi. Rivojlanish guruhi tizimga kiritiladigan o'zgarishlar to'g'risida qaror qabul qiladi.
2. Tizimning versiyasi sinov uchun ichki ravishda chiqariladigan tizimni sinovdan o'tkazish bosqichi. Bu sifat menejmenti guruhi yoki ishlab chiqish guruhidagi shaxs yoki guruhning mas'uliyati bo'lishi mumkin. Ushbu bosqichda tizimga hech qanday yangi funksiya qo'shilmaydi. Ushbu bosqichda qilingan o'zgarishlar xatolarni tuzatish, ishlashni yaxshilash va xavfsizlik zaifliklarini tuzatishdir. Ushbu bosqichda beta testerlar sifatida mijozlar ishtirok etishi mumkin.
3. Dasturiy ta'minot mijozlarga foydalanish uchun chiqariladigan chiqarish bosqichi. Chiqarish tarqatilgandan so'ng, mijozlar xato hisobotlarini yuborishlari va o'zgartirish so'rovlarini yuborishlari mumkin. Chiqarilgan tizimning yangi versiyalari xatolar va zaifliklarni tuzatish va mijozlar tomonidan taklif qilingan yangi xususiyatlarni o'z ichiga olish uchun ishlab chiqilishi mumkin.

25.2-rasm Multiversiyali tizimni ishlab chiqish
Katta tizimlar uchun hech qachon tizimning faqat bitta "ishchi" versiyasi mavjud emas; rivojlanishning turli bosqichlarida tizimning har doim bir nechta versiyalari mavjud. Turli xil tizim versiyalarini ishlab chiqishda bir nechta jamoalar ishtirok etishi mumkin. 25.2-rasmda tizimning uchta versiyasi ishlab chiqilayotgan holatlar ko'rsatilgan:
1. Tizimning 1.5-versiyasi xatoliklarni tuzatish va tizimning birinchi versiyasi ish faoliyatini yaxshilash uchun ishlab chiqilgan. Bu tizimning ikkinchi versiyasining asosi (R1.1).
2. 2.4 versiyasi tizimning 2.0 versiyasiga aylanishi uchun sinovdan o'tkazilmoqda. Ushbu bosqichda hech qanday yangi xususiyatlar qo'shilmaydi.
3. 3-versiya mijozlar va ishlab chiqish guruhining o‘zgartirish so‘rovlariga javoban yangi funksiyalar qo‘shiladigan ishlab chiqish tizimidir. Bu oxir-oqibat 3.0 versiyasi sifatida chiqariladi.
Ushbu turli xil versiyalarda ko'plab umumiy komponentlar, shuningdek, ushbu tizim versiyasiga xos bo'lgan komponentlar yoki komponent versiyalari mavjud. CM tizimi har bir versiyaning bir qismi bo'lgan komponentlarni kuzatib boradi va tizimni yaratishda talab qilinganda ularni o'z ichiga oladi.
Katta dasturiy ta'minot loyihalarida konfiguratsiyani boshqarish ba'zan dasturiy ta'minot sifatini boshqarishning bir qismidir (24-bobda yoritilgan). Sifat menejeri sifatni boshqarish va konfiguratsiyani boshqarish uchun javobgardir. Dasturiy ta'minotning relizdan oldingi versiyasi tayyor bo'lgach, ishlab chiqish guruhi uni sifat menejmenti guruhiga topshiradi. QM jamoasi tizim sifatining maqbulligini tekshiradi. Agar shunday bo'lsa, u boshqariladigan tizimga aylanadi, ya'ni tizimga kiritilgan barcha o'zgarishlar ular amalga oshirilishidan oldin kelishib olinishi va qayd etilishi kerak.
Konfiguratsiyani boshqarishda ko'plab maxsus atamalar qo'llaniladi. Afsuski, bular standartlashtirilmagan. Harbiy dasturiy ta'minot tizimlari dasturiy ta'minot CM ishlatilgan birinchi tizimlar edi, shuning uchun bu tizimlar uchun terminologiya apparat konfiguratsiyasini boshqarishda ishlatiladigan jarayonlar va terminologiyani aks ettirdi. Tijorat tizimlarini ishlab chiquvchilar harbiy protseduralar yoki terminologiya haqida bilishmagan va shuning uchun ko'pincha o'z atamalarini ixtiro qilganlar. Agile usullari, shuningdek, tezkor yondashuvni an'anaviy CM usullaridan farqlash uchun yangi terminologiyani ishlab chiqdi.

Muddati	Tushuntirish
Asosiy	Tizimni tashkil etuvchi komponentlar versiyalari to'plami. Asosiy chiziqlar boshqariladi, ya'ni komponent versiyalarida foydalaniladi asosiy chiziqni o'zgartirib bo'lmaydi. Har doim asosiy chiziqni qayta yaratish mumkin uning tarkibiy qismlaridan.
Tarmoqlanish	kod chizig'idagi versiyadan yangi kod chizig'ini yaratish . Keyin yangi kod chizig'i va mavjud kod chizig'i rivojlanishi mumkin mustaqil ravishda.
Codeline	Dasturiy ta'minot komponentining versiyalari va ushbu komponent bog'liq bo'lgan boshqa konfiguratsiya elementlari to'plami.
Konfiguratsiyani (versiyani) boshqarish	Tizimlar va komponentlarning versiyalari qayd etilishi va saqlanishini ta'minlash jarayoni, o'zgarishlar boshqarilishi va komponentlarning barcha versiyalari tizimning ishlash muddati davomida aniqlanishi va saqlanishi.
Konfiguratsiya elementi yoki dasturiy ta'minot konfiguratsiyasi elementi (SCI)	Dasturiy ta'minot loyihasi bilan bog'liq har qanday narsa (dizayn, kod, test ma'lumotlari, hujjat va boshqalar) konfiguratsiya nazorati ostida joylashtirilgan. Konfiguratsiya elementlari har doim noyob identifikatorga ega.
Magistral	Tizimning turli versiyalarini ifodalovchi asosiy chiziqlar ketma-ketligi.
Birlashish	kod chiziqlaridagi alohida versiyalarni birlashtirish orqali dasturiy ta'minot komponentining yangi versiyasini yaratish . Ushbu kod chiziqlari tegishli kod qatorlaridan birining oldingi bo'limi tomonidan yaratilgan bo'lishi mumkin .
Chiqarish	Tizimning mijozlarga (yoki tashkilotdagi boshqa foydalanuvchilarga) foydalanish uchun chiqarilgan versiyasi.
Repozitariy	Dasturiy ta'minot komponentlari versiyalarining umumiy ma'lumotlar bazasi va ushbu komponentlarga kiritilgan o'zgarishlar haqidagi meta-ma'lumotlar.
Tizim qurish	Tizimni tashkil etuvchi komponentlar va kutubxonalarning tegishli versiyalarini kompilyatsiya qilish va bog'lash orqali bajariladigan tizim versiyasini yaratish.
Versiya	Ushbu elementning boshqa nusxalaridan qaysidir ma'noda farq qiluvchi konfiguratsiya elementining namunasi. Versiyalar har doim noyob identifikatorga ega bo'lishi kerak.
Ish maydoni	Ushbu dasturiy ta'minotdan foydalanayotgan yoki o'zgartirayotgan boshqa ishlab chiquvchilarga ta'sir qilmasdan dasturiy ta'minotni o'zgartirish mumkin bo'lgan shaxsiy ish maydoni.

Shakl 25.3 CM terminologiyasi
Konfiguratsiyani boshqarish standartlarini ta'riflash va ulardan foydalanish ISO 9000 va SEI qobiliyatining etuklik modelida sifat sertifikati uchun juda muhim (Bamford va Deibler 2003; Chrissis , Konrad, and Shrum 2011). Kompaniyadagi CM standartlari IEEE 828-2012, konfiguratsiyani boshqarish uchun IEEE standarti kabi umumiy standartlarga asoslanishi mumkin. Ushbu standartlar CM jarayonlari va CM jarayonida ishlab chiqarilgan hujjatlarga qaratilgan (IEEE 2012). Boshlang'ich nuqta sifatida tashqi standartlardan foydalangan holda, kompaniyalar o'zlarining ehtiyojlariga moslashtirilgan batafsilroq, kompaniyaga xos standartlarni ishlab chiqishlari mumkin. Biroq, tezkor usullar hujjatlar bilan bog'liq qo'shimcha xarajatlar tufayli kamdan-kam hollarda ushbu standartlardan foydalanadi.
8.1. Versiya boshqaruvi
Versiyalarni boshqarish - bu dasturiy ta'minot komponentlarining turli versiyalarini va ushbu komponentlar qo'llaniladigan tizimlarni kuzatib borish jarayoni. Shuningdek, u turli ishlab chiquvchilar tomonidan ushbu versiyalarga kiritilgan o'zgarishlar bir-biriga xalaqit bermasligini ta'minlashni o'z ichiga oladi. Boshqacha qilib aytadigan bo'lsak, versiyalarni boshqarish - bu kodlar va asosiy ko'rsatkichlarni boshqarish jarayoni.
25.4-rasmda kodli chiziq va asosiy chiziqlar o'rtasidagi farqlar ko'rsatilgan . Kod chizig'i - bu dastlabki versiyalardan olingan ketma-ketlikda keyingi versiyalar bilan dastlabki kod versiyalarining ketma-ketligi. Kodekslar odatda tizim komponentlariga qo'llaniladi, shuning uchun har bir komponentning turli xil versiyalari mavjud. Asosiy chiziq - bu muayyan tizimning ta'rifi. Asosiy chiziq tizimga kiritilgan komponent versiyalarini belgilaydi va foydalanilgan kutubxonalar, konfiguratsiya fayllari va boshqa tizim ma'lumotlarini aniqlaydi. 25.4-rasmda siz turli xil asosiy chiziqlar har bir kod chizig'idagi komponentlarning turli xil versiyalarini ishlatishini ko'rishingiz mumkin . Diagrammada men asosiy ta'rifdagi komponentlarni ifodalovchi qutilarni soya qildim, bular aslida kod chizig'idagi komponentlarga havolalar ekanligini ko'rsatish uchun . Asosiy chiziq - bu asl bazadan ishlab chiqilgan tizim versiyalarining ketma-ketligi.

Asosiy chiziqlar tizimning ma'lum bir versiyasiga qanday komponentlar kiritilishi kerakligini aniqlaydigan konfiguratsiya tili yordamida belgilanishi mumkin. Komponentning individual versiyasini (X.1.2, aytaylik) yoki oddiygina komponent identifikatorini (X) aniq belgilash mumkin. Agar siz konfiguratsiya tavsifiga oddiygina komponent identifikatorini qo'shsangiz, komponentning eng so'nggi versiyasidan foydalanish kerak.
Asosiy belgilar muhim, chunki siz tez-tez tizimning individual versiyasini qayta yaratishingiz kerak bo'ladi. Misol uchun, har bir tizim mijozi uchun maxsus tizim versiyalari mavjud bo'lishi uchun mahsulot liniyasi yaratilishi mumkin. Agar mijoz o'z tizimidagi tuzatilishi kerak bo'lgan xatolar haqida xabar bersa, unga yetkazib berilgan versiyani qayta yaratishingiz kerak bo'lishi mumkin.
Versiyalarni boshqarish (VC) tizimlari komponentlarning turli versiyalariga kirishni aniqlaydi, saqlaydi va nazorat qiladi. Zamonaviy versiyani boshqarish tizimining ikki turi mavjud:
1. Markazlashtirilgan tizimlar, bunda yagona asosiy ombor ishlab chiqilayotgan dasturiy ta'minot komponentlarining barcha versiyalarini saqlaydi. Subversion (Pilato, Collins- Sussman va Fitzpatrick 2008) markazlashtirilgan VC tizimining keng qo'llaniladigan namunasidir.
2. Komponentlar omborining bir nechta versiyalari bir vaqtning o'zida mavjud bo'lgan taqsimlangan tizimlar. Git ( Loeliger and McCullough 2012) taqsimlangan VC tizimining keng tarqalgan namunasidir.
Markazlashtirilgan va taqsimlangan VC tizimlari solishtirish mumkin bo'lgan funksionallikni ta'minlaydi, ammo bu funksiyani turli yo'llar bilan amalga oshiradi. Ushbu tizimlarning asosiy xususiyatlari quyidagilardan iborat:

Versiya va reliz identifikatsiyasi Komponentning boshqariladigan versiyalari tizimga yuborilganda ularga noyob identifikatorlar beriladi. Ushbu identifikatorlar komponent nomini o'zgartirmasdan, bir xil komponentning turli versiyalarini boshqarishga imkon beradi. Versiyalarga atributlar ham berilishi mumkin, atributlar to‘plami har bir versiyani yagona aniqlash uchun ishlatiladi.
2. O'zgarishlar tarixini yozib olish VC tizimi komponentning oldingi versiyasidan yangi versiyasini yaratish uchun kiritilgan o'zgarishlarni qayd qiladi. Ba'zi tizimlarda bu o'zgarishlar muayyan tizim versiyasini tanlash uchun ishlatilishi mumkin. Bu kiritilgan o'zgarishlarni tavsiflovchi kalit so'zlar bilan komponentlarni belgilashni o'z ichiga oladi. Keyin ushbu teglardan asosiy chiziqqa kiritiladigan komponentlarni tanlash uchun foydalanasiz.
Mustaqil ishlab chiqish Turli ishlab chiquvchilar bir vaqtning o'zida bir xil komponent ustida ishlayotgan bo'lishi mumkin. Versiyalarni boshqarish tizimi tahrirlash uchun tekshirilgan komponentlarni kuzatib boradi va turli ishlab chiquvchilar tomonidan komponentga kiritilgan o'zgarishlar xalaqit bermasligini ta'minlaydi.
Loyihani qo'llab-quvvatlash Versiyalarni boshqarish tizimi bir nechta loyihalarni ishlab chiqishni qo'llab-quvvatlashi mumkin, ular birgalikda komponentlardir. Odatda, bir vaqtning o'zida bitta fayl yoki katalog bilan ishlashdan ko'ra, loyiha bilan bog'liq barcha fayllarni tekshirish va tekshirish mumkin.
Saqlashni boshqarish Komponentning barcha versiyalarining alohida nusxalarini saqlash o'rniga, versiyalarni boshqarish tizimi bir xil fayllarning takroriy nusxalari saqlanmasligini ta'minlash uchun samarali mexanizmlardan foydalanishi mumkin. Fayllar o'rtasida faqat kichik farqlar mavjud bo'lsa, VC tizimi fayllarning bir nechta nusxalarini saqlash o'rniga bu farqlarni saqlashi mumkin. Muayyan versiya farqlarni asosiy versiyaga qo'llash orqali avtomatik ravishda qayta yaratilishi mumkin.

Ko'pgina dasturiy ta'minotni ishlab chiqish jamoaviy faoliyatdir, shuning uchun bir nechta jamoa a'zolari bir vaqtning o'zida bir komponentda ishlaydi. Masalan, Alisa tizimga ba'zi o'zgarishlar kiritmoqda, bu A, B va C komponentlarini o'zgartirishni nazarda tutadi. Shu bilan birga, Bob X, Y va C komponentlariga o'zgartirish kiritishni talab qiluvchi o'zgarishlar ustida ishlamoqda. Elis ikkalasi ham va Bob shuning uchun C ni o'zgartirmoqda. O'zgarishlar bir-biriga xalaqit beradigan vaziyatlardan qochish muhim - Bobning C ga o'zgarishi, Elisning ustiga yozish yoki aksincha.
Mustaqil rivojlanishni aralashuvsiz qo'llab-quvvatlash uchun barcha versiyalarni boshqarish tizimlari loyiha ombori va shaxsiy ish maydoni tushunchasidan foydalanadi. Loyiha ombori barcha komponentlarning "master" versiyasini saqlaydi, bu esa tizimni qurish uchun asoslarni yaratish uchun ishlatiladi. Komponentlarni o'zgartirganda, ishlab chiquvchilar ularni ombordan o'zlarining ish joylariga ko'chiradilar va ushbu nusxalar ustida ishlaydilar. O'zgarishlarni tugatgandan so'ng, o'zgartirilgan komponentlar omborga qaytariladi (ro'yxatdan o'tkaziladi). Biroq, markazlashtirilgan va taqsimlangan VC tizimlari birgalikda komponentlarning mustaqil rivojlanishini turli yo'llar bilan qo'llab-quvvatlaydi.
Markazlashtirilgan tizimlarda ishlab chiquvchilar loyiha omboridan o'zlarining shaxsiy ish joylariga komponentlar yoki komponentlar kataloglarini tekshiradilar va o'zlarining shaxsiy ish joylarida ushbu nusxalar ustida ishlaydilar. O'zgartirishlar tugallangach, ular komponentlarni omborga qaytadan tekshiradilar. Bu keyinchalik baham ko'rish mumkin bo'lgan yangi komponent versiyasini yaratadi. Rasm uchun 25.5-rasmga qarang.

Bu erda Elis A1.0, B1.0 va C1.0 versiyalarini tekshirdi. U ushbu versiyalar ustida ishlagan va yangi A1.1, B1.1 va C1.1 versiyalarini yaratgan. U ushbu yangi versiyalarni omborga tekshiradi. Bob X1.0, Y1.0 va C1.0 ni tekshiradi. U ushbu komponentlarning yangi versiyalarini yaratadi va ularni omborga qaytadan tekshiradi. Biroq, Elis allaqachon C ning yangi versiyasini yaratgan, Bob esa uning ustida ishlamoqda. Shuning uchun uning ro'yxatdan o'tish jarayoni boshqa C1.2 versiyasini yaratadi, shuning uchun Elisning o'zgarishlari qayta yozilmaydi.
Ikki yoki undan ortiq kishi bir vaqtning o'zida komponent ustida ishlayotgan bo'lsa, har biri komponentni ombordan tekshirishi kerak. Agar komponent tekshirilgan bo'lsa, versiyani boshqarish tizimi ushbu komponentni tekshirmoqchi bo'lgan boshqa foydalanuvchilarni u boshqa birov tomonidan tekshirilganligi haqida ogohlantiradi. Tizim, shuningdek, o'zgartirilgan komponentlar tekshirilganda, turli versiyalarga turli versiya identifikatorlari tayinlanishini va alohida saqlanishini ta'minlaydi.
Git kabi taqsimlangan VC tizimida boshqa yondashuv qo'llaniladi. Ishlab chiquvchilar guruhi tomonidan ishlab chiqarilgan kodni saqlaydigan serverda "master" ombori yaratiladi. Faqatgina kerakli fayllarni tekshirish o'rniga, dasturchi o'z kompyuteriga yuklab olinadigan va o'rnatiladigan loyiha omborining klonini yaratadi.
Ishlab chiquvchilar kerakli fayllar ustida ishlaydilar va yangi versiyalarni shaxsiy kompyuterlaridagi shaxsiy omborlarida saqlaydilar. O'zgartirishlar kiritishni tugatgandan so'ng, ular ushbu o'zgarishlarni "majbur qiladilar" va shaxsiy server omborini yangilaydilar. Keyin ular ushbu o'zgarishlarni loyiha omboriga "surishlari" yoki integratsiya menejeriga o'zgartirilgan versiyalar mavjudligini aytishi mumkin. Keyin u ushbu fayllarni loyiha omboriga "tortib olishi" mumkin (25.6-rasmga qarang). Ushbu misolda Bob ham, Elis ham loyiha omborini klonlashtirgan va fayllarni yangilagan. Ular hali bularni loyiha omboriga qaytarishmadi.

Rivojlanishning ushbu modeli bir qator afzalliklarga ega:
1. U ombor uchun zaxira mexanizmini taqdim etadi. Agar ombor buzilgan bo'lsa, ish davom etishi mumkin va loyiha ombori mahalliy nusxalardan tiklanishi mumkin.
2. Agar tarmoqqa ulanmagan bo'lsa, ishlab chiquvchilar o'zgarishlarni amalga oshirishi uchun oflayn rejimda ishlash imkonini beradi.
3. Loyihani qo'llab-quvvatlash standart ish usuli hisoblanadi. Ishlab chiquvchilar butun tizimni o'zlarining mahalliy mashinalarida kompilyatsiya qilishlari va sinab ko'rishlari va o'zlari kiritgan o'zgarishlarni sinab ko'rishlari mumkin.
Tarqalgan versiyani boshqarish ochiq manbali ishlab chiqish uchun juda muhim, bunda bir nechta odam bir vaqtning o'zida bir xil tizimda hech qanday markaziy muvofiqlashtirishsiz ishlashi mumkin. Ochiq manbali tizim "menejyeri" uchun qachon o'zgartirishlar kiritilishini bilishning imkoni yo'q. Bunday holda, ishlab chiquvchilar o'zlarining shaxsiy kompyuterlaridagi shaxsiy omborlari bilan bir qatorda, o'zlari o'zgartirgan komponentlarning yangi versiyalarini bosadigan umumiy server omborini ham saqlaydilar. Keyinchalik, bu o'zgarishlarni aniq tizimga qachon kiritish kerakligini ochiq manbali tizim "menejeri" hal qiladi. Ushbu tashkilot 25.7-rasmda ko'rsatilgan.

Ushbu misolda Charli ochiq kodli tizim uchun integratsiya menejeri. Elis va Bob tizimni ishlab chiqishda mustaqil ishlaydilar va aniq loyiha omborini klonlashadi (1). Elis ham, Bob ham o'zlarining shaxsiy omborlari bilan bir qatorda, Charli kirishi mumkin bo'lmagan serverda umumiy omborga ega. Ular o'zgartirishlar kiritib, sinab ko'rganlarida, ular o'zgartirilgan versiyalarni shaxsiy omborlaridan shaxsiy umumiy omborlariga suradilar va Charliga bu omborlar mavjudligini aytadilar (2). Charli ularni o'z omborlaridan o'zining shaxsiy omboriga sinovdan o'tkazish uchun oladi (3). O'zgarishlarning maqbul ekanligiga ishonch hosil qilgandan so'ng, u aniq loyiha omborini yangilaydi (4).
Xuddi shu komponentning mustaqil rivojlanishining natijasi shundaki, kodekslar tarmoqlanishi mumkin. Vaqt o'tishi bilan komponentdagi o'zgarishlarni aks ettiruvchi versiyalarning chiziqli ketma-ketligi o'rniga, 25.8-rasmda ko'rsatilganidek, bir nechta mustaqil ketma-ketliklar bo'lishi mumkin. Bu tizimni ishlab chiqishda normal holat bo'lib, turli ishlab chiquvchilar manba kodining turli versiyalarida mustaqil ravishda ishlaydi va uni turli yo'llar bilan o'zgartiradi. Tizim ustida ishlayotganda, odatda, o'zgarishlar ishchi tizimni tasodifan buzmasligi uchun yangi filialni yaratish tavsiya etiladi.

barcha kiritilgan o'zgarishlarni o'z ichiga olgan komponentning yangi versiyasini yaratish uchun kod chizig'i shoxlarini birlashtirish kerak bo'lishi mumkin . Bu 25.8-rasmda ham ko'rsatilgan, unda 2.1.2 va 2.3 komponent versiyalari 2.4 versiyasini yaratish uchun birlashtiriladi. Agar kiritilgan o'zgartirishlar kodning butunlay boshqa qismlarini o'z ichiga olsa, komponent versiyalari kod o'zgarishlarini birlashtirish orqali versiyani boshqarish tizimi tomonidan avtomatik ravishda birlashtirilishi mumkin. Bu yangi funksiyalar qo'shilganda odatiy ish rejimidir. Ushbu kod o'zgarishlari tizimning asosiy nusxasiga birlashtiriladi. Biroq, turli ishlab chiquvchilar tomonidan kiritilgan o'zgarishlar ba'zan bir-biriga mos keladi. O'zgarishlar mos kelmasligi va bir-biriga xalaqit berishi mumkin. Bunday holda, ishlab chiquvchi to'qnashuvlarni tekshirishi va turli versiyalar o'rtasidagi nomuvofiqlikni bartaraf etish uchun komponentlarga o'zgartirishlar kiritishi kerak.
Versiyalarni boshqarish tizimlari birinchi marta ishlab chiqilganda, saqlashni boshqarish ularning eng muhim funktsiyalaridan biri edi. Disk maydoni qimmat edi va komponentlarning turli nusxalari ishlatadigan disk maydonini minimallashtirish muhim edi. Har bir versiyaning to'liq nusxasini saqlash o'rniga, tizim bir versiya va boshqa versiya o'rtasidagi farqlar ro'yxatini (deltalar) saqlaydi. Ularni asosiy versiyaga (odatda eng so'nggi versiya) qo'llash orqali maqsadli versiyani qayta yaratish mumkin. Bu 25.9-rasmda ko'rsatilgan.

Yangi versiya yaratilganda, tizim shunchaki yangi versiya va ushbu yangi versiyani yaratish uchun foydalanilgan eski versiya o'rtasidagi farqlar ro'yxatini, deltani saqlaydi. 25.9-rasmda soyali qutilar komponentning eng oxirgi versiyasidan avtomatik ravishda qayta yaratiladigan oldingi versiyalarini ifodalaydi. Deltalar odatda o'zgartirilgan qatorlar ro'yxati sifatida saqlanadi va ularni avtomatik ravishda qo'llash orqali komponentning bir versiyasi boshqasidan yaratilishi mumkin. Komponentning eng so'nggi versiyasi ishlatilgan bo'lishi mumkinligi sababli, aksariyat tizimlar ushbu versiyani to'liq saqlaydi. Keyin deltalar oldingi tizim versiyalarini qanday qayta yaratishni belgilaydi.
Saqlashni boshqarishda deltaga asoslangan yondashuv bilan bog'liq muammolardan biri shundaki, barcha deltalarni qo'llash uzoq vaqt talab qilishi mumkin. Disk xotirasi nisbatan arzon bo'lganligi sababli, Git muqobil, tezroq yondashuvdan foydalanadi. Git deltalardan foydalanmaydi, lekin saqlangan fayllar va ular bilan bog'liq meta-ma'lumotlarga standart siqish algoritmini qo'llaydi. U fayllarning ikki nusxadagi nusxalarini saqlamaydi. Faylni olish oddiygina uni ochishni o'z ichiga oladi, bunda operatsiyalar zanjirini qo'llash kerak emas. Git shuningdek , bir nechta kichikroq fayllar indekslangan bitta faylga birlashtirilgan paketli fayllar tushunchasidan foydalanadi . Bu ko'plab kichik fayllar bilan bog'liq bo'lgan qo'shimcha xarajatlarni kamaytiradi. Deltalar paketli fayllar ichida ularning hajmini yanada kamaytirish uchun ishlatiladi.
8.2. Tizim qurish
Tizim qurish - bu tizim komponentlarini, tashqi kutubxonalarni, konfiguratsiya fayllarini va boshqa ma'lumotlarni kompilyatsiya qilish va bog'lash orqali to'liq, bajariladigan tizimni yaratish jarayoni. Tizim yaratish vositalari va versiyalarni boshqarish vositalari birlashtirilishi kerak, chunki qurish jarayoni versiyalarni boshqarish tizimi tomonidan boshqariladigan ombordan komponent versiyalarini oladi.
Tizimni qurish dasturiy ta'minot va uning ishlash muhiti haqida katta hajmdagi ma'lumotlarni yig'ishni o'z ichiga oladi. Shuning uchun tizim qurilishini yaratish uchun har doim avtomatlashtirilgan qurish vositasidan foydalanish mantiqan to'g'ri keladi (25.10-rasm). E'tibor bering, sizga faqat qurilishda ishtirok etadigan manba kodi fayllari kerak emas. Siz ularni tashqi tomondan taqdim etilgan kutubxonalar, maʼlumotlar fayllari (masalan, xato xabarlari fayli) va maqsadli oʻrnatishni belgilaydigan konfiguratsiya fayllari bilan bogʻlashingiz kerak boʻlishi mumkin. Qurilishda foydalaniladigan kompilyator va boshqa dasturiy vositalarning versiyalarini ko'rsatishingiz kerak bo'lishi mumkin. Ideal holda, siz bitta buyruq yoki sichqonchani bosish bilan to'liq tizimni yaratishingiz kerak.

Tizim integratsiyasi va qurish vositalari quyidagi xususiyatlarning bir qismini yoki barchasini o'z ichiga oladi:
1. Qurilish skriptini yaratish Qurilish tizimi qurilayotgan dasturni tahlil qilishi, unga bog'liq komponentlarni aniqlashi va avtomatik ravishda qurish skriptini (konfiguratsiya faylini) yaratishi kerak. Tizim, shuningdek, qurilish skriptlarini qo'lda yaratish va tahrirlashni qo'llab-quvvatlashi kerak.
2. Versiyani boshqarish tizimining integratsiyasi Qurilish tizimi versiyani boshqarish tizimidan komponentlarning kerakli versiyalarini tekshirishi kerak.
3. Minimal qayta kompilyatsiya. Qurilish tizimi qaysi manba kodini qayta kompilyatsiya qilish kerakligini aniqlashi va kerak bo'lganda kompilyatsiyalarni o'rnatishi kerak.
4. Bajariladigan tizimni yaratish Qurilish tizimi bajariladigan tizimni yaratish uchun kompilyatsiya qilingan ob'ekt kodli fayllarni bir-biri bilan va kutubxonalar va konfiguratsiya fayllari kabi boshqa kerakli fayllar bilan bog'lashi kerak.
5. Sinovlarni avtomatlashtirish Ba'zi tuzilma tizimlari JUnit kabi testlarni avtomatlashtirish vositalaridan foydalangan holda avtomatlashtirilgan testlarni avtomatik ravishda bajarishi mumkin. Bular qurilish o'zgarishlar bilan "buzilmagan"ligini tekshiradi.
6. Hisobot Qurilish tizimi qurilishning muvaffaqiyati yoki muvaffaqiyatsizligi va o'tkazilgan testlar haqida hisobotlarni taqdim etishi kerak.
7. Hujjatlarni yaratish Qurilish tizimi tuzilish va tizim yordam sahifalari haqida relizlar eslatmalarini yaratishi mumkin.
Qurilish skripti quriladigan tizimning ta'rifidir. U komponentlar va ularning bog'liqliklari, tizimni kompilyatsiya qilish va bog'lash uchun ishlatiladigan asboblar versiyalari haqida ma'lumotni o'z ichiga oladi. Qurilish skriptini aniqlash uchun ishlatiladigan konfiguratsiya tili tuzilishga kiritiladigan tizim komponentlarini va ularning bog'liqliklarini tavsiflash uchun konstruksiyalarni o'z ichiga oladi.

Qurilish - bu murakkab jarayon bo'lib, u xatoga yo'l qo'yishi mumkin, chunki uchta turli tizim platformalari ishtirok etishi mumkin (25.11-rasm):
1. Kompilyatorlar va dastlabki kod muharrirlari kabi ishlab chiqish vositalarini o'z ichiga olgan ishlab chiqish tizimi. Dasturchilar tizimga o'zgartirish kiritishdan oldin versiyani boshqarish tizimidan shaxsiy ish maydoniga kodni tekshiradilar. Ular versiyani boshqarish tizimiga kiritilgan o'zgarishlarni amalga oshirishdan oldin o'zlarining ishlab chiqish muhitida sinov uchun tizim versiyasini yaratishni xohlashlari mumkin. Bu shaxsiy ish maydonida komponentlarning tekshirilgan versiyalaridan foydalanadigan mahalliy qurish vositalaridan foydalanishni o'z ichiga oladi.
2. Tizimning aniq, bajariladigan versiyalarini yaratish uchun foydalaniladigan qurish serveri. Ushbu server tizimning aniq versiyalarini saqlaydi. Barcha tizim ishlab chiquvchilari tizimni yaratish uchun tuzilish serveridagi versiyani boshqarish tizimiga kodni tekshiradilar.
3. Tizim bajaradigan platforma bo'lgan maqsadli muhit. Bu tizimlarni ishlab chiqish va qurish uchun ishlatiladigan kompyuter turi bo'lishi mumkin. Biroq, real vaqtda va o'rnatilgan tizimlar uchun maqsadli muhit ko'pincha ishlab chiqish muhitidan (masalan, uyali telefon) kichikroq va soddaroqdir. Katta tizimlar uchun maqsadli muhit ma'lumotlar bazalari va ishlab chiquvchi mashinalarga o'rnatib bo'lmaydigan boshqa amaliy tizimlarni o'z ichiga olishi mumkin. Bunday holatlarda tizimni ishlab chiquvchi kompyuterda yoki qurish serverida qurish va sinab ko'rish mumkin emas.

Agile usullari dasturiy ta'minot muammolarini aniqlash uchun avtomatlashtirilgan sinovdan foydalangan holda tizimni tez-tez qurishni tavsiya qiladi. Tez-tez qurish 25.12-rasmda ko'rsatilganidek, uzluksiz integratsiya jarayonining bir qismidir . Ko'pgina kichik o'zgarishlarni amalga oshirishning tezkor usullari tushunchasiga muvofiq, uzluksiz integratsiya kichik manba kodiga o'zgartirishlar kiritilgandan so'ng tez-tez magistralni qayta qurishni o'z ichiga oladi. Uzluksiz integratsiyaning bosqichlari:
1. Magistral tizimni VC tizimidan ishlab chiquvchining shaxsiy ish maydoniga chiqarib oling.
2. O'rnatilgan tizim barcha testlardan o'tishini ta'minlash uchun tizimni yarating va avtomatlashtirilgan testlarni o'tkazing. Agar yo'q bo'lsa, qurilish buzilgan va siz oxirgi bazaviy tizimda kimni tekshirgan bo'lsa, bu haqda xabar berishingiz kerak. U muammoni tuzatish uchun javobgardir.
3. Tizim komponentlariga o'zgartirishlar kiriting.
4. Tizimni shaxsiy ish maydonida yarating va tizim testlarini qayta o'tkazing. Sinovlar muvaffaqiyatsiz bo'lsa, tahrirlashni davom eting.
5. Tizim sinovlardan o'tgandan so'ng, uni tuzilma tizimi serveriga tekshiring, lekin uni VC tizimida yangi tizim bazasi sifatida ishlatmang.
6. Qurilish serverida tizimni yarating va testlarni bajaring. Shu bilan bir qatorda, agar siz Git dan foydalanayotgan bo'lsangiz , oxirgi o'zgarishlarni serverdan shaxsiy ish joyingizga o'tkazishingiz mumkin. Agar tizimni tekshirganingizdan so'ng boshqalar komponentlarni o'zgartirgan bo'lsa, buni qilishingiz kerak. Agar shunday bo'lsa, muvaffaqiyatsiz bo'lgan komponentlarni tekshiring va testlar shaxsiy ish joyingizda o'tishi uchun ularni tahrirlang.
7. Agar tizim qurish tizimida o'z sinovlaridan o'tsa, tizimning asosiy chizig'ida yangi baza sifatida kiritilgan o'zgarishlarni amalga oshiring.
Jenkins (Smart 2011) kabi vositalar uzluksiz integratsiyani qo'llab-quvvatlash uchun ishlatiladi. Ushbu vositalar dasturchi omborni yangilashni tugatgandan so'ng tizimni yaratish uchun sozlanishi mumkin.
Uzluksiz integratsiyaning afzalligi shundaki, u turli ishlab chiquvchilar o'rtasidagi o'zaro aloqalar natijasida yuzaga keladigan muammolarni imkon qadar tezroq aniqlash va tuzatish imkonini beradi. Magistral yo'nalishdagi eng so'nggi tizim aniq ish tizimidir. Biroq, uzluksiz integratsiya yaxshi g'oya bo'lsa-da, tizimni qurishda ushbu yondashuvni har doim ham amalga oshirish mumkin emas:
1. Agar tizim juda katta bo'lsa, uni qurish va sinovdan o'tkazish uzoq vaqt talab qilishi mumkin, ayniqsa, boshqa amaliy tizimlar bilan integratsiyalashgan bo'lsa. Kuniga bir necha marta ishlab chiqilayotgan tizimni qurish amaliy bo'lmasligi mumkin.
2. Agar ishlab chiqish platformasi maqsadli platformadan farq qilsa, ishlab chiquvchining shaxsiy ish maydonida tizim testlarini o‘tkazish imkoni bo‘lmasligi mumkin. Uskuna, operatsion tizim yoki o'rnatilgan dasturiy ta'minotda farqlar bo'lishi mumkin. Shuning uchun tizimni sinab ko'rish uchun ko'proq vaqt talab etiladi.
Katta tizimlar yoki ijro platformasi ishlab chiqish platformasi bilan bir xil bo'lmagan tizimlar uchun doimiy integratsiya odatda mumkin emas. Bunday sharoitda tez-tez tizim qurish kundalik qurish tizimi yordamida qo'llab-quvvatlanadi:
1. Rivojlanish tashkiloti tizim komponentlari uchun yetkazib berish vaqtini (aytaylik, 14:00) belgilaydi. Agar ishlab chiquvchilar o'zlari yozayotgan komponentlarning yangi versiyalariga ega bo'lsa, ularni o'sha vaqtga qadar etkazib berishlari kerak. Komponentlar to'liq bo'lmasligi mumkin, lekin sinovdan o'tishi mumkin bo'lgan ba'zi asosiy funktsiyalarni ta'minlashi kerak.
2. Ushbu komponentlardan kompilyatsiya qilish va bog'lash orqali to'liq tizim hosil qilish uchun tizimning yangi versiyasi tuziladi.
3. Keyin ushbu tizim oldindan belgilangan tizim testlari to'plamini amalga oshiradigan test guruhiga etkaziladi.
4. Tizimni sinovdan o'tkazishda aniqlangan nosozliklar hujjatlashtiriladi va tizim ishlab chiquvchilariga qaytariladi. Ular ushbu nosozliklarni komponentning keyingi versiyasida tuzatadilar.
Tez-tez tuziladigan dasturiy ta'minotdan foydalanishning afzalliklari shundan iboratki, jarayonning boshida komponentlarning o'zaro ta'siridan kelib chiqadigan muammolarni topish imkoniyati ortadi. Tez-tez qurish komponentlarni sinchkovlik bilan sinovdan o'tkazishga yordam beradi. Psixologik jihatdan ishlab chiquvchilarga "qurilishni buzmaslik" uchun bosim o'tkaziladi; ya'ni ular butun tizimning ishlamay qolishiga olib keladigan komponentlarning versiyalarini tekshirishdan qochishga harakat qilishadi. Shuning uchun ular to'g'ri sinovdan o'tmagan yangi komponent versiyalarini etkazib berishni istamaydilar. Shunday qilib, ishlab chiquvchi tomonidan topilishi mumkin bo'lgan dasturiy ta'minotdagi nosozliklarni aniqlash va ularni bartaraf etish uchun tizimni sinovdan o'tkazish uchun kamroq vaqt sarflanadi.
Kompilyatsiya hisoblashni talab qiladigan jarayon bo'lganligi sababli, tizimni qurishni qo'llab-quvvatlash vositalari talab qilinadigan kompilyatsiya miqdorini minimallashtirish uchun mo'ljallangan bo'lishi mumkin. Ular buni komponentning kompilyatsiya qilingan versiyasi mavjudligini tekshirish orqali amalga oshiradilar. Agar shunday bo'lsa, ushbu komponentni qayta kompilyatsiya qilishning hojati yo'q. Shuning uchun komponentning manba kodini uning ekvivalent ob'ekt kodi bilan aniq bog'lash usuli bo'lishi kerak.
Ushbu ulanish manba kodi komponenti saqlanadigan har bir fayl bilan noyob imzoni bog'lash orqali amalga oshiriladi. Manba kodidan tuzilgan tegishli ob'ekt kodi tegishli imzoga ega. Imzo har bir manba kodi versiyasini aniqlaydi va manba kodi tahrirlanganda o'zgartiriladi. Manba va ob'ekt kodi fayllaridagi imzolarni solishtirish orqali ob'ekt kodi komponentini yaratish uchun manba kodi komponenti ishlatilganligini aniqlash mumkin.

25.13-rasm Manba va obyekt kodini ulash
25.13-rasmda ko'rsatilganidek, ikki turdagi imzo qo'llanilishi mumkin:

O'zgartirish vaqt belgilari. Manba kodi faylidagi imzo bu fayl o'zgartirilgan vaqt va sana hisoblanadi. Agar komponentning manba kodi fayli tegishli ob'ekt kodi faylidan keyin o'zgartirilgan bo'lsa, tizim yangi ob'ekt kodi faylini yaratish uchun qayta kompilyatsiya qilish zarur deb hisoblaydi.

Masalan, Comp.java va Comp.class komponentlarida mos ravishda 17:03:05:02:14:2014 va 16:58:43:02:14:2014 oʻzgartirish imzolari bor. Bu shuni anglatadiki, Java kodi 2014-yil 14-fevralda 5dan 3 daqiqa 5 soniya o‘tganda va kompilyatsiya qilingan versiya 2014-yil 14-fevralda 4dan 58 daqiqa 43 soniya o‘tganda o‘zgartirilgan. Bunday holda, tizim Comp.java-ni avtomatik ravishda qayta kompilyatsiya qiling, chunki kompilyatsiya qilingan versiya komponentning eng oxirgi versiyasidan oldingi o'zgartirish sanasiga ega.

Manba kodini tekshirish summalari Manba kod faylidagi imzo fayldagi ma'lumotlardan hisoblangan nazorat summasidir. Tekshirish summasi funksiyasi kirish sifatida manba matnidan foydalangan holda noyob raqamni hisoblab chiqadi. Agar siz manba kodini o'zgartirsangiz (hatto bitta belgi bo'lsa ham), bu boshqa nazorat summasini hosil qiladi. Shunday qilib, turli nazorat summalariga ega bo'lgan manba kodli fayllar aslida boshqacha ekanligiga ishonchingiz komil bo'lishi mumkin. Tekshirish summasi kompilyatsiya qilishdan oldin manba kodiga tayinlanadi va manba faylni noyob tarzda aniqlaydi. So'ngra qurish tizimi yaratilgan ob'ekt kodi fayliga nazorat summasi imzosi bilan teglar qo'yadi. Agar tizimga kiritiladigan manba kod fayli bilan bir xil imzoga ega bo'lgan ob'ekt kodi fayli bo'lmasa, manba kodini qayta kompilyatsiya qilish kerak bo'ladi.

Ob'ekt kodlari fayllari odatda versiyalashtirilmaganligi sababli, birinchi yondashuv tizimda faqat eng so'nggi tuzilgan ob'ekt kodi fayli saqlanishini anglatadi. Bu odatda manba kod fayli nomi bilan bog'liq; ya'ni u manba kod fayli bilan bir xil nomga ega, lekin boshqa qo'shimchaga ega. Shuning uchun Comp.Java manba fayli Comp.class obyekt faylini yaratishi mumkin . Resurs va ob'ekt fayllari nomlari bilan bog'langanligi sababli, odatda bir vaqtning o'zida bir katalogga manba kodi komponentining turli versiyalarini qurish mumkin emas. Kompilyator bir xil nomdagi ob'ekt fayllarini yaratadi, shuning uchun faqat eng so'nggi tuzilgan versiya mavjud bo'ladi.
Tekshirish yig'indisi yondashuvi bir vaqtning o'zida komponent ob'ekt kodining ko'plab turli xil versiyalarini saqlashga imkon berishning afzalligiga ega. Fayl nomi emas, balki imzo manba va ob'ekt kodi o'rtasidagi bog'lanishdir. Manba kodi va obyekt kodi fayllari bir xil imzoga ega. Shuning uchun, komponentni qayta kompilyatsiya qilganingizda, odatda vaqt tamg'asi ishlatilganda bo'lgani kabi, u ob'ekt kodini qayta yozmaydi. Aksincha, u yangi obyekt kodi faylini yaratadi va uni manba kodi imzosi bilan teglaydi. Parallel kompilyatsiya qilish mumkin va komponentning turli versiyalari bir vaqtning o'zida kompilyatsiya qilinishi mumkin.
8 .3 O'zgarishlarni boshqarish
O'zgarish katta dasturiy ta'minot tizimlari uchun hayot haqiqatidir. Tizimning ishlash muddati davomida tashkilot ehtiyojlari va talablari o'zgaradi, xatolar tuzatilishi va tizimlar o'z muhitidagi o'zgarishlarga moslashishi kerak. O'zgarishlar tizimga boshqariladigan tarzda qo'llanilishini ta'minlash uchun sizga asboblar tomonidan qo'llab-quvvatlanadigan, o'zgarishlarni boshqarish jarayonlari to'plami kerak bo'ladi.
O'zgarishlarni boshqarish tizimning evolyutsiyasi nazorat qilinishini va eng shoshilinch va tejamkor o'zgarishlarning ustuvorligini ta'minlash uchun mo'ljallangan. O'zgarishlarni boshqarish - bu taklif qilingan o'zgarishlarning xarajatlari va foydalarini tahlil qilish, iqtisodiy jihatdan samarali bo'lgan o'zgarishlarni tasdiqlash va tizimdagi qaysi komponentlar o'zgartirilganligini kuzatish jarayoni. 25.14-rasmda o'zgarishlarni boshqarish jarayonining modeli ko'rsatilgan bo'lib, unda o'zgarishlarni boshqarishning asosiy faoliyati ko'rsatilgan. Ushbu jarayon dasturiy ta'minot mijozlarga chiqarish yoki tashkilot ichida joylashtirish uchun topshirilganda kuchga kirishi kerak.

Ushbu jarayonning ko'plab variantlari dasturiy ta'minotning maxsus tizim, mahsulot liniyasi yoki tayyor mahsulot ekanligiga qarab qo'llaniladi. Kompaniyaning kattaligi ham farq qiladi - kichik kompaniyalar korporativ yoki davlat mijozlari bilan ishlaydigan yirik kompaniyalarga qaraganda kamroq rasmiy jarayondan foydalanadilar. Biroq, barcha o'zgarishlarni boshqarish jarayonlari o'zgarishlarni tekshirish, xarajatlarni hisoblash va tasdiqlashning qandaydir usullarini o'z ichiga olishi kerak.
Clearcase kabi keng ko'lamli tizimlar uchun konfiguratsiyani boshqarish paketi bilan birlashtirilgan dasturiy ta'minot bo'lishi mumkin . Muammolarni kuzatish tizimlari har kimga xato haqida xabar berish yoki tizimni o'zgartirish bo'yicha taklif kiritish imkonini beradi va ular ishlab chiqish guruhi muammolarga qanday munosabatda bo'lganini kuzatib boradi. Ushbu tizimlar foydalanuvchilarga jarayonni yuklamaydi va shuning uchun turli xil sozlamalarda foydalanish mumkin. Keyinchalik murakkab tizimlar o'zgarishlarni boshqarish jarayonining jarayon modeli atrofida qurilgan. Ular mijozning dastlabki taklifidan tortib yakuniy o'zgarishlarni tasdiqlash va ishlab chiqish guruhiga o'zgartirishlar topshirishgacha bo'lgan o'zgartirish so'rovlarini ko'rib chiqishning butun jarayonini avtomatlashtiradi.
O'zgarishlarni boshqarish jarayoni tizim manfaatdor tomonlari tizimga talab qilinadigan o'zgarishlarni tavsiflovchi o'zgartirish so'rovini tugatib yuborganida boshlanadi. Bu xato belgilari tasvirlangan xato hisoboti yoki tizimga qo'shimcha funksiyalarni qo'shish so'rovi bo'lishi mumkin. Ba'zi kompaniyalar xato hisobotlari va yangi talablarni alohida ko'rib chiqadilar, lekin printsipial jihatdan ikkalasi ham oddiygina o'zgartirish so'rovidir. O'zgartirish so'rovlari o'zgartirish so'rovi shakli (CRF) yordamida yuborilishi mumkin. Manfaatdor tomonlar tizim egalari va foydalanuvchilari, beta testerlari, ishlab chiquvchilari yoki kompaniyaning marketing bo'limi bo'lishi mumkin.
Elektron o'zgartirish so'rovi shakllari o'zgarishlarni boshqarish bilan shug'ullanadigan barcha guruhlar o'rtasida almashiladigan qayd ma'lumotlari. O'zgartirish so'rovi ko'rib chiqilayotganda, jarayonning har bir bosqichida qabul qilingan qarorlarni yozib olish uchun CRFga ma'lumotlar qo'shiladi. Istalgan vaqtda, shuning uchun u o'zgartirish so'rovi holatining oniy rasmini ifodalaydi. Kerakli o'zgarishlarni qayd etishdan tashqari, CRF o'zgartirish bo'yicha tavsiyalarni, o'zgartirishning taxminiy xarajatlarini va o'zgartirish so'ralgan, tasdiqlangan, amalga oshirilgan va tasdiqlangan sanalarni qayd etadi. CRF shuningdek, ishlab chiquvchi o'zgartirishni qanday amalga oshirish mumkinligini ko'rsatadigan bo'limni o'z ichiga olishi mumkin. Shunga qaramay, CRFdagi rasmiyatchilik darajasi tizimni ishlab chiqayotgan tashkilotning hajmi va turiga qarab o'zgaradi.
25.15-rasmda yirik kompleks tizim muhandislik loyihasida qo'llanilishi mumkin bo'lgan CRF turiga misol keltirilgan. Kichikroq loyihalar uchun men o'zgartirish so'rovlarini rasmiy ravishda yozib olishni tavsiya qilaman; CRF talab qilinadigan o'zgarishlarni tavsiflashga e'tibor qaratishi kerak, bunda amalga oshirish masalalariga kamroq e'tibor qaratiladi. Tizim ishlab chiquvchilari o'zgarishlarni qanday amalga oshirishni hal qiladilar va o'zgarishlarni amalga oshirish uchun zarur bo'lgan vaqtni hisoblaydilar.

O'zgartirish so'rovi yuborilgandan so'ng, uning haqiqiyligi tekshiriladi. Tekshiruvchi mijoz yoki ilovalarni qo'llab-quvvatlash guruhidan bo'lishi mumkin yoki ichki so'rovlar uchun ishlab chiqish guruhining a'zosi bo'lishi mumkin. Ushbu bosqichda o'zgartirish so'rovi rad etilishi mumkin. Agar o'zgartirish so'rovi xato haqida hisobot bo'lsa, xato allaqachon xabar qilingan va tuzatilgan bo'lishi mumkin. Ba'zida odamlar muammo deb hisoblagan narsa, aslida tizim nima qilishi kutilayotganini noto'g'ri tushunishdir. Ba'zida odamlar allaqachon amalga oshirilgan, lekin ular bilmagan xususiyatlarni so'rashadi. Agar ushbu xususiyatlardan biri to'g'ri bo'lsa, muammo yopiladi va shakl yopilish sababi bilan yangilanadi. Agar u to'g'ri o'zgartirish so'rovi bo'lsa, u keyingi tahlil uchun ajoyib so'rov sifatida qayd qilinadi.
To'g'ri o'zgartirish so'rovlari uchun jarayonning keyingi bosqichi o'zgarishlarni baholash va xarajatlar hisoblanadi. Ushbu funktsiya odatda ishlab chiqish yoki texnik xizmat ko'rsatish guruhining mas'uliyati hisoblanadi, chunki ular o'zgarishlarni amalga oshirishda nima ishtirok etishini ishlab chiqishlari mumkin. O'zgarishlarning tizimning qolgan qismiga ta'sirini tekshirish kerak. Buning uchun siz o'zgarishlardan ta'sirlangan barcha komponentlarni aniqlashingiz kerak. Agar o'zgartirish tizimning boshqa joylarida qo'shimcha o'zgarishlar zarurligini anglatsa, bu o'zgarishlarni amalga oshirish xarajatlarini oshiradi. Keyinchalik, tizim modullariga kerakli o'zgarishlar baholanadi. Nihoyat, tegishli tarkibiy qismlarni o'zgartirish xarajatlarini hisobga olgan holda, o'zgartirishni amalga oshirish qiymati taxmin qilinadi.
Ushbu tahlildan so'ng, alohida guruh biznes uchun dasturiy ta'minotga o'zgartirish kiritish iqtisodiy jihatdan samaralimi yoki yo'qligini hal qiladi. Harbiy va hukumat tizimlari uchun bu guruh ko'pincha o'zgarishlarni boshqarish kengashi (CCB) deb ataladi. Sanoatda uni dasturiy ta'minot tizimining qanday rivojlanishi kerakligi haqida qaror qabul qilish uchun mas'ul bo'lgan "mahsulot ishlab chiqish guruhi" deb atash mumkin. Ushbu guruh barcha o'zgartirish so'rovlarini ko'rib chiqishi va tasdiqlashi kerak, agar o'zgartirishlar oddiygina ekran displeylari, veb-sahifalar yoki hujjatlardagi kichik xatolarni tuzatishni nazarda tutmasa. Ushbu kichik so'rovlar darhol amalga oshirish uchun ishlab chiqish guruhiga yuborilishi kerak.
CCB yoki mahsulotni ishlab chiqish guruhi o'zgarishlarning ta'sirini texnik nuqtai nazardan emas, balki strategik va tashkiliy jihatdan ko'rib chiqadi. U ko'rib chiqilayotgan o'zgarishlarning iqtisodiy jihatdan asosli yoki yo'qligini hal qiladi va amalga oshirish uchun qabul qilingan o'zgarishlarni birinchi o'ringa qo'yadi. Qabul qilingan o'zgarishlar ishlab chiqish guruhiga qaytariladi; rad etilgan o'zgartirish so'rovlari yopiladi va boshqa hech qanday chora ko'rilmaydi. O'zgartirishni amalga oshirish yoki qilmaslik to'g'risida qaror qabul qilishga ta'sir qiluvchi omillarga quyidagilar kiradi:
1. O'zgartirish kiritmaslik oqibatlari O'zgartirish so'rovini baholashda, agar o'zgartirish amalga oshirilmasa, nima bo'lishini hisobga olishingiz kerak. Agar o'zgarishlar tizim xatosi bilan bog'liq bo'lsa, bu xatoning jiddiyligini hisobga olish kerak. Agar tizimdagi nosozlik tizimning ishdan chiqishiga sabab bo'lsa, bu juda jiddiy va o'zgarishlarni amalga oshirmaslik tizimdan operatsion foydalanishni buzishi mumkin. Boshqa tomondan, agar buzilish displeydagi noto'g'ri ranglar kabi kichik ta'sirga ega bo'lsa, unda muammoni tezda hal qilish muhim emas. Shuning uchun o'zgarish past ustuvorlikka ega bo'lishi kerak.
2. O'zgartirishning afzalliklari O'zgartirish tizimning ko'plab foydalanuvchilariga foyda keltiradimi yoki faqat o'zgartirish taklifchisiga foyda keltiradimi?
3. O'zgartirishdan ta'sirlangan foydalanuvchilar soni Agar bir nechta foydalanuvchi ta'sir ko'rsatsa, o'zgartirishga past ustuvorlik berilishi mumkin. Aslida, agar tizim foydalanuvchilarining ko'pchiligi unga moslashishi kerak bo'lsa, o'zgartirishni kiritish maqsadga muvofiq emas.
4. O'zgartirish kiritish xarajatlari Agar o'zgartirish tizimning ko'plab komponentlariga ta'sir qilsa (shuning uchun yangi xatolarni kiritish imkoniyatini oshirsa) va/yoki amalga oshirish uchun ko'p vaqt talab qilinsa, o'zgartirish rad etilishi mumkin.
5. Mahsulotni chiqarish tsikli Agar dasturiy ta'minotning yangi versiyasi mijozlarga endigina chiqarilgan bo'lsa, o'zgartirishni amalga oshirishni keyingi rejalashtirilgan relizgacha kechiktirish mantiqiy bo'lishi mumkin (25.4-bo'limga qarang).
Muayyan mijoz uchun maxsus ishlab chiqilgan maxsus tizimlar o'rniga dasturiy mahsulotlar (masalan, SAPR tizimi mahsuloti) uchun o'zgarishlarni boshqarish boshqacha tarzda ko'rib chiqiladi. Dasturiy ta'minot mahsulotlarida mijoz tizim evolyutsiyasi bo'yicha qarorlarni qabul qilishda bevosita ishtirok etmaydi, shuning uchun o'zgartirishning mijozning biznesiga tegishliligi muammo emas. Ushbu mahsulotlarni o'zgartirish so'rovlari mijozlarni qo'llab-quvvatlash jamoasi, kompaniya marketing jamoasi va ishlab chiquvchilarning o'zidan keladi. Ushbu so'rovlar mijozlarning takliflari va fikr-mulohazalarini yoki raqobatdosh mahsulotlar tomonidan taqdim etilgan tahlillarni aks ettirishi mumkin.
Mijozlarni qo'llab-quvvatlash jamoasi dasturiy ta'minot chiqarilgandan so'ng mijozlar tomonidan aniqlangan va xabar qilingan xatolar bilan bog'liq o'zgartirish so'rovlarini yuborishi mumkin. Xatolar haqida xabar berish uchun mijozlar veb-sahifa yoki elektron pochtadan foydalanishlari mumkin. Xatolarni boshqarish guruhi xato hisobotlarining haqiqiyligini tekshiradi va ularni rasmiy tizimni o'zgartirish so'rovlariga tarjima qiladi. Marketing xodimlari mijozlar bilan uchrashishlari va raqobatbardosh mahsulotlarni tekshirishlari mumkin. Ular yangi va mavjud mijozlarga tizimning yangi versiyasini sotishni osonlashtirish uchun kiritilishi kerak bo'lgan o'zgarishlarni taklif qilishlari mumkin. Tizim ishlab chiquvchilarning o'zlari tizimga qo'shilishi mumkin bo'lgan yangi xususiyatlar haqida yaxshi fikrlarga ega bo'lishi mumkin.
25.14-rasmda ko'rsatilgan o'zgartirish so'rovi jarayoni tizim mijozlarga chiqarilgandan so'ng boshlanadi. Rivojlanish jarayonida tizimning yangi versiyalari kundalik (yoki tez-tez) tizimni qurish orqali yaratilganda, rasmiy o'zgarishlarni boshqarish jarayoniga ehtiyoj qolmaydi. Muammolar va so'ralgan o'zgartirishlar muammolarni kuzatish tizimida qayd etiladi va kundalik yig'ilishlarda muhokama qilinadi. Faqatgina alohida komponentlarga ta'sir qiladigan o'zgarishlar to'g'ridan-to'g'ri tizim ishlab chiqaruvchisiga uzatiladi, u ularni qabul qiladi yoki nima uchun talab qilinmasligini ko'rsatadi. Biroq, tizim arxitektori kabi mustaqil vakolatli organ turli ishlab chiqish guruhlari tomonidan ishlab chiqarilgan tizim modullarini kesib o'tgan o'zgarishlarni baholashi va birinchi o'ringa qo'yishi kerak.
Ba'zi tezkor usullarda mijozlar o'zgarishlarni amalga oshirish kerakmi yoki yo'qligini hal qilishda bevosita ishtirok etadilar. Tizim talablariga o'zgartirish kiritishni taklif qilganda, ular ushbu o'zgarishlarning ta'sirini baholash uchun jamoa bilan ishlaydi va keyin o'zgartirish tizimning keyingi o'sishi uchun rejalashtirilgan xususiyatlardan ustun bo'lishi kerakmi yoki yo'qligini hal qiladi. Biroq, dasturiy ta'minotni takomillashtirish bilan bog'liq o'zgarishlar tizimda ishlaydigan dasturchilarning ixtiyorida qoladi. Dasturiy ta'minot doimiy ravishda takomillashtiriladigan refaktoring qo'shimcha xarajatlar sifatida emas, balki ishlab chiqish jarayonining zaruriy qismi sifatida qaraladi.
Ishlab chiqish guruhi dasturiy ta'minot komponentlarini o'zgartirganda, ular har bir komponentga kiritilgan o'zgarishlarni qayd etishlari kerak. Bu ba'zan komponentning hosila tarixi deb ataladi. Derivatsiya tarixini saqlashning yaxshi usuli komponent manba kodining boshida standartlashtirilgan izohda (25.16-rasm). Ushbu sharh dasturiy ta'minotni o'zgartirishga turtki bo'lgan o'zgartirish so'roviga havola qilishi kerak. Ushbu sharhlar hosila tarixi uchun barcha komponentlarni skanerlaydigan skriptlar orqali qayta ishlanishi va keyin komponent o'zgarishi hisobotlarini yaratishi mumkin. Hujjatlar uchun har bir versiyaga kiritilgan o'zgartirishlar yozuvlari odatda hujjatning old qismidagi alohida sahifada saqlanadi. Men buni hujjatlar bo'yicha veb-bo'limda muhokama qilaman (30-bob).

8.4 Chiqarish boshqaruv
Tizim relizi - mijozlarga tarqatiladigan dasturiy ta'minot tizimining versiyasi. Ommaviy bozor dasturiy ta'minoti uchun odatda ikki turdagi nashrlarni aniqlash mumkin: muhim yangi funksiyalarni taqdim etadigan asosiy relizlar va xatolarni tuzatuvchi va mijozlarning xabar qilingan muammolarini tuzatuvchi kichik relizlar. Misol uchun, ushbu kitob operatsion tizimi OS 10.9.2 bo'lgan Apple Mac kompyuterida yozilmoqda. Bu OS 10 ning 9-versiyasining 2-kichik versiyasini bildiradi. Asosiy relizlar dasturiy ta'minot sotuvchisi uchun iqtisodiy jihatdan juda muhim, chunki mijozlar odatda ular uchun pul to'lashlari kerak. Kichik relizlar bor odatda tarqatilgan ozod ning zaryad .
Dasturiy ta'minot mahsulotining chiqarilishi faqat tizimning bajariladigan kodi emas. Chiqarish shuningdek quyidagilarni o'z ichiga olishi mumkin:
■ alohida o'rnatishlar uchun versiya qanday sozlanishi kerakligini belgilovchi konfiguratsiya fayllari;
■ tizimning muvaffaqiyatli ishlashi uchun zarur bo'lgan turli tillardagi xato xabarlari fayllari kabi ma'lumotlar fayllari;
■ tizimni maqsadli uskunaga o'rnatishga yordam beradigan o'rnatish dasturi;
■ tizimni tavsiflovchi elektron va qog'oz hujjatlar;
■ o'sha nashr uchun mo'ljallangan qadoqlash va tegishli reklama.
Ommaviy bozor mahsulotlari uchun tizim nashrini tayyorlash va tarqatish qimmat jarayondir. Relizlar tarqatilishini yaratish bilan bog'liq texnik ishlardan tashqari, reklama va reklama materiallarini tayyorlash kerak. Marketing strategiyalari mijozlarni tizimning yangi versiyasini sotib olishga ishontirish uchun ishlab chiqilishi kerak. Bo'shatish vaqtini diqqat bilan o'ylash kerak. Agar relizlar juda tez-tez bo'lsa yoki uskunani yangilashni talab qilsa, mijozlar yangi versiyaga o'tmasligi mumkin, ayniqsa buning uchun pul to'lash kerak bo'lsa. Tizim relizlari kamdan-kam bo'lsa, mijozlar muqobil tizimlarga o'tishlari sababli bozor ulushi yo'qolishi mumkin.
Dasturiy mahsulotning yangi versiyasini qachon chiqarish to'g'risida qaror qabul qilishda e'tiborga olish kerak bo'lgan turli xil texnik va tashkiliy omillar 25.17-rasmda ko'rsatilgan.

Faktor	Tavsif
Musobaqa	Ommaviy bozor dasturiy ta'minoti uchun tizimning yangi versiyasini chiqarish zarur bo'lishi mumkin, chunki raqobatdosh mahsulot yangi xususiyatlarni taqdim etgan va agar ular mavjud mijozlarga taqdim etilmasa, bozor ulushi yo'qolishi mumkin.
Marketing talablari	Tashkilotning marketing bo'limi nashrlarni ma'lum bir sanada taqdim etish majburiyatini olgan bo'lishi mumkin. Marketing sabablariga ko'ra, foydalanuvchilarni avvalgi versiyadan yangilashga ko'ndirishlari uchun tizimga yangi xususiyatlarni kiritish kerak bo'lishi mumkin.
Platforma o'zgarishi	Operatsion tizim platformasining yangi versiyasi chiqarilganda dasturiy ta'minot ilovasining yangi versiyasini yaratishingiz kerak bo'lishi mumkin.
Tizimning texnik sifati	Agar ko'plab mijozlar tizimdan foydalanishiga ta'sir qiladigan jiddiy tizim nosozliklari haqida xabar berilsa, ularni yangi tizim nashrida tuzatish kerak bo'lishi mumkin. Kichkina tizim nosozliklari tizimning joriy versiyasiga qo'llanilishi mumkin bo'lgan Internet orqali tarqatilgan yamoqlarni chiqarish orqali tuzatilishi mumkin.

25.17-rasm Tizim chiqarishni rejalashtirishga ta'sir etuvchi omillar
Relizni yaratish - bu tizim relizining barcha komponentlarini o'z ichiga olgan fayllar va hujjatlar to'plamini yaratish jarayoni. Bu jarayon bir necha bosqichlarni o'z ichiga oladi:
1. Dasturlarning bajariladigan kodi va barcha bog'langan ma'lumotlar fayllari versiyalarni boshqarish tizimida aniqlanishi va reliz identifikatori bilan belgilanishi kerak.
2. Konfiguratsiya tavsiflari turli apparat va operatsion tizimlar uchun yozilishi kerak bo'lishi mumkin.
3. O'z tizimlarini sozlashi kerak bo'lgan mijozlar uchun yangilangan ko'rsatmalar yozilishi kerak bo'lishi mumkin.
4. O'rnatish dasturi uchun skriptlarni yozish kerak bo'lishi mumkin.
5. Tizim hujjatlariga havolalar bilan nashrni tavsiflovchi veb-sahifalar yaratilishi kerak.
6. Nihoyat, barcha ma'lumotlar mavjud bo'lganda, dasturiy ta'minotning bajariladigan asosiy tasviri tayyorlanishi va mijozlarga yoki savdo nuqtalariga tarqatish uchun topshirilishi kerak.
Maxsus dasturiy ta'minot yoki dasturiy mahsulotlar liniyalari uchun tizimni chiqarishni boshqarish jarayonining murakkabligi tizim mijozlari soniga bog'liq. Har bir mijoz uchun tizimning maxsus nashrlarini ishlab chiqarish kerak bo'lishi mumkin. Individual mijozlar bir vaqtning o'zida turli xil apparat qurilmalarida tizimning bir nechta turli versiyalarini ishga tushirishlari mumkin. Agar dasturiy ta'minot murakkab tizimlar tizimining bir qismi bo'lsa , alohida tizimlarning bir nechta turli xil variantlarini yaratish kerak bo'lishi mumkin. Misol uchun, ixtisoslashtirilgan yong'inga qarshi vositalarda har bir turdagi transport vositalarida ushbu transport vositasidagi jihozlarga moslashtirilgan dasturiy ta'minot tizimining o'z versiyasi bo'lishi mumkin.
Dasturiy ta'minot kompaniyasi o'z dasturiy ta'minotining o'nlab yoki hatto yuzlab turli xil nashrlarini boshqarishi kerak bo'lishi mumkin. Ularning konfiguratsiyani boshqarish tizimlari va jarayonlari qaysi mijozlar tizimning qaysi relizlariga ega ekanligi va relizlar va tizim versiyalari o'rtasidagi bog'liqlik haqida ma'lumot berishga mo'ljallangan bo'lishi kerak. Yetkazib berilgan tizim bilan bog'liq muammo yuzaga kelsa, siz ushbu tizimda ishlatiladigan barcha komponent versiyalarini tiklashingiz kerak.
Shuning uchun, tizim relizi ishlab chiqarilganda, uni kelajakda aynan qayta yaratish mumkinligini ta'minlash uchun hujjatlashtirilishi kerak. Bu, ayniqsa, harbiy tizimlar va murakkab mashinalarni boshqaradigan tizimlar kabi moslashtirilgan, uzoq umr ko'radigan o'rnatilgan tizimlar uchun juda muhimdir. Ushbu tizimlar uzoq umr ko'rishi mumkin - ba'zi hollarda 30 yil. Mijozlar ko'p yillar davomida ushbu tizimlarning bitta versiyasidan foydalanishlari mumkin va u almashtirilgandan keyin ko'p vaqt o'tgach, ushbu versiyaga maxsus o'zgartirishlar talab qilishi mumkin.
Chiqarishni hujjatlashtirish uchun siz bajariladigan kodni yaratishda foydalanilgan manba kodi komponentlarining maxsus versiyalarini yozib olishingiz kerak. Siz manba kodi fayllari, tegishli bajariladigan fayllar va barcha ma'lumotlar va konfiguratsiya fayllari nusxalarini saqlashingiz kerak. Eski operatsion tizimlar va boshqa qo'llab-quvvatlovchi dasturlarning nusxalarini saqlash kerak bo'lishi mumkin, chunki ular hali ham operatsion foydalanishda bo'lishi mumkin. Yaxshiyamki, bu endi eski uskuna har doim saqlanishi kerak degani emas. Eski operatsion tizimlar virtual mashinada ishlashi mumkin.
Shuningdek, dasturiy ta'minotni yaratishda foydalanilgan operatsion tizim versiyalari, kutubxonalar, kompilyatorlar va boshqa vositalarni yozib olishingiz kerak. Keyinchalik bir xil tizimni yaratish uchun ushbu vositalar talab qilinishi mumkin. Shunga ko'ra, platforma dasturiy ta'minotining nusxalarini va tizimni yaratishda foydalaniladigan vositalarni maqsadli tizimning manba kodi bilan birga versiyani boshqarish tizimida saqlashingiz kerak bo'lishi mumkin.
Yangi tizim relizlarini o'rnatishni rejalashtirayotganda, mijozlar har doim yangi tizim relizlarini o'rnatadi deb o'ylay olmaysiz. Ba'zi tizim foydalanuvchilari mavjud tizimdan mamnun bo'lishlari mumkin va yangi versiyaga o'tish xarajatlarini o'zlashtirmasliklari mumkin. Tizimning yangi versiyalari oldingi versiyalarni o'rnatishga tayanishi mumkin emas. Ushbu muammoni tasvirlash uchun quyidagi stsenariyni ko'rib chiqing:
1. Tizimning 1-relizi tarqatiladi va foydalanishga topshiriladi.
2. 2-reliz yangi ma'lumotlar fayllarini o'rnatishni talab qiladi, ammo ba'zi mijozlar 2-chiqarish vositalariga muhtoj emas va shuning uchun 1-chiqarishda qoladi.
3. 3-versiya 2-chi versiyada o'rnatilgan ma'lumotlar fayllarini talab qiladi va o'ziga xos yangi ma'lumotlar fayllariga ega emas.
Dasturiy ta'minot distribyutori 3-chiqarish uchun zarur bo'lgan fayllar allaqachon barcha saytlarda o'rnatilgan deb taxmin qila olmaydi. Ba'zi saytlar to'g'ridan-to'g'ri 1-nashrdan 3-nashrga o'tishi mumkin, 2-nashrni o'tkazib yuborishi mumkin. Ba'zi saytlar mahalliy sharoitlarni aks ettirish uchun 2-nashr bilan bog'liq ma'lumotlar fayllarini o'zgartirgan bo'lishi mumkin. Shuning uchun ma'lumotlar fayllari tizimning 3-versiyasi bilan tarqatilishi va o'rnatilishi kerak.
Dasturiy ta'minotni xizmat (SaaS) sifatida taqdim etishning afzalliklaridan biri shundaki, u ushbu muammolarning barchasidan qochadi. Bu mijozlar uchun relizlarni boshqarish va tizimni o'rnatishni soddalashtiradi. Dasturiy ta'minot ishlab chiqaruvchisi tizimning mavjud versiyasini bir vaqtning o'zida barcha mijozlarga taqdim etiladigan yangi reliz bilan almashtirish uchun javobgardir. Biroq, bu yondashuv xizmatlarni ishga tushiradigan barcha serverlar bir vaqtning o'zida yangilanishini talab qiladi. Server yangilanishlarini qo'llab-quvvatlash uchun yangi dasturiy ta'minotni serverlarga "itarish" uchun qo'g'irchoq ( Loope 2011) kabi tarqatish boshqaruvining maxsus vositalari ishlab chiqilgan.

Download 4,12 Mb.