តើធ្វើដូចម្តេចដើម្បីជៀសវាងការបាញ់ខ្លួនឯងនៅក្នុងជើងដោយប្រើ Liquibase

មិនធ្លាប់មានពីមុនមក ហើយយើងទៅម្តងទៀត!

នៅលើគម្រោងបន្ទាប់របស់យើង យើងបានសម្រេចចិត្តប្រើ Liquibase តាំងពីដំបូង ដើម្បីជៀសវាងបញ្ហានៅពេលអនាគត។ ដូចដែលវាបានប្រែក្លាយ មិនមែនសមាជិកក្រុមវ័យក្មេងទាំងអស់ដឹងពីរបៀបប្រើវាឱ្យបានត្រឹមត្រូវនោះទេ។ ខ្ញុំបានរៀបចំសិក្ខាសាលាផ្ទៃក្នុងមួយ ដែលបន្ទាប់មកខ្ញុំបានសម្រេចចិត្តប្រែក្លាយទៅជាអត្ថបទមួយ។

អត្ថបទរួមមានគន្លឹះមានប្រយោជន៍ និងការពិពណ៌នាអំពីបញ្ហាជាក់ស្តែងបំផុតចំនួនបី ដែលអ្នកអាចធ្លាក់ចូលទៅក្នុងពេលធ្វើការជាមួយឧបករណ៍ផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យដែលទាក់ទង ជាពិសេស Liquibase ។ រចនាឡើងសម្រាប់អ្នកអភិវឌ្ឍន៍ Java នៅកម្រិត Junior និង Middle សម្រាប់អ្នកអភិវឌ្ឍន៍ដែលមានបទពិសោធន៍ច្រើន វាអាចមានការចាប់អារម្មណ៍សម្រាប់ការរៀបចំរចនាសម្ព័ន្ធ និងការនិយាយឡើងវិញនូវអ្វីដែលទំនងជាដឹងរួចហើយ។

Liquibase និង Flyway គឺជាបច្ចេកវិទ្យាប្រកួតប្រជែងដ៏សំខាន់សម្រាប់ការដោះស្រាយបញ្ហាការគ្រប់គ្រងកំណែនៃរចនាសម្ព័ន្ធទំនាក់ទំនងនៅក្នុងពិភព Java ។ ទីមួយគឺមិនគិតថ្លៃទាំងស្រុងទេ តាមការអនុវត្តជាក់ស្តែងវាត្រូវបានជ្រើសរើសជាញឹកញាប់បំផុតសម្រាប់ការប្រើប្រាស់ ដែលជាមូលហេតុដែល Liquibase ត្រូវបានជ្រើសរើសជាវីរបុរសនៃការបោះពុម្ពផ្សាយ។ ទោះយ៉ាងណាក៏ដោយ ការអនុវត្តមួយចំនួនដែលបានពិពណ៌នាអាចជាសកល អាស្រ័យលើស្ថាបត្យកម្មកម្មវិធីរបស់អ្នក។

ការធ្វើចំណាកស្រុកនៃរចនាសម្ព័ន្ធទំនាក់ទំនងគឺជាវិធីបង្ខំដើម្បីដោះស្រាយជាមួយនឹងភាពបត់បែនខ្សោយនៃឃ្លាំងទិន្នន័យទំនាក់ទំនង។ នៅក្នុងយុគសម័យនៃម៉ូដ OOP រចនាប័ទ្មនៃការធ្វើការជាមួយមូលដ្ឋានទិន្នន័យមានន័យថាយើងនឹងពណ៌នាគ្រោងការណ៍ម្តងហើយមិនប៉ះវាម្តងទៀត។ ប៉ុន្តែការពិតគឺតែងតែថាអ្វីៗផ្លាស់ប្តូរ ហើយការផ្លាស់ប្តូររចនាសម្ព័ន្ធតារាងត្រូវបានទាមទារជាញឹកញាប់។ តាមធម្មជាតិ ដំណើរការខ្លួនវាអាចឈឺចាប់ និងមិនសប្បាយចិត្ត។

ខ្ញុំនឹងមិនចូលជ្រៅទៅក្នុងការពិពណ៌នាអំពីបច្ចេកវិទ្យា និងការណែនាំសម្រាប់ការបន្ថែមបណ្ណាល័យទៅក្នុងគម្រោងរបស់អ្នកទេ អត្ថបទមួយចំនួនត្រូវបានសរសេរលើប្រធានបទនេះ៖

• ការប្រើប្រាស់ Liquibase ដើម្បីគ្រប់គ្រងរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យនៅក្នុងកម្មវិធី Spring Boot ។ ផ្នែកទី 1
• ការប្រើប្រាស់ Liquibase ដើម្បីគ្រប់គ្រងរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យនៅក្នុងកម្មវិធី Spring Boot ។ ផ្នែកទី 2
• Liquibase និង Maven
• វិធីសាស្រ្តនៃការផ្លាស់ប្តូរមូលដ្ឋានទិន្នន័យកំណែ
• យើងបើកដំណើរការ Spring MVC/Security, REST, Hibernate, Liquibase ជាពីរជួរ

លើសពីនេះ មានអត្ថបទដ៏ល្អមួយរួចហើយលើប្រធានបទ គន្លឹះមានប្រយោជន៍៖

• ការប្រើប្រាស់ Liquibase ដោយមិនឈឺក្បាល។ 10 គន្លឹះពីបទពិសោធន៍អភិវឌ្ឍន៍ពិតប្រាកដ

ព័ត៌មានជំនួយ

ខ្ញុំចង់ចែករំលែកដំបូន្មាន និងយោបល់របស់ខ្ញុំ ដែលកើតមកតាមរយៈញើសឈាម និងការឈឺចាប់នៃការដោះស្រាយបញ្ហាចំណាកស្រុក។

1. មុនពេលចាប់ផ្តើមការងារ អ្នកគួរតែស្គាល់ខ្លួនអ្នកជាមួយនឹងផ្នែកការអនុវត្តល្អបំផុតនៅលើ តំបន់បណ្តាញ Liquibase

នៅទីនោះ រឿងសាមញ្ញៗ ប៉ុន្តែសំខាន់ណាស់ត្រូវបានពិពណ៌នា ដោយមិនប្រើបណ្ណាល័យអាចធ្វើអោយជីវិតអ្នកស្មុគស្មាញបាន។ ជាឧទាហរណ៍ វិធីសាស្រ្តដែលមិនមានរចនាសម្ព័ន្ធក្នុងការគ្រប់គ្រងការផ្លាស់ប្ដូរនឹងឆាប់ឬក្រោយមកនាំឱ្យមានការភ័ន្តច្រឡំ និងការធ្វើចំណាកស្រុកដែលខូច។ ប្រសិនបើអ្នកមិនបញ្ចេញការផ្លាស់ប្តូរដែលពឹងផ្អែកទៅវិញទៅមកចំពោះរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យ និងតក្កវិជ្ជាសេវាកម្មក្នុងពេលតែមួយទេ វាមានប្រូបាប៊ីលីតេខ្ពស់ដែលវានឹងនាំទៅដល់ការធ្វើតេស្តក្រហម ឬបរិស្ថានដែលខូច។ លើសពីនេះទៀត ការណែនាំសម្រាប់ការប្រើប្រាស់ Liquibase នៅលើគេហទំព័រផ្លូវការមានឃ្លាអំពីការអភិវឌ្ឍន៍ និងការធ្វើតេស្តស្គ្រីប rollback រួមជាមួយនឹងស្គ្រីបចំណាកស្រុកសំខាន់ៗ។ មែនហើយនៅក្នុងអត្ថបទ https://habr.com/ru/post/178665/ មានឧទាហរណ៍កូដទាក់ទងនឹងការធ្វើចំណាកស្រុក និងយន្តការវិលត្រឡប់មកវិញ។

2. ប្រសិនបើអ្នកចាប់ផ្តើមប្រើឧបករណ៍ធ្វើចំណាកស្រុក សូមកុំអនុញ្ញាតឱ្យមានការកែតម្រូវដោយដៃនៅក្នុងរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យ

ដូចពាក្យថា “One Persil, always Persil”។ ប្រសិនបើមូលដ្ឋាននៃកម្មវិធីរបស់អ្នកចាប់ផ្តើមត្រូវបានគ្រប់គ្រងដោយ Liquibase ការផ្លាស់ប្តូរដោយដៃណាមួយភ្លាមៗនាំទៅរកស្ថានភាពមិនស៊ីសង្វាក់គ្នា ហើយកម្រិតនៃការជឿទុកចិត្តលើការផ្លាស់ប្តូរនឹងក្លាយទៅជាសូន្យ។ ហានិភ័យដែលអាចកើតមានរួមមានការចំណាយពេលជាច្រើនម៉ោងដើម្បីស្ដារមូលដ្ឋានទិន្នន័យឡើងវិញ ក្នុងករណីដ៏អាក្រក់បំផុតគឺម៉ាស៊ីនមេដែលស្លាប់។ ប្រសិនបើអ្នកមាន "សាលាចាស់" DBA ស្ថាបត្យករនៅក្នុងក្រុមរបស់អ្នក ពន្យល់គាត់ដោយអត់ធ្មត់ និងគិតឱ្យបានច្បាស់ថាតើរឿងអាក្រក់នឹងទៅជាយ៉ាងណា ប្រសិនបើគាត់គ្រាន់តែកែសម្រួលមូលដ្ឋានទិន្នន័យតាមការយល់ដឹងរបស់គាត់ពីអ្នកអភិវឌ្ឍន៍ SQL ដែលមានលក្ខខណ្ឌ។

3. ប្រសិនបើការផ្លាស់ប្តូរត្រូវបានរុញចូលទៅក្នុងឃ្លាំងរួចហើយ ជៀសវាងការកែសម្រួល

ប្រសិនបើអ្នកអភិវឌ្ឍន៍ផ្សេងទៀតបានធ្វើការទាញ និងអនុវត្តសំណុំការផ្លាស់ប្តូរ ដែលនៅពេលក្រោយនឹងត្រូវបានកែសម្រួល គាត់នឹងចងចាំអ្នកដោយពាក្យសប្បុរស នៅពេលដែលគាត់ទទួលបានកំហុសនៅពេលចាប់ផ្តើមកម្មវិធី។ ប្រសិនបើការកែសម្រួលឈុតផ្លាស់ប្តូរដោយរបៀបណាដែលលេចធ្លាយទៅក្នុងការអភិវឌ្ឍន៍ អ្នកនឹងត្រូវធ្វើតាមជម្រាលរអិលនៃកម្មវិធីកែកុន។ ខ្លឹមសារនៃបញ្ហាគឺស្ថិតនៅលើសុពលភាពនៃការផ្លាស់ប្តូរដោយផលបូកលេខ - យន្តការសំខាន់របស់ Liquibase ។ នៅពេលកែសម្រួលកូដកំណត់ បរិមាណ hash ផ្លាស់ប្តូរ។ ការកែសម្រួលការផ្លាស់ប្តូរគឺអាចធ្វើទៅបានលុះត្រាតែវាអាចធ្វើទៅបានដើម្បីដាក់ពង្រាយមូលដ្ឋានទិន្នន័យទាំងមូលពីដំបូងដោយមិនបាត់បង់ទិន្នន័យ។ ក្នុងករណីនេះ ការផ្លាស់ប្តូរកូដ SQL ឬ XML ផ្ទុយទៅវិញអាចធ្វើឱ្យជីវិតកាន់តែងាយស្រួល និងធ្វើឱ្យការធ្វើចំណាកស្រុកកាន់តែអាចអានបាន។ ឧទាហរណ៍មួយនឹងជាស្ថានភាពដែលនៅពេលចាប់ផ្តើមកម្មវិធី គ្រោងការណ៍នៃមូលដ្ឋានទិន្នន័យប្រភពត្រូវបានយល់ព្រមនៅក្នុងក្រុម។

4. បានផ្ទៀងផ្ទាត់ការបម្រុងទុកមូលដ្ឋានទិន្នន័យប្រសិនបើអាចធ្វើទៅបាន

នៅទីនេះខ្ញុំគិតថាអ្វីៗគឺច្បាស់។ ប្រសិនបើភ្លាមៗការធ្វើចំណាកស្រុកមិនបានជោគជ័យ អ្វីៗអាចត្រលប់មកវិញបាន។ Liquibase មានឧបករណ៍សម្រាប់រំកិលការផ្លាស់ប្តូរ ប៉ុន្តែស្គ្រីបវិលវិញក៏ត្រូវបានសរសេរដោយអ្នកអភិវឌ្ឍន៍ខ្លួនឯងដែរ ហើយពួកគេអាចមានបញ្ហាជាមួយនឹងប្រូបាប៊ីលីតេដូចគ្នាទៅនឹងស្គ្រីបនៃសំណុំការផ្លាស់ប្តូរសំខាន់។ នេះមានន័យថាវាមានប្រយោជន៍ក្នុងការលេងវាដោយសុវត្ថិភាពជាមួយនឹងការបម្រុងទុកនៅក្នុងករណីណាមួយ។

5. ប្រើការបម្រុងទុកមូលដ្ឋានទិន្នន័យដែលបានបញ្ជាក់ក្នុងការអភិវឌ្ឍន៍ ប្រសិនបើអាចធ្វើទៅបាន

ប្រសិនបើវាមិនផ្ទុយពីកិច្ចសន្យា និងភាពឯកជនទេនោះ មិនមានទិន្នន័យផ្ទាល់ខ្លួននៅក្នុងមូលដ្ឋានទិន្នន័យទេ ហើយវាមិនទម្ងន់ដូចព្រះអាទិត្យពីរទេ - មុនពេលប្រើវានៅលើម៉ាស៊ីនមេផ្លាស់ទីផ្ទាល់ អ្នកអាចពិនិត្យមើលថាតើវានឹងដំណើរការលើម៉ាស៊ីនរបស់អ្នកអភិវឌ្ឍន៍ និងគណនាយ៉ាងដូចម្តេច។ ស្ទើរតែ 100% នៃបញ្ហាដែលអាចកើតមានក្នុងអំឡុងពេលធ្វើចំណាកស្រុក។

6. ទំនាក់ទំនងជាមួយអ្នកអភិវឌ្ឍន៍ផ្សេងទៀតនៅក្នុងក្រុម

នៅក្នុងដំណើរការអភិវឌ្ឍន៍ដែលរៀបចំបានល្អ អ្នករាល់គ្នានៅក្នុងក្រុមដឹងថាអ្នកណាកំពុងធ្វើអ្វី។ តាមពិត នេះច្រើនតែមិនមែនជាករណីនោះទេ ដូច្នេះហើយ ប្រសិនបើអ្នកកំពុងរៀបចំការផ្លាស់ប្តូររចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យជាផ្នែកនៃកិច្ចការរបស់អ្នក គួរតែជូនដំណឹងបន្ថែមដល់ក្រុមទាំងមូលអំពីបញ្ហានេះ។ ប្រសិនបើនរណាម្នាក់កំពុងធ្វើការផ្លាស់ប្តូរស្របគ្នា អ្នកគួរតែរៀបចំដោយប្រុងប្រយ័ត្ន។ វាមានតម្លៃក្នុងការប្រាស្រ័យទាក់ទងជាមួយមិត្តរួមការងារបន្ទាប់ពីបញ្ចប់ការងារ មិនមែនគ្រាន់តែនៅពេលចាប់ផ្តើមនោះទេ។ បញ្ហាដែលអាចកើតមានជាច្រើនជាមួយនឹងការផ្លាស់ប្តូរអាចត្រូវបានដោះស្រាយនៅដំណាក់កាលពិនិត្យកូដ។

7. គិតអំពីអ្វីដែលអ្នកកំពុងធ្វើ!

វាហាក់ដូចជាដំបូន្មានដែលបង្ហាញឱ្យឃើញដោយខ្លួនឯងដែលអនុវត្តចំពោះស្ថានភាពណាមួយ។ ទោះជាយ៉ាងណាក៏ដោយ បញ្ហាជាច្រើនអាចត្រូវបានជៀសវាង ប្រសិនបើអ្នកអភិវឌ្ឍន៍បានវិភាគម្តងទៀតនូវអ្វីដែលគាត់កំពុងធ្វើ និងអ្វីដែលវាអាចប៉ះពាល់ដល់។ ការធ្វើការជាមួយការធ្វើចំណាកស្រុកតែងតែទាមទារការយកចិត្តទុកដាក់បន្ថែម និងភាពត្រឹមត្រូវ។

អន្ទាក់

ឥឡូវនេះ សូមក្រឡេកមើលអន្ទាក់ធម្មតា ដែលអ្នកអាចធ្លាក់ចូលទៅក្នុង ប្រសិនបើអ្នកមិនធ្វើតាមការណែនាំខាងលើ ហើយតើអ្នកគួរធ្វើយ៉ាងណា?

ស្ថានភាពទី 1៖ អ្នកអភិវឌ្ឍន៍ពីរនាក់កំពុងព្យាយាមបន្ថែមការផ្លាស់ប្តូរថ្មីក្នុងពេលតែមួយ

Vasya និង Petya ចង់បង្កើតការផ្លាស់ប្តូរកំណែទី 4 ដោយមិនដឹងពីគ្នាទៅវិញទៅមក។ ពួកគេបានធ្វើការផ្លាស់ប្តូររចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យ និងបានចេញសំណើទាញជាមួយនឹងឯកសារផ្លាស់ប្តូរផ្សេងគ្នា។ យន្តការនៃសកម្មភាពខាងក្រោមត្រូវបានស្នើឡើង៖

របៀបសម្រេចចិត្ត

1. ដូចម្ដេច សហសេវិកត្រូវតែយល់ព្រមលើលំដាប់ដែលការផ្លាស់ប្តូររបស់ពួកគេគួរតែទៅ ឧទាហរណ៍ Petin គួរតែត្រូវបានអនុវត្តជាមុនសិន។
2. នរណាម្នាក់គួរតែបន្ថែមលេខទីពីរទៅខ្លួនគេ ហើយសម្គាល់ការផ្លាស់ប្តូររបស់ Vasya ជាមួយនឹងកំណែទី 5។ នេះអាចត្រូវបានធ្វើតាមរយៈ Cherry Pick ឬការរួមបញ្ចូលគ្នាយ៉ាងស្អាត។
3. បន្ទាប់ពីការផ្លាស់ប្តូរ អ្នកពិតជាគួរពិនិត្យមើលសុពលភាពនៃសកម្មភាពដែលបានធ្វើឡើង។
   ជាការពិត យន្តការ Liquibase នឹងអនុញ្ញាតឱ្យអ្នកមានការផ្លាស់ប្តូរកំណែ 4 ចំនួនពីរនៅក្នុងឃ្លាំង ដូច្នេះអ្នកអាចទុកអ្វីៗគ្រប់យ៉ាងដូចបច្ចុប្បន្ន។ នោះគឺអ្នកនឹងមានការផ្លាស់ប្តូរពីរទៅកំណែ 4 ជាមួយនឹងឈ្មោះផ្សេងគ្នា។ ជាមួយនឹងវិធីសាស្រ្តនេះ ក្រោយមកវាក្លាយជាការលំបាកខ្លាំងណាស់ក្នុងការរុករកកំណែមូលដ្ឋានទិន្នន័យ។

លើសពីនេះទៀត Liquibase ដូចជាផ្ទះរបស់ hobbits រក្សាអាថ៌កំបាំងជាច្រើន។ មួយក្នុងចំណោមពួកគេគឺជា validCheckSum key ដែលបានបង្ហាញខ្លួននៅក្នុងកំណែ 1.7 និងអនុញ្ញាតឱ្យអ្នកបញ្ជាក់តម្លៃ hash ត្រឹមត្រូវសម្រាប់សំណុំការផ្លាស់ប្តូរជាក់លាក់មួយ ដោយមិនគិតពីអ្វីដែលត្រូវបានរក្សាទុកនៅក្នុងមូលដ្ឋានទិន្នន័យ។ ឯកសារ https://www.liquibase.org/documentation/changeset.html និយាយដូចតទៅ៖

បន្ថែមមូលប្បទានប័ត្រដែលត្រូវបានចាត់ទុកថាមានសុពលភាពសម្រាប់សំណុំនៃការផ្លាស់ប្តូរនេះ ដោយមិនគិតពីអ្វីដែលត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ។ ប្រើជាចម្បងនៅពេលដែលអ្នកត្រូវការផ្លាស់ប្តូរ ChangeSet ហើយមិនចង់មានកំហុសនៅលើមូលដ្ឋានទិន្នន័យដែលវាដំណើរការរួចហើយ (មិនមែនជានីតិវិធីដែលបានណែនាំទេ)

បាទ/ចាស៎ នីតិវិធីនេះមិនត្រូវបានណែនាំទេ។ ប៉ុន្តែពេលខ្លះ គ្រូមន្តអាគមពន្លឺខ្លាំង ក៏ចេះបច្ចេកទេសងងឹតដែរ។

ស្ថានភាពទី 2: ការធ្វើចំណាកស្រុកដែលអាស្រ័យលើទិន្នន័យ

ឧបមាថាអ្នកមិនមានលទ្ធភាពប្រើការបម្រុងទុកមូលដ្ឋានទិន្នន័យពីម៉ាស៊ីនមេផ្ទាល់ទេ។ Petya បានបង្កើតសំណុំការផ្លាស់ប្តូរមួយ សាកល្បងវានៅក្នុងមូលដ្ឋាន ហើយដោយមានទំនុកចិត្តពេញលេញថាគាត់ត្រឹមត្រូវ បានធ្វើសំណើទាញទៅកាន់អ្នកអភិវឌ្ឍន៍។ ក្នុង​ករណី​នេះ ប្រធាន​គម្រោង​បាន​បញ្ជាក់​ថា​តើ Petya បាន​ពិនិត្យ​វា​ដែរ​ឬ​ទេ ហើយ​បន្ទាប់​មក​បន្ថែម​វា។ ប៉ុន្តែការដាក់ពង្រាយនៅលើម៉ាស៊ីនមេអភិវឌ្ឍន៍បានធ្លាក់ចុះ។

តាមពិត នេះអាចទៅរួច ហើយគ្មាននរណាម្នាក់មានភាពស៊ាំពីរឿងនេះទេ។ វាកើតឡើងប្រសិនបើការកែប្រែរចនាសម្ព័ន្ធតារាងត្រូវបានចងភ្ជាប់ជាមួយទិន្នន័យជាក់លាក់ពីមូលដ្ឋានទិន្នន័យ។ ជាក់ស្តែង ប្រសិនបើមូលដ្ឋានទិន្នន័យរបស់ Petya ត្រូវបានបំពេញដោយទិន្នន័យសាកល្បង នោះវាប្រហែលជាមិនគ្របដណ្តប់គ្រប់ករណីបញ្ហាទាំងអស់នោះទេ។ ឧទាហរណ៍ នៅពេលលុបតារាង វាបង្ហាញថាមានកំណត់ត្រានៅក្នុងតារាងផ្សេងទៀតដោយ Foreign Key ដែលទាក់ទងនឹងកំណត់ត្រានៅក្នុងមួយដែលត្រូវបានលុប។ ឬនៅពេលផ្លាស់ប្តូរប្រភេទជួរឈរ វាប្រែថាមិនមែន 100% នៃទិន្នន័យអាចត្រូវបានបម្លែងទៅជាប្រភេទថ្មីនោះទេ។

របៀបសម្រេចចិត្ត

• សរសេរស្គ្រីបពិសេសដែលនឹងត្រូវបានប្រើម្តង រួមជាមួយនឹងការធ្វើចំណាកស្រុក និងនាំយកទិន្នន័យទៅក្នុងទម្រង់ត្រឹមត្រូវ។ នេះជាវិធីទូទៅក្នុងការដោះស្រាយបញ្ហាផ្ទេរទិន្នន័យទៅរចនាសម្ព័ន្ធថ្មីបន្ទាប់ពីអនុវត្តការធ្វើចំណាកស្រុក ប៉ុន្តែអ្វីដែលស្រដៀងគ្នាអាចត្រូវបានអនុវត្តពីមុន ក្នុងករណីពិសេស។ ជាការពិតណាស់ ផ្លូវនេះមិនតែងតែមានទេ ពីព្រោះការកែសម្រួលទិន្នន័យនៅលើម៉ាស៊ីនមេផ្ទាល់អាចមានគ្រោះថ្នាក់ និងសូម្បីតែការបំផ្លិចបំផ្លាញ។
• វិធីដ៏លំបាកមួយទៀតគឺការកែសម្រួលសំណុំការផ្លាស់ប្តូរដែលមានស្រាប់។ ការលំបាកគឺថាមូលដ្ឋានទិន្នន័យទាំងអស់ដែលវាត្រូវបានអនុវត្តរួចហើយនៅក្នុងទម្រង់ដែលមានស្រាប់របស់វានឹងត្រូវស្ដារឡើងវិញ។ វាអាចទៅរួចដែលថាក្រុម backend ទាំងមូលនឹងត្រូវបានបង្ខំឱ្យដាក់មូលដ្ឋានទិន្នន័យចេញពីមូលដ្ឋាន។
• ហើយមធ្យោបាយជាសកលបំផុតគឺផ្ទេរបញ្ហាជាមួយទិន្នន័យទៅកាន់បរិស្ថានរបស់អ្នកអភិវឌ្ឍន៍ បង្កើតស្ថានភាពដូចគ្នាឡើងវិញ និងបន្ថែមការផ្លាស់ប្ដូរថ្មីទៅផ្នែកដែលខូច ដែលនឹងជៀសវាងបញ្ហា។
  

ជាទូទៅ មូលដ្ឋានទិន្នន័យកាន់តែមានភាពស្រដៀងគ្នានៅក្នុងសមាសភាពទៅនឹងមូលដ្ឋានទិន្នន័យម៉ាស៊ីនមេផលិតកម្ម ឱកាសតិចជាងដែលបញ្ហាជាមួយនឹងការធ្វើចំណាកស្រុកនឹងទៅឆ្ងាយ។ ហើយជាការពិតណាស់ មុនពេលដែលអ្នកផ្ញើសំណុំការផ្លាស់ប្តូរទៅកាន់ឃ្លាំង អ្នកគួរតែគិតច្រើនដងថាតើវានឹងធ្វើឱ្យខូចអ្វីទាំងអស់។

ស្ថានភាព 3. Liquibase ចាប់ផ្តើមប្រើបន្ទាប់ពីវាចូលទៅក្នុងការផលិត

ឧបមាថាប្រធានក្រុមបានស្នើឱ្យ Petya បញ្ចូល Liquibase ក្នុងគម្រោង ប៉ុន្តែគម្រោងនេះកំពុងដំណើរការហើយ ហើយមានរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យដែលមានស្រាប់។

អាស្រ័យហេតុនេះ បញ្ហាគឺថានៅលើម៉ាស៊ីនមេថ្មី ឬម៉ាស៊ីនអ្នកអភិវឌ្ឍន៍ តារាងទាំងនេះត្រូវតែបង្កើតឡើងវិញពីទទេ ហើយបរិយាកាសដែលមានស្រាប់ត្រូវតែស្ថិតក្នុងស្ថានភាពជាប់លាប់ ត្រៀមខ្លួនដើម្បីទទួលយកការផ្លាស់ប្តូរថ្មី។

របៀបសម្រេចចិត្ត

មានវិធីជាច្រើនផងដែរ៖

• ទីមួយ និងច្បាស់បំផុតគឺត្រូវមានស្គ្រីបដាច់ដោយឡែកដែលត្រូវតែអនុវត្តដោយដៃនៅពេលចាប់ផ្តើមបរិស្ថានថ្មី។
• ទីពីរគឺមិនសូវច្បាស់ទេ មានការធ្វើចំណាកស្រុក Liquibase ដែលស្ថិតនៅក្នុងបរិបទ Liquibase ផ្សេងទៀត ហើយអនុវត្តវា។ អ្នកអាចអានបន្ថែមអំពីបរិបទ Liquibase នៅទីនេះ៖ https://www.liquibase.org/documentation/contexts.html. ជាទូទៅនេះគឺជាយន្តការគួរឱ្យចាប់អារម្មណ៍ដែលអាចត្រូវបានប្រើដោយជោគជ័យឧទាហរណ៍សម្រាប់ការធ្វើតេស្ត។
• ផ្លូវទីបីមានជំហានជាច្រើន។ ដំបូង ការធ្វើចំណាកស្រុកត្រូវតែបង្កើតសម្រាប់តារាងដែលមានស្រាប់។ បន្ទាប់មកវាត្រូវតែអនុវត្តចំពោះបរិស្ថានមួយចំនួន ហើយដូច្នេះផលបូករបស់វានឹងត្រូវបានទទួល។ ជំហានបន្ទាប់គឺត្រូវចាប់ផ្តើមតារាង Liquibase ទទេនៅលើម៉ាស៊ីនមេដែលមិនទទេរបស់យើង ហើយនៅក្នុងតារាងជាមួយនឹងប្រវត្តិនៃការប្រើប្រាស់ការផ្លាស់ប្តូរ អ្នកអាចដាក់កំណត់ត្រាដោយដៃអំពីការផ្លាស់ប្តូរ "ដូចជាប្រសិនបើបានអនុវត្ត" ជាមួយនឹងការផ្លាស់ប្តូរដែលមានរួចហើយនៅក្នុងមូលដ្ឋានទិន្នន័យ។ . ដូច្នេះនៅលើម៉ាស៊ីនមេដែលមានស្រាប់ ការរាប់ថយក្រោយនឹងចាប់ផ្តើមពីកំណែ 2 ហើយបរិស្ថានថ្មីទាំងអស់នឹងមានលក្ខណៈដូចគ្នាបេះបិទ។
  

ស្ថានភាព 4. ការធ្វើចំណាកស្រុកក្លាយជាធំ ហើយមិនមានពេលវេលាដើម្បីបញ្ចប់

នៅដើមដំបូងនៃការអភិវឌ្ឍន៍សេវាកម្ម ជាក្បួន Liquibase ត្រូវបានប្រើជាការពឹងផ្អែកខាងក្រៅ ហើយការធ្វើចំណាកស្រុកទាំងអស់ត្រូវបានដំណើរការនៅពេលដែលកម្មវិធីចាប់ផ្តើម។ ទោះយ៉ាងណាក៏ដោយយូរ ៗ ទៅអ្នកអាចជំពប់ដួលលើករណីដូចខាងក្រោមៈ

• ការធ្វើចំណាកស្រុកក្លាយជាធំ ហើយចំណាយពេលយូរដើម្បីបញ្ចប់។
• មានតម្រូវការសម្រាប់ការធ្វើចំណាកស្រុកនៅក្នុងបរិស្ថានដែលបានចែកចាយ ជាឧទាហរណ៍ នៅលើម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យជាច្រើនក្នុងពេលដំណាលគ្នា។
  ក្នុងករណីនេះ ការអនុវត្តការធ្វើចំណាកស្រុកយូរពេកនឹងនាំឱ្យអស់ពេលនៅពេលដែលកម្មវិធីចាប់ផ្តើម។ លើសពីនេះ ការអនុវត្តការផ្លាស់ប្តូរទៅកម្មវិធីនីមួយៗដោយឡែកពីគ្នាអាចបណ្តាលឱ្យម៉ាស៊ីនមេផ្សេងៗគ្នាមិនសមកាលកម្ម។

របៀបសម្រេចចិត្ត

ក្នុងករណីបែបនេះ គម្រោងរបស់អ្នកមានទំហំធំរួចទៅហើយ ប្រហែលជាសូម្បីតែមនុស្សពេញវ័យ ហើយ Liquibase ចាប់ផ្តើមដើរតួជាឧបករណ៍ខាងក្រៅដាច់ដោយឡែក។ ការពិតគឺថា Liquibase ជាបណ្ណាល័យត្រូវបានចងក្រងជាឯកសារ jar ហើយអាចធ្វើការជាអ្នកអាស្រ័យនៅក្នុងគម្រោង ឬដោយឯករាជ្យ។

នៅក្នុងរបៀបឯករាជ្យ អ្នកអាចទុកការអនុវត្តនៃការធ្វើចំណាកស្រុកទៅកាន់បរិយាកាស CI/CD របស់អ្នក ឬទៅកាន់ស្មាដ៏រឹងមាំរបស់អ្នកគ្រប់គ្រងប្រព័ន្ធ និងអ្នកជំនាញផ្នែកដាក់ឱ្យប្រើប្រាស់។ ដើម្បីធ្វើដូចនេះអ្នកនឹងត្រូវការបន្ទាត់ពាក្យបញ្ជា Liquibase https://www.liquibase.org/documentation/command_line.html. នៅក្នុងរបៀបនេះ វាអាចចាប់ផ្តើមកម្មវិធីបាន បន្ទាប់ពីការធ្វើចំណាកស្រុកចាំបាច់ទាំងអស់ត្រូវបានអនុវត្ត។

សេចក្តីសន្និដ្ឋាន

ជាការពិត វាអាចមានឧបសគ្គជាច្រើនទៀតនៅពេលធ្វើការជាមួយការផ្ទេរទិន្នន័យ ហើយពួកគេជាច្រើនទាមទារវិធីសាស្រ្តប្រកបដោយភាពច្នៃប្រឌិត។ វាជាការសំខាន់ណាស់ដែលត្រូវយល់ថាប្រសិនបើអ្នកប្រើឧបករណ៍ត្រឹមត្រូវនោះ ភាគច្រើននៃបញ្ហាទាំងនេះអាចត្រូវបានជៀសវាង។ ជាពិសេស ខ្ញុំត្រូវដោះស្រាយរាល់បញ្ហាដែលបានរាយបញ្ជីក្នុងទម្រង់ផ្សេងៗគ្នា ហើយពួកគេខ្លះជាលទ្ធផលនៃកំហុសរបស់ខ្ញុំ។ ភាគច្រើនវាកើតឡើងដោយសារការមិនយកចិត្តទុកដាក់ ប៉ុន្តែពេលខ្លះដោយសារតែអសមត្ថភាពក្នុងការប្រើប្រាស់ឧបករណ៍។

ប្រភព: www.habr.com