Odoo.sh: branch, build, staging va production qanday ishlaydi

Ishchi bazaga yangi maydon qoʻshmoqchisiz. Uni toʻgʻridan-toʻgʻri sinab koʻrsangiz, xato chiqqanda buni birinchi boʻlib mijozlaringiz va xodimlaringiz koʻradi. Kod bilan ishlaydigan jamoalar uchun Odoo shu muammoga alohida javob bergan: Odoo.sh. Hujjat uni Odoo ilovalarini joylashtirish va boshqarish uchun rasmiy bulut platformasi deb ataydi va uning imkoniyatlari qatorida veb-terminal, modullar bogʻliqligi, uzluksiz sinov va SSH orqali kirishni sanaydi. Platformaning oʻz sahifasi esa uni dasturchilarga qaratilgan, Git branchlariga qurilgan muhit deb tanishtiradi.

Uch qism va uch xil odam

Odoo.sh bir narsa emas, uchta narsaning birikmasi. Birinchisi — GitHub dagi kod ombori, yaʼni dasturlar saqlanadigan va har oʻzgarishi yozib boriladigan joy. Ikkinchisi — Odoo.sh loyihasi, GitHub bilan ulanadigan platforma, u zaxira nusxa, staging muhitlari va uzluksiz sinovni beradi. Uchinchisi — Odoo bazasi, yaʼni kundalik maʼlumotlarning oʻzi.

Shu uch qismga uch xil odam toʻgʻri keladi. GitHub foydalanuvchilari omborga kira oladigan dasturchilar, Odoo.sh hamkorlari esa loyihani boshqaradigan odamlar, ularning har biri GitHub foydalanuvchisiga bogʻlangan boʻlishi shart. Baza foydalanuvchilari tayyor tizimda ishlaydigan xodimlar, loyihani boshqarishga ularning aloqasi yoʻq. Yaʼni omborga kirish odamni loyiha hamkoriga aylantirmaydi.

Hamkorlarning huquqi uch rolga boʻlingan:

• Admin: hamma narsaga ega va loyiha sozlamalariga yagona kira oladi.
• Tester: staging va development bazalariga, ularning asboblariga kira oladi, lekin Odoo.sh asboblari orqali ishchi bazaga kira olmaydi. Bu rol qabul sinovini oʻtkazuvchilar uchun.
• Dasturchi: ishchi va staging bazalarga kirmaydi, veb-terminal va server jurnalini koʻrmaydi. Bu kod yozadigan, lekin mijoz maʼlumotini koʻrmasligi kerak boʻlgan odam uchun.

Bu boʻlinish oddiy qoidani amalga oshiradi: kodni yozadigan odam ishchi maʼlumotni koʻrishi shart emas. Sinovchi esa ishchi bazaning nusxasida ishlaydi, ishchi bazaning oʻzida emas.

Development, staging, production: uch bosqich

Har branch, yaʼni kod tarmogʻi, uch bosqichdan birida turadi. Bosqichni oʻzgartirish uchun branchni sichqoncha bilan boshqa bosqichga sudrash kifoya. Production da faqat bitta branch boʻladi. Quyidagi jadval uch bosqichni yonma-yon qoʻyadi.

Development da demo maʼlumot yuklanadi va test toʻplami ishga tushadi, test yiqilsa esa build muvaffaqiyatsiz deb hisoblanadi. Toʻliq toʻplamda barcha standart modullarni oʻrnatish bir soatgacha choʻzilishi mumkin. Development bazasi taxminan uch kun yashaydi, undan keyin ogohlantirishsiz oʻchirilishi mumkin.

Staging boshqacha. U ishchi bazaning nusxasini oladi, shuning uchun sinov haqiqiy maʼlumotda oʻtadi, lekin nusxa neytrallanadi, yaʼni xavfli funksiyalar oʻchiriladi. Hujjatga koʻra, neytrallash rejalashtirilgan harakatlarni, chiquvchi xatlarni va tashqi xizmatlarga ulanishni oʻchiradi, toʻlov provayderlari va yetkazib berish ulagichlarini esa test rejimiga oʻtkazadi. Chiquvchi xatlar oʻrniga xat ushlagich turadi: u bazadan qanday xatlar ketishini koʻrsatadi, mijozga esa hech narsa bormaydi. Testlar staging da ishlamaydi, chunki ular demo maʼlumotga tayanadi, staging bazasida esa demo maʼlumot yoʻq.

Production dagi har yangi commit serverni yangi kod bilan qayta ishga tushiradi. Production da demo maʼlumot yuklanmaydi va testlar ishlamaydi, chunki bu bazani uzoqroq oʻchirib qoʻyardi. Agar oʻzgarish modulni yangilashni talab qilsa, modul versiyasi raqamini oshirish kifoya: platforma yangilashni oʻzi bajaradi, shu vaqtda esa baza vaqtincha ishlamaydi.

Build: har oʻzgarishga alohida sinov

Build — oʻzgarish yuborilganda platforma yigʻadigan ishchi nusxa. Aniqrogʻi, build — Odoo serveri kodingizning maʼlum bir versiyasi bilan yuklagan baza, uning maqsadi esa shu versiya serverda, bazada va funksiyalarda toʻgʻri ishlashini sinash. Koʻp build GitHub dagi branchga yangi kod yuborilganda yaratiladi, qoʻlda qayta yigʻdirish yoki bazani import qilish ham yangi build beradi.

Build uch xil rangda koʻrinadi:

• Yashil: yaratishda xato ham, ogohlantirish ham boʻlmagan.
• Sariq: ogohlantirish bor, lekin xato yoʻq.
• Qizil: yaratishda xato boʻlgan.

Production da bu ranglarning maʼnosi muhimroq: yangi build muvaffaqiyatli yoki deyarli muvaffaqiyatli boʻlsa, ishchi baza shu kod bilan ishlaydi, qizil boʻlsa esa baza oldingi muvaffaqiyatli build bilan ishlashda davom etadi. Yaʼni xatoli kod mijozga koʻrinmasdan toʻxtatiladi.

Modul yangilanishi paytida xato chiqsa, platforma serverni oldingi kod versiyasiga qaytaradi va bazani avvalgi holatiga tiklaydi, xatoning jurnalini esa koʻrib chiqish mumkin. Bu platformaning eng foydali himoyalaridan biri: ishchi bazada yarim yangilangan holat qolmaydi.

Gipotetik oqim. Jamoa hisob-fakturaga yangi maydon qoʻshmoqchi.

1. Dasturchi development branch ochib, kodni yozadi va GitHub ga yuboradi.
2. Platforma noldan baza yaratib, testlarni ishga tushiradi; test oʻtmasa, build qizil boʻladi.
3. Branch staging ga koʻchiriladi; platforma ishchi bazaning neytrallangan nusxasini yaratadi.
4. Tester nusxada hisob-fakturalarni sinaydi, xat ham, toʻlov ham tashqariga chiqmaydi.
5. Staging production branchga qoʻshiladi; server qayta ishga tushadi, xato boʻlsa oldingi holatga qaytadi.

Staging dagi sozlama production ga oʻtmaydi

Bu eng koʻp yoʻl qoʻyiladigan xato. Staging branchni production ga qoʻshganda faqat kod oʻtadi, staging bazasidagi oʻzgarishlar esa, masalan siz qoʻlda oʻzgartirgan sozlama yoki koʻrinish, ishchi bazaga oʻtmaydi. Staging bazasi keyingi build da ishchi bazadan yangidan nusxalanadi, shuning uchun u yerda qilingan sozlama yoʻqoladi.

Hujjat ikki chiqish yoʻlini beradi. Birinchisi — sozlamani modul ichiga XML maʼlumot fayli sifatida yozib, modul versiyasini oshirish: qoʻshilganda platforma yangilashni oʻzi bajaradi. Ikkinchisi — sozlamani qoʻlda ishchi bazaga takrorlash. Hujjat birinchi yoʻlni tavsiya etadi, chunki oʻzgarish Git tarixida qoladi va kimning nima oʻzgartirgani koʻrinadi.

Staging haqidagi ikki sahifa bir-biriga ozgina mos kelmaydi. Builds sahifasi har gal yangi nusxa olinadi deydi, branch sozlamalari sahifasi esa sukut boʻyicha staging oldingi buildni yangilaydi, yangi nusxa faqat «New build» tanlansa olinadi deydi. Aniq xulq-atvor uchun branchning oʻz sozlamalarini tekshirish maʼqul.

Kuzatuv: monitor va jurnallar

Branch sahifasida kuzatuv asboblari ham bor. Monitor boʻlimi xotira va protsessor sarfini, saqlash hajmini, soniyadagi soʻrovlar sonini va oʻrtacha javob vaqtini grafiklarda koʻrsatadi. Jurnallar boʻlimi server jurnalini, modullar oʻrnatilishi va yangilanishi jurnallarini real vaqtda koʻrsatadi, toʻxtatilmasa besh daqiqadan keyin oʻzi toʻxtaydi. Texnik jurnallar vaqtni UTC boʻyicha yozadi, shuning uchun grafiklarni solishtirishda ham, yordam soʻrovida ham UTC ni tanlash kerak.

Zaxira nusxa: nima, qancha va qayerda

Production bazasi har kuni avtomatik zaxiralanadi, yetti kunlik, toʻrt haftalik va uch oylik nusxalar saqlanadi. Hisoblasak, 7 + 4 + 3 bir vaqtda 14 tagacha nusxa beradi. Har nusxaga bazaning dampi, fayl ombori, jurnallar va sessiyalar kiradi.

Lekin hammasi ham oldingizda turmaydi. Production serverida faqat bir oylik nusxa, yaʼni yetti kunlik va toʻrt haftalik, turadi. Qolgan uch oylik nusxalar alohida zaxira serverlarida saqlanadi va ularni tiklash yoki yuklab olish uchun Odoo yordamiga murojaat qilish kerak. Staging va development bazalari avtomatik zaxiralanmaydi, staging va production uchun esa qoʻlda zaxira olish mumkin: u uch kun saqlanadi, kuniga beshtadan koʻp emas. Development uchun qoʻlda zaxira ham yoʻq.

Modul versiyasi yoki Python bogʻliqliklari oʻzgargan commit production ga qoʻshilsa, platforma oʻzi «Update» turidagi zaxira oladi, chunki bunda server yoki baza oʻzgaradi. Versiya oʻzgarmasa, zaxira olinmaydi, shuning uchun muhim oʻzgarishdan oldin qoʻlda nusxa olish ehtiyotkorlik hisoblanadi.

Odoo Online dan farqi va kirish shartlari

Asosiy farq maxsus kod. Odoo Online maxsus modullar va Apps Store modullari bilan mos emas. Odoo.sh da esa jamoa va maxsus modullar branchga qoʻshiladi, platforma modul joylashgan papkalarni oʻzi topadi. Shuning uchun kodli sozlamaga muhtoj kompaniya Online ni emas, Odoo.sh ni tanlaydi.

Boshlash uchun shartlar bor. Avvalo GitHub hisobi kerak, loyiha ochilganda esa Odoo asosiy versiyasi tanlanadi, chunki Odoo.sh oraliq versiyalarni qoʻllab-quvvatlamaydi. Odoo Enterprise obunasining Odoo.sh ni oʻz ichiga olgan kodi kiritiladi, hosting joylashuvi tanlanadi. Bir obuna uchun bitta faol baza ruxsat etiladi, import qilingan baza esa obunaga bogʻlanmaguncha nusxa hisoblanadi.

Mavjud bazani import qilishda hajm masalasi bor: hujjatga koʻra, import dump hajmidan toʻrt baravar koʻp boʻsh joy talab qiladi, yaʼni 10 GB lik dump uchun kamida 40 GB kerak. Chiquvchi pochta uchun 25-port yopiq, tashqi serverga 465 yoki 587-port orqali ulanish kerak.

Yangilash ham boshqacha yuritiladi: Odoo.sh da dastlabki uch yillik qoʻllab-quvvatlashdan keyin yangilashni tugatish uchun yana ikki yil beriladi. Yangilash paytida ishchi bazaning oxirgi kunlik zaxirasi yangilash platformasiga yuboriladi, branch esa maxsus rejimga oʻtadi: har yangi commit yangilangan zaxirani tiklaydi va maxsus modullarni yangidan oʻrnatadi. Shunda kodingizni toza yangilangan nusxada sinash mumkin, ishchi bazani yangilash esa branchga yangi commit tushgan zahoti boshlanadi. Xato boʻlsa, platforma yangilashni oʻzi qaytaradi, muvaffaqiyatli boʻlsa yangilashdan oldingi zaxira saqlanadi.

Amalda nima qilish mumkin

Hujjatdan chiqarilgan tahririyat fikri:

• Sozlamani staging da qoʻlda emas, modul ichidagi XML fayl sifatida yozing va versiyani oshiring, aks holda u ishchi bazaga oʻtmaydi.
• Sinovchilarga Tester, dasturchilarga Developer rolini bering; ishchi bazaga kirish faqat Admin da qolsin.
• Muhim production oʻzgarishidan oldin qoʻlda zaxira oling va uning uch kun saqlanishini hisobga oling.
• Uch oylik zaxira kerak boʻlishi mumkin boʻlsa, uni Odoo yordami orqali tiklash muddatini oldindan hisobga oling.
• Loyihani oraliq emas, asosiy versiyadan boshlang: Odoo.sh oraliq versiyalarni qabul qilmaydi.