Өмнө нь хэзээ ч ийм зүйл тохиолдож байгаагүй бөгөөд бид дахин ирлээ!
Дараагийн төсөл дээрээ бид ирээдүйд асуудал гарахгүйн тулд Liquibase-ийг эхнээс нь ашиглахаар шийдсэн. Үүнээс харахад багийн залуу гишүүд бүгд үүнийг хэрхэн зөв ашиглахаа мэддэггүй. Би дотоод семинар зохион байгуулж, дараа нь нийтлэл болгохоор шийдсэн.
Өгүүлэлд хэрэгтэй зөвлөмжүүд болон харилцааны мэдээллийн санг шилжүүлэх хэрэгслүүд, ялангуяа Liquibase-тай ажиллахад тулгарч болох хамгийн тод гурван бэрхшээлийн тайлбарыг багтаасан болно. Бага болон дунд түвшний Java хөгжүүлэгчдэд зориулагдсан; илүү туршлагатай хөгжүүлэгчдийн хувьд энэ нь аль хэдийн мэдэгдэж байсан зүйлийг бүтэцжүүлэх, давтах сонирхолтой байж магадгүй юм.
Liquibase болон Flyway нь Java ертөнц дэх харилцааны бүтцийн хувилбарын хяналтын асуудлыг шийдвэрлэх гол өрсөлдөгч технологи юм. Эхнийх нь бүрэн үнэ төлбөргүй бөгөөд практик дээр үүнийг ихэвчлэн ашиглахаар сонгодог тул Liquibase-ийг хэвлэлийн баатараар сонгосон юм. Гэсэн хэдий ч, тайлбарласан зарим практик нь таны хэрэглээний архитектураас хамааран бүх нийтийнх байж болно.
Харилцааны бүтцийн шилжилт нь харилцааны мэдээллийн сангийн сул уян хатан байдлыг шийдвэрлэх албадан арга юм. OOP загварын эрин үед мэдээллийн сантай ажиллах хэв маяг нь бид схемийг нэг удаа дүрсэлж, дахин хөндөхгүй гэсэн үг юм. Гэвч бодит байдал нь үргэлж бүх зүйл өөрчлөгдөж, хүснэгтийн бүтцийг өөрчлөх шаардлагатай байдаг. Мэдээжийн хэрэг, үйл явц нь өөрөө өвдөлт, тааламжгүй байж болно.
Би таны төсөлд номын сан нэмэх технологийн тодорхойлолт, зааварчилгааг илүү гүнзгийрүүлэхгүй; энэ сэдвээр нэлээд хэдэн нийтлэл бичсэн:
Нэмж дурдахад ашигтай зөвлөмжүүдийн сэдвээр маш сайн нийтлэл аль хэдийн гарсан байна.
Зөвлөмж
Шилжилт хөдөлгөөнтэй холбоотой асуудлыг шийдэхийн тулд хөлс, цус, өвдөлтөөр төрсөн зөвлөгөө, сэтгэгдлээ хуваалцмаар байна.
1. Ажил эхлэхийн өмнө та шилдэг туршлагын хэсэгтэй танилцах хэрэгтэй Ликвибаза
Энгийн боловч маш чухал зүйлсийг дүрсэлсэн бөгөөд үүнгүйгээр номын сан ашиглах нь таны амьдралыг улам хүндрүүлдэг. Жишээлбэл, өөрчлөлтийн багцыг удирдах бүтэцгүй хандлага нь эрт орой хэзээ нэгэн цагт төөрөгдөл, эвдэрсэн шилжилт хөдөлгөөнд хүргэдэг. Хэрэв та өгөгдлийн сангийн бүтэц, үйлчилгээний логикт харилцан хамааралтай өөрчлөлтүүдийг нэгэн зэрэг хийхгүй бол энэ нь улаан тест эсвэл эвдэрсэн орчинд хүргэх магадлал өндөр байна. Нэмж дурдахад, Liquibase-ийг албан ёсны вэбсайт дээр ашиглах зөвлөмжүүд нь үндсэн шилжих скриптүүдийн хамт буцаах скриптүүдийг боловсруулах, турших тухай заалтыг агуулдаг. За, нийтлэлд Шилжилт хөдөлгөөн болон буцаах механизмтай холбоотой кодын жишээнүүд байдаг.
2. Хэрэв та шилжих хэрэгслийг ашиглаж эхэлбэл мэдээллийн сангийн бүтцэд гараар засвар оруулахыг бүү зөвшөөр
"Нэг удаа Персил бол дандаа Персил" гэдэг үг байдаг. Хэрэв таны програмын суурийг Liquibase удирдаж эхэлбэл аливаа гарын авлагын өөрчлөлт нь нэн даруй нийцэхгүй байдалд хүргэж, өөрчлөлтийн багцад итгэх итгэлийн түвшин тэг болно. Болзошгүй эрсдэлд мэдээллийн санг сэргээхэд зарцуулсан хэдэн цаг орно; хамгийн муу тохиолдолд үхсэн сервер. Хэрэв та өөрийн багт "хуучин сургуулийн" DBA архитектортой бол нөхцөлт SQL хөгжүүлэгчийн өөрийн ойлголтын дагуу мэдээллийн санг зүгээр л засварлавал ямар муу зүйл болохыг тэвчээртэй, тунгаан бодож тайлбарла.
3. Хэрэв өөрчлөлтийн багцыг репозитор руу оруулсан бол засварлахаас зайлсхий
Хэрэв өөр хөгжүүлэгч таталт хийж, дараа нь засварлах өөрчлөлтийн багцыг хэрэглэвэл програмыг эхлүүлэх үед алдаа гарахад тэр таныг эелдэг үгээр санах нь гарцаагүй. Хэрэв өөрчлөлтийн багцыг засварлах нь хөгжилд ямар нэгэн байдлаар урсах юм бол та засварын гулгамтгай налууг дагах хэрэгтэй болно. Асуудлын мөн чанар нь Liquibase-ийн үндсэн механизм болох хэш нийлбэрээр өөрчлөлтийг баталгаажуулахад оршино. Өөрчлөлтийн кодыг засварлах үед хэшийн хэмжээ өөрчлөгдөнө. Өгөгдлийн санг бүхэлд нь эхнээс нь өгөгдөл алдалгүйгээр ашиглах боломжтой үед л өөрчлөлтийн багцыг засварлах боломжтой. Энэ тохиолдолд SQL эсвэл XML кодыг дахин засварлах нь эсрэгээрээ амьдралыг хөнгөвчлөх, шилжих хөдөлгөөнийг уншихад хялбар болгож чадна. Жишээ нь, програмын эхэнд эх сурвалжийн мэдээллийн сангийн схемийг баг дотроо тохиролцсон нөхцөл байдал байж болно.
4. Боломжтой бол өгөгдлийн сангийн баталгаажуулсан нөөцлөлттэй байх
Энд бүх зүйл тодорхой байна гэж би бодож байна. Хэрэв гэнэт шилжилт хөдөлгөөн амжилтгүй болсон бол бүх зүйлийг буцааж болно. Liquibase нь өөрчлөлтийг буцаах хэрэгсэлтэй боловч буцаах скриптүүдийг мөн хөгжүүлэгч өөрөө бичдэг бөгөөд тэдгээр нь үндсэн өөрчлөлтийн багцын скрипттэй ижил магадлалтай асуудалтай байж болно. Энэ нь ямар ч тохиолдолд нөөцлөлтөөр аюулгүй тоглох нь ашигтай гэсэн үг юм.
5. Боломжтой бол хөгжүүлэлтийн явцад батлагдсан мэдээллийн сангийн нөөцлөлтийг ашигла
Хэрэв энэ нь гэрээ, нууцлалтай зөрчилдөхгүй бол мэдээллийн санд хувийн мэдээлэл байхгүй бөгөөд энэ нь хоёр нарны жинтэй биш - үүнийг шууд шилжилтийн сервер дээр ашиглахаасаа өмнө хөгжүүлэгчийн машин дээр хэрхэн ажиллахыг шалгаж, тооцоолж болно. шилжилт хөдөлгөөний үед гарч болзошгүй асуудлуудын бараг 100%.
6. Багийн бусад хөгжүүлэгчидтэй харилцах
Сайн зохион байгуулалттай хөгжлийн явцад багийн гишүүд хэн юу хийж байгааг мэддэг. Бодит байдал дээр энэ нь ихэвчлэн тийм биш байдаг тул хэрэв та даалгаврынхаа нэг хэсэг болгон мэдээллийн сангийн бүтцэд өөрчлөлт оруулахаар бэлтгэж байгаа бол энэ талаар бүхэл бүтэн багт нэмэлт мэдэгдэхийг зөвлөж байна. Хэрэв хэн нэгэн зэрэг өөрчлөлт хийж байгаа бол та анхааралтай зохион байгуулах хэрэгтэй. Зөвхөн эхэнд нь биш, ажил дууссаны дараа хамт ажиллагсадтайгаа харилцах нь зүйтэй. Өөрчлөлтийн багцтай холбоотой гарч болзошгүй олон асуудлыг кодыг шалгах үе шатанд шийдэж болно.
7. Юу хийж байгаагаа бод!
Энэ нь ямар ч нөхцөл байдалд тохирсон ойлгомжтой зөвлөгөө юм шиг санагдаж байна. Гэсэн хэдий ч, хэрэв хөгжүүлэгч өөрийн хийж байгаа зүйл болон энэ нь юу нөлөөлж болох талаар дахин дүн шинжилгээ хийсэн бол олон асуудлаас зайлсхийх боломжтой байсан. Шилжилт хөдөлгөөнтэй ажиллах нь үргэлж нэмэлт анхаарал, нарийвчлал шаарддаг.
Урхи
Хэрэв та дээрх зөвлөмжийг дагаж мөрдөхгүй бол ямар ердийн урхинд орж болохыг харцгаая, яг юу хийх ёстой вэ?
Нөхцөл байдал 1: Хоёр хөгжүүлэгчид нэгэн зэрэг шинэ өөрчлөлтийн багц нэмэхийг оролдож байна
Вася, Петя нар бие биенийхээ талаар мэдэхгүй байж өөрчлөлтийн 4-р хувилбарыг бүтээхийг хүсч байна. Тэд өгөгдлийн сангийн бүтцэд өөрчлөлт оруулж, өөр өөр өөрчлөлтийн файлуудыг татах хүсэлт гаргасан. Дараахь үйл ажиллагааны механизмыг санал болгож байна.
Хэрхэн шийдэх вэ
- Ямар нэгэн байдлаар хамт ажиллагсад нь өөрчлөлтийн багцыг ямар дарааллаар хийх талаар тохиролцох ёстой, жишээлбэл, Петинийг эхлээд хэрэглэх ёстой.
- Хэн нэгэн нь хоёр дахь нэгийг нь өөртөө нэмж, Васягийн өөрчлөлтийн багцыг 5-р хувилбараар тэмдэглэх хэрэгтэй. Үүнийг Cherry Pick эсвэл цэвэрхэн нэгтгэх замаар хийж болно.
- Өөрчлөлт хийсний дараа та хийсэн үйлдлийн хүчинтэй эсэхийг шалгах хэрэгтэй.
Үнэн хэрэгтээ, Liquibase механизмууд нь репозиторт 4-р хувилбарын хоёр өөрчлөлт оруулах боломжийг танд олгоно, ингэснээр та бүгдийг байгаагаар нь үлдээж болно. Өөрөөр хэлбэл, та 4-р хувилбарт өөр өөр нэртэй хоёр өөрчлөлт хийх болно. Энэ аргын тусламжтайгаар өгөгдлийн сангийн хувилбаруудыг удирдахад дараа нь маш хэцүү болно.
Үүнээс гадна Liquibase нь хоббитуудын гэр шиг олон нууцыг хадгалдаг. Тэдгээрийн нэг нь 1.7 хувилбар дээр гарч ирсэн validCheckSum түлхүүр бөгөөд мэдээллийн санд юу хадгалагдаж байгаагаас үл хамааран тодорхой өөрчлөлтийн багцад хүчинтэй хэш утгыг зааж өгөх боломжийг олгодог. Баримт бичиг дараах зүйлийг хэлж байна.
Өгөгдлийн санд юу хадгалагдаж байгаагаас үл хамааран энэхүү өөрчлөлтийн багцад хүчинтэй гэж тооцогдох шалгах нийлбэрийг нэмнэ үү. Үндсэндээ та өөрчлөлтийн багцыг өөрчлөх шаардлагатай бөгөөд аль хэдийн ажиллаж байсан мэдээллийн санд алдаа гаргахыг хүсэхгүй байгаа үед ашиглагддаг (санал болгосон процедур биш)
Тийм ээ, тийм ээ, энэ процедурыг хийхийг зөвлөдөггүй. Гэхдээ заримдаа хүчтэй гэрлийн илбэчин харанхуй техникийг эзэмшдэг
Нөхцөл байдал 2: Өгөгдлөөс хамаарах шилжилт хөдөлгөөн
Танд шууд серверээс мэдээллийн сангийн нөөцлөлтийг ашиглах чадвар байхгүй гэж бодъё. Петя өөрчлөлтийн багц үүсгэж, орон нутагтаа туршиж үзээд зөв гэдэгт бүрэн итгэлтэй байж хөгжүүлэгч рүү татах хүсэлт гаргасан. Ямар ч тохиолдолд төслийн удирдагч Петя үүнийг шалгасан эсэхийг тодруулж, дараа нь нэмсэн. Гэвч хөгжүүлэлтийн сервер дээр байршуулалт буурсан.
Үнэн хэрэгтээ энэ нь боломжтой бөгөөд хэн ч үүнээс ангид байдаггүй. Хүснэгтийн бүтцэд өөрчлөлт оруулах нь өгөгдлийн сангийн тодорхой өгөгдөлтэй ямар нэгэн байдлаар холбоотой байвал энэ нь тохиолддог. Мэдээжийн хэрэг, хэрэв Петягийн мэдээллийн сан нь зөвхөн туршилтын мэдээллээр дүүрсэн бол энэ нь асуудлын бүх тохиолдлыг хамрахгүй байж магадгүй юм. Жишээлбэл, хүснэгтийг устгах үед Гадаад Түлхүүрээр бусад хүснэгтэд устгаж байгаа бичлэгүүдтэй холбоотой бичлэгүүд байгаа нь харагдаж байна. Эсвэл баганын төрлийг өөрчлөхөд өгөгдлийн 100% нь шинэ төрөл рүү хөрвүүлэх боломжгүй болж байна.
Хэрхэн шийдэх вэ
- Шилжилтийн үед нэг удаа хэрэглэгдэх тусгай скриптүүдийг бичиж, өгөгдлийг зохих хэлбэрт оруулаарай. Энэ нь шилжилт хөдөлгөөн хийсний дараа өгөгдлийг шинэ бүтэц рүү шилжүүлэх асуудлыг шийдэх ерөнхий арга боловч үүнтэй төстэй зүйлийг онцгой тохиолдолд өмнө нь хэрэглэж болно. Энэ зам нь мэдээжийн хэрэг үргэлж боломжгүй байдаг, учир нь шууд сервер дээрх өгөгдлийг засварлах нь аюултай, бүр хор хөнөөлтэй байж болно.
- Өөр нэг хэцүү арга бол одоо байгаа өөрчлөлтийн багцыг засах явдал юм. Асуудал нь одоо байгаа хэлбэрээр хэрэглэгдэж байсан бүх мэдээллийн санг сэргээх шаардлагатай болно. Бүхэл бүтэн арын баг мэдээллийн санг эхнээс нь орон нутагт гаргахаас өөр аргагүйд хүрч магадгүй юм.
- Хамгийн түгээмэл арга бол өгөгдлийн асуудлыг хөгжүүлэгчийн орчинд шилжүүлэх, ижил нөхцөл байдлыг дахин үүсгэж, эвдэрсэн хэсэгт шинэ өөрчлөлт оруулах бөгөөд энэ нь асуудлыг тойрч гарах болно.
Ерөнхийдөө мэдээллийн сан нь үйлдвэрлэлийн серверийн мэдээллийн сантай ижил төстэй байх тусам шилжилт хөдөлгөөнтэй холбоотой асуудал гарах магадлал багасна. Мэдээжийн хэрэг, өөрчлөлтийн багцыг репозитор руу илгээхээсээ өмнө энэ нь ямар нэгэн зүйлийг эвдэх эсэхийг хэд хэдэн удаа бодох хэрэгтэй.
Нөхцөл байдал 3. Liquibase нь үйлдвэрлэлд орсны дараа ашиглагдаж эхэлдэг
Багийн ахлагч Петягаас Liquibase-г төсөлд оруулахыг хүссэн боловч төсөл аль хэдийн үйлдвэрлэгдэж байгаа бөгөөд мэдээллийн сангийн бүтэц байгаа гэж бодъё.
Үүний дагуу аливаа шинэ серверүүд эсвэл хөгжүүлэгч машинууд дээр эдгээр хүснэгтүүдийг эхнээс нь дахин үүсгэх ёстой бөгөөд одоо байгаа орчин нь шинэ өөрчлөлтийн багцыг хүлээн авахад бэлэн тогтвортой байдалд байх ёстой.
Хэрхэн шийдэх вэ
Мөн хэд хэдэн арга байдаг:
- Эхний бөгөөд хамгийн ойлгомжтой зүйл бол шинэ орчинг эхлүүлэхдээ гараар ашиглах ёстой тусдаа скрипттэй байх явдал юм.
- Хоёр дахь нь тодорхой бус, өөр Liquibase контекст байгаа Liquibase шилжилттэй байж, хэрэглээрэй. Та эндээс Liquibase контекстийн талаар илүү ихийг уншиж болно: . Ерөнхийдөө энэ бол туршилтанд амжилттай ашиглаж болох сонирхолтой механизм юм.
- Гурав дахь зам нь хэд хэдэн алхамаас бүрдэнэ. Нэгдүгээрт, одоо байгаа хүснэгтүүдэд шилжих хөдөлгөөнийг үүсгэх ёстой. Дараа нь үүнийг зарим орчинд хэрэглэх ёстой бөгөөд ингэснээр түүний хэш нийлбэрийг авах болно. Дараагийн алхам бол хоосон бус сервер дээр Liquibase-ийн хоосон хүснэгтүүдийг эхлүүлэх бөгөөд өөрчлөлтийн багцыг ашигласан түүхтэй хүснэгтэд та мэдээллийн санд байгаа өөрчлөлтүүдтэй "хэрэглэсэн мэт" өөрчлөлтийн талаар гараар бичиж болно. . Тиймээс одоо байгаа сервер дээр түүхийн тооллого 2-р хувилбараас эхлэх бөгөөд бүх шинэ орчин ижилхэн ажиллах болно.
Нөхцөл байдал 4. Шилжилт хөдөлгөөн асар их болж, дуусгах цаг байхгүй
Үйлчилгээг хөгжүүлэх эхэнд, дүрмээр бол Liquibase-ийг гадны хамаарал болгон ашигладаг бөгөөд програм эхлэхэд бүх шилжилтийг боловсруулдаг. Гэсэн хэдий ч цаг хугацаа өнгөрөхөд та дараах тохиолдлуудад бүдэрч магадгүй.
- Шилжилт хөдөлгөөн асар их болж, дуусгахад удаан хугацаа шаардагдана.
- Түгээмэл орчинд, жишээлбэл, хэд хэдэн өгөгдлийн сангийн серверийн жишээн дээр нэгэн зэрэг шилжих шаардлагатай байдаг.
Энэ тохиолдолд шилжүүлэлтийг хэт удаан хэрэглэснээр програм эхлэхэд хугацаа хэтрэх болно. Нэмж дурдахад, шилжилт хөдөлгөөнийг хэрэглүүрийн тохиолдол бүрт тус тусад нь хэрэгжүүлэх нь өөр өөр серверүүдийг синхрончлолгүй болгоход хүргэж болзошгүй.
Хэрхэн шийдэх вэ
Ийм тохиолдолд таны төсөл аль хэдийн том болсон, магадгүй насанд хүрсэн хүн ч гэсэн Liquibase нь тусдаа гадаад хэрэгсэл болж эхэлдэг. Үнэн хэрэгтээ Liquibase нь номын сан хэлбэрээр jar файлд хөрвүүлсэн бөгөөд төслийн хүрээнд эсвэл бие даан ажиллах боломжтой.
Бие даасан горимд та шилжүүлгийн хэрэгжилтийг өөрийн CI/CD орчин эсвэл системийн администраторууд болон байршуулалтын мэргэжилтнүүдийн хүчтэй мөрөнд үлдээж болно. Үүнийг хийхийн тулд танд Liquibase командын мөр хэрэгтэй болно . Энэ горимд шаардлагатай бүх шилжүүлгийг хийсний дараа програмыг эхлүүлэх боломжтой болно.
дүгнэлт
Үнэн хэрэгтээ, мэдээллийн баазын шилжилттэй ажиллахад өөр олон бэрхшээл байж болох бөгөөд тэдгээрийн ихэнх нь бүтээлч хандлагыг шаарддаг. Хэрэв та багажийг зөв ашиглавал эдгээр бэрхшээлээс зайлсхийх боломжтой гэдгийг ойлгох нь чухал юм. Тодруулбал, би жагсаасан бүх асуудлыг янз бүрийн хэлбэрээр шийдвэрлэх шаардлагатай болсон бөгөөд тэдгээрийн зарим нь миний алдааны үр дагавар байсан. Ихэнхдээ энэ нь мэдээжийн хэрэг анхаарал болгоомжгүй байдлаас болж тохиолддог, гэхдээ заримдаа гэмт хэргийн улмаас уг хэрэгслийг ашиглах чадваргүй байдаг.
Эх сурвалж: www.habr.com