របៀបដែលយើងចេញផ្សាយបំណះកម្មវិធីនៅក្នុង GitLab

នៅ GitLab យើងដំណើរការជួសជុលកម្មវិធីតាមពីរវិធី៖ ដោយដៃ និងដោយស្វ័យប្រវត្តិ។ សូមអានបន្ត ដើម្បីស្វែងយល់អំពីការងាររបស់អ្នកគ្រប់គ្រងការចេញផ្សាយក្នុងការបង្កើត និងផ្តល់ព័ត៌មានថ្មីៗសំខាន់ៗ តាមរយៈការដាក់ឱ្យប្រើប្រាស់ដោយស្វ័យប្រវត្តិទៅកាន់ gitlab.com ក៏ដូចជាបំណះសម្រាប់អ្នកប្រើប្រាស់ដើម្បីធ្វើការជាមួយនឹងការដំឡើងរបស់ពួកគេផ្ទាល់។

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

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

«យើងធានាថាអ្វីគ្រប់យ៉ាងដែលអ្នកអភិវឌ្ឍន៍បង្កើតត្រូវបានដាក់ពង្រាយទៅគ្រប់មជ្ឈដ្ឋានជារៀងរាល់ថ្ងៃ មុនពេលដាក់ឱ្យប្រើប្រាស់ទៅកាន់ GitLab.com", ពន្យល់ Marin Jankovki, អ្នកគ្រប់គ្រងបច្ចេកទេសជាន់ខ្ពស់, នាយកដ្ឋានហេដ្ឋារចនាសម្ព័ន្ធ។ "គិតពីការចេញផ្សាយសម្រាប់ការដំឡើងរបស់អ្នកជារូបថតសម្រាប់ការដាក់ពង្រាយ gitlab.com ដែលយើងបានបន្ថែមជំហានដាច់ដោយឡែកដើម្បីបង្កើតកញ្ចប់មួយ ដូច្នេះអ្នកប្រើប្រាស់របស់យើងអាចប្រើវាដើម្បីដំឡើងនៅលើការដំឡើងរបស់ពួកគេ"។

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

ក្រុមចែកចាយកំពុងធ្វើការយ៉ាងស្វិតស្វាញដើម្បីធ្វើស្វ័យប្រវត្តិកម្មភាគច្រើននៃដំណើរការដែលពាក់ព័ន្ធនឹងការបង្កើតការចេញផ្សាយដើម្បីកាត់បន្ថយ MTTP (មានន័យថាពេលវេលាផលិត ពោលគឺពេលវេលាចំណាយលើការផលិត) រយៈពេលពីដំណើរការសំណើបញ្ចូលគ្នាដោយអ្នកអភិវឌ្ឍន៍ទៅការដាក់ឱ្យប្រើប្រាស់នៅលើ gitlab.com ។

«គោលដៅរបស់ក្រុមដឹកជញ្ជូនគឺដើម្បីធ្វើឱ្យប្រាកដថាយើងអាចផ្លាស់ទីបានលឿនក្នុងនាមជាក្រុមហ៊ុន ឬយ៉ាងហោចណាស់ធ្វើឱ្យមនុស្សធ្វើការលឿនជាងមុន។Marin និយាយ។

ទាំងអតិថិជន gitlab.com និងអ្នកប្រើប្រាស់ការដំឡើងរបស់ពួកគេទទួលបានអត្ថប្រយោជន៍ពីកិច្ចខិតខំប្រឹងប្រែងរបស់ក្រុមចែកចាយដើម្បីកាត់បន្ថយពេលវេលាវដ្ត និងបង្កើនល្បឿននៃការដាក់ឱ្យប្រើប្រាស់។ នៅក្នុងអត្ថបទនេះ យើងនឹងពន្យល់ពីភាពស្រដៀងគ្នា និងភាពខុសគ្នារវាងវិធីសាស្រ្តទាំងពីរនេះ។ បញ្ហាហើយយើងក៏នឹងពណ៌នាអំពីរបៀបដែលក្រុមចែកចាយរបស់យើងរៀបចំបំណះសម្រាប់អ្នកប្រើប្រាស់ដែលកំពុងដំណើរការនៅលើគេហទំព័រ និងរបៀបដែលយើងរក្សា gitlab.com ឱ្យទាន់សម័យដោយប្រើការដាក់ឱ្យប្រើប្រាស់ដោយស្វ័យប្រវត្តិ។

តើអ្នកគ្រប់គ្រងការចេញផ្សាយធ្វើអ្វី?

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

Marin ពន្យល់ថា ការចេញផ្សាយការដំឡើងដោយខ្លួនឯង និងការចេញផ្សាយ gitlab.com ប្រើលំហូរការងារស្រដៀងគ្នា ប៉ុន្តែដំណើរការនៅពេលផ្សេងគ្នា។

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

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

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

វាទាំងអស់អំពីការជួសជុល

តើអ្វីជាបំណះ ហើយហេតុអ្វីបានជាយើងត្រូវការវា?

អ្នកគ្រប់គ្រងការចេញផ្សាយសម្រេចចិត្តថាតើត្រូវចេញផ្សាយការជួសជុលដោយផ្អែកលើភាពធ្ងន់ធ្ងរនៃកំហុស។

កំហុសប្រែប្រួលអាស្រ័យលើភាពធ្ងន់ធ្ងររបស់វា។ ដូច្នេះ កំហុស S4 ឬ S3 អាចមានលក្ខណៈទាន់សម័យ ដូចជាការផ្លាស់ទីលំនៅរបស់ភីកសែល ឬរូបតំណាង។ Marin ពន្យល់ថា នេះមិនសំខាន់ទេ ប៉ុន្តែវាមិនមានផលប៉ះពាល់ខ្លាំងដល់ដំណើរការការងាររបស់នរណាម្នាក់ទេ ដែលមានន័យថាលទ្ធភាពដែលការជួសជុលនឹងត្រូវបានបង្កើតឡើងសម្រាប់កំហុស S3 ឬ S4 បែបនេះគឺតូច។

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

នៅពេលដែលបំណះសម្រាប់ភាពងាយរងគ្រោះ S1 ឬ S2 រួចរាល់ អ្នកគ្រប់គ្រងការចេញផ្សាយចាប់ផ្តើមបញ្ចេញបំណះ។

ឧទាហរណ៍ បំណះ GitLab 12.10.1 ត្រូវបានបង្កើតឡើង បន្ទាប់ពីបញ្ហាការទប់ស្កាត់ជាច្រើនត្រូវបានកំណត់អត្តសញ្ញាណ ហើយអ្នកអភិវឌ្ឍន៍បានដោះស្រាយបញ្ហាមូលដ្ឋានដែលបណ្តាលឱ្យពួកគេ។ អ្នកគ្រប់គ្រងការចេញផ្សាយបានវាយតម្លៃភាពត្រឹមត្រូវនៃកម្រិតភាពធ្ងន់ធ្ងរដែលបានកំណត់ ហើយបន្ទាប់ពីការបញ្ជាក់ ដំណើរការនៃការចេញផ្សាយការជួសជុលត្រូវបានចាប់ផ្តើម ដែលរួចរាល់ក្នុងរយៈពេល XNUMX ម៉ោងបន្ទាប់ពីបញ្ហានៃការទប់ស្កាត់ត្រូវបានរកឃើញ។

នៅពេលដែល S4, S3 និង S2 កកកុញច្រើន អ្នកគ្រប់គ្រងការចេញផ្សាយពិនិត្យមើលបរិបទដើម្បីកំណត់ភាពបន្ទាន់នៃការចេញផ្សាយការជួសជុល ហើយនៅពេលដែលចំនួនជាក់លាក់មួយត្រូវបានឈានដល់ ពួកវាទាំងអស់ត្រូវបានបញ្ចូលគ្នា និងបញ្ចេញ។ ការជួសជុលក្រោយការចេញផ្សាយ ឬការអាប់ដេតសុវត្ថិភាពត្រូវបានសង្ខេបនៅក្នុងការបង្ហោះប្លុក។

របៀបដែលអ្នកគ្រប់គ្រងការចេញផ្សាយបង្កើតបំណះ

យើងប្រើ GitLab CI និងលក្ខណៈពិសេសផ្សេងទៀតដូចជា ChatOps របស់យើងដើម្បីបង្កើតបំណះ។ អ្នកគ្រប់គ្រងការចេញផ្សាយធ្វើឱ្យមានការចេញផ្សាយការជួសជុលដោយធ្វើឱ្យក្រុម ChatOps សកម្មនៅលើឆានែលខាងក្នុងរបស់យើង។ #releases នៅ Slack ។

/chatops run release prepare 12.10.1

ChatOps ដំណើរការនៅក្នុង Slack ដើម្បីបង្ករព្រឹត្តិការណ៍ផ្សេងៗ ដែលបន្ទាប់មកត្រូវបានដំណើរការ និងប្រតិបត្តិដោយ GitLab ។ ជាឧទាហរណ៍ ក្រុមចែកចាយបានបង្កើត ChatOps ដើម្បីធ្វើស្វ័យប្រវត្តិកម្មផ្សេងៗដើម្បីបញ្ចេញបំណះ។

នៅពេលដែលអ្នកគ្រប់គ្រងការចេញផ្សាយចាប់ផ្តើមក្រុម ChatOps នៅក្នុង Slack ការងារដែលនៅសល់កើតឡើងដោយស្វ័យប្រវត្តិនៅក្នុង GitLab ដោយប្រើ CICD ។ មានការទំនាក់ទំនងពីរផ្លូវរវាង ChatOps នៅក្នុង Slack និង GitLab កំឡុងពេលដំណើរការចេញផ្សាយ ដោយសារអ្នកគ្រប់គ្រងការចេញផ្សាយធ្វើឱ្យដំណើរការជំហានសំខាន់ៗមួយចំនួននៅក្នុងដំណើរការ។

វីដេអូខាងក្រោមបង្ហាញពីដំណើរការបច្ចេកទេសនៃការរៀបចំបំណះសម្រាប់ GitLab ។

របៀបដែលការដាក់ពង្រាយដោយស្វ័យប្រវត្តិដំណើរការនៅលើ gitlab.com

ដំណើរការ និងឧបករណ៍ដែលប្រើដើម្បីធ្វើបច្ចុប្បន្នភាព gitlab.com គឺស្រដៀងទៅនឹងអ្វីដែលប្រើដើម្បីបង្កើតបំណះ។ ការធ្វើបច្ចុប្បន្នភាព gitlab.com តម្រូវឱ្យមានការងារដោយដៃតិចជាងមុនពីទស្សនៈរបស់អ្នកគ្រប់គ្រងការចេញផ្សាយ។

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

Marin និយាយថា "ដូច្នេះយើងមានការដាក់ពង្រាយជាច្រើនដែលកំពុងដំណើរការនៅក្នុងបរិស្ថានផ្សេងៗគ្នាមុន gitlab.com ហើយបន្ទាប់ពីបរិស្ថានទាំងនោះមានរូបរាងល្អ ហើយការធ្វើតេស្តបង្ហាញលទ្ធផលល្អ អ្នកគ្រប់គ្រងការចេញផ្សាយចាប់ផ្តើមសកម្មភាពដាក់ពង្រាយ gitlab.com" ។

បច្ចេកវិទ្យា CICD សម្រាប់គាំទ្រការអាប់ដេត gitlab.com ធ្វើឱ្យដំណើរការទាំងមូលដោយស្វ័យប្រវត្តិដល់ចំណុចដែលអ្នកគ្រប់គ្រងការចេញផ្សាយត្រូវតែចាប់ផ្តើមការដាក់ពង្រាយបរិស្ថានផលិតកម្មដោយដៃទៅកាន់ gitlab.com ។

Marin រៀបរាប់លម្អិតអំពីដំណើរការអាប់ដេត gitlab.com នៅក្នុងវីដេអូខាងក្រោម។

តើក្រុមដឹកជញ្ជូនធ្វើអ្វីទៀត?

ភាពខុសគ្នាសំខាន់រវាងដំណើរការអាប់ដេត gitlab.com និងការចេញផ្សាយបំណះដល់អតិថិជននៅក្នុងផ្ទះគឺថា ដំណើរការចុងក្រោយត្រូវការពេលវេលា និងការងារដោយដៃកាន់តែច្រើនពីអ្នកគ្រប់គ្រងការចេញផ្សាយ។

Marin និយាយថា "ពេលខ្លះយើងពន្យារពេលការចេញផ្សាយបំណះដល់អតិថិជនជាមួយនឹងការដំឡើងរបស់ពួកគេដោយសារតែបញ្ហាដែលបានរាយការណ៍ បញ្ហាឧបករណ៍ និងដោយសារតែមានភាពខុសប្លែកគ្នាជាច្រើនដែលចាំបាច់ត្រូវយកមកពិចារណានៅពេលបញ្ចេញបំណះតែមួយ"។

គោលដៅមួយក្នុងចំនោមគោលដៅរយៈពេលខ្លីរបស់ក្រុមចែកចាយគឺដើម្បីកាត់បន្ថយចំនួនការងារដោយដៃនៅលើផ្នែកនៃអ្នកគ្រប់គ្រងការចេញផ្សាយដើម្បីបង្កើនល្បឿននៃការចេញផ្សាយ។ ក្រុមការងារកំពុងធ្វើការដើម្បីសម្រួល សម្រួល និងធ្វើស្វ័យប្រវត្តិកម្មដំណើរការចេញផ្សាយ ដែលនឹងជួយដោះស្រាយបញ្ហានៃភាពធ្ងន់ធ្ងរទាប (S3 និង S4, ប្រហែល អ្នកបកប្រែ) ការផ្តោតលើល្បឿនគឺជាសូចនាករការអនុវត្តដ៏សំខាន់មួយ៖ វាចាំបាច់ក្នុងការកាត់បន្ថយ MTTP - ពេលវេលាពីការទទួលបានសំណើបញ្ចូលគ្នាដើម្បីដាក់ពង្រាយលទ្ធផលទៅ gitlab.com - ពី 50 ម៉ោងបច្ចុប្បន្នទៅ 8 ម៉ោង។

ក្រុមចែកចាយក៏កំពុងធ្វើការលើការផ្ទេរ gitlab.com ទៅកាន់ហេដ្ឋារចនាសម្ព័ន្ធដែលមានមូលដ្ឋានលើ Kubernetes ផងដែរ។

អ្នកនិពន្ធ n.b.៖ ប្រសិនបើអ្នកបានឮរួចហើយអំពីបច្ចេកវិទ្យា Kubernetes (ហើយខ្ញុំមិនមានការសង្ស័យទេថាអ្នកមាន) ប៉ុន្តែមិនទាន់បានប៉ះវាដោយដៃរបស់អ្នកទេ ខ្ញុំសូមណែនាំឱ្យចូលរួមក្នុងវគ្គសិក្សាដែលពឹងផ្អែកខ្លាំងលើអ៊ីនធឺណិត មូលដ្ឋាន Kubernetesដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃទី 28-30 ខែកញ្ញា និង Kubernetes Megaដែលនឹងប្រព្រឹត្តទៅនៅថ្ងៃទី ១៤-១៦ ខែតុលា។ នេះនឹងអនុញ្ញាតឱ្យអ្នករុករក និងធ្វើការជាមួយបច្ចេកវិទ្យាប្រកបដោយទំនុកចិត្ត។

ទាំងនេះគឺជាវិធីសាស្រ្តពីរដែលបន្តគោលដៅដូចគ្នា៖ ការផ្តល់ការអាប់ដេតយ៉ាងឆាប់រហ័ស ទាំងសម្រាប់ gitlab.com និងសម្រាប់អតិថិជននៅឯកន្លែងរបស់ពួកគេ។

តើមានគំនិត ឬអនុសាសន៍សម្រាប់យើងទេ?

អ្នកគ្រប់គ្នាត្រូវបានស្វាគមន៍ក្នុងការរួមចំណែកដល់ GitLab ហើយយើងស្វាគមន៍មតិកែលម្អពីអ្នកអានរបស់យើង។ ប្រសិនបើអ្នកមានគំនិតណាមួយសម្រាប់ក្រុមដឹកជញ្ជូនរបស់យើង សូមកុំស្ទាក់ស្ទើរ បង្កើតសំណើមួយ។ ជាមួយនឹងការជូនដំណឹង team: Delivery.

ប្រភព: www.habr.com