របៀបបង្កើតការអភិវឌ្ឍន៍ក្នុងផ្ទះពេញលេញដោយប្រើបទពិសោធន៍ DevOps - VTB

ការអនុវត្ត DevOps ដំណើរការ។ យើងជឿជាក់លើរឿងនេះដោយខ្លួនឯង នៅពេលដែលយើងកាត់បន្ថយពេលវេលាដំឡើងការចេញផ្សាយ 10 ដង។ នៅក្នុងប្រព័ន្ធ FIS Profile ដែលយើងប្រើនៅ VTB ការដំឡើងឥឡូវត្រូវចំណាយពេល 90 នាទីជាជាង 10។ ពេលវេលាបង្កើតការចេញផ្សាយបានថយចុះពីពីរសប្តាហ៍ទៅពីរថ្ងៃ។ ចំនួននៃកំហុសក្នុងការអនុវត្តជាប់លាប់បានធ្លាក់ចុះដល់កម្រិតអប្បបរមា។ ដើម្បីគេចចេញពី "ពលកម្មដោយដៃ" និងលុបបំបាត់ការពឹងផ្អែកលើអ្នកលក់ យើងត្រូវធ្វើការជាមួយឈើច្រត់ និងស្វែងរកដំណោះស្រាយដែលមិនបានរំពឹងទុក។ ខាងក្រោមការកាត់នេះគឺជារឿងលម្អិតអំពីរបៀបដែលយើងកសាងការអភិវឌ្ឍន៍ផ្ទៃក្នុងពេញលេញ។

 

Prologue: DevOps គឺជាទស្សនវិជ្ជាមួយ។

ក្នុងរយៈពេលមួយឆ្នាំកន្លងមក យើងបានធ្វើការងារជាច្រើនដើម្បីរៀបចំការអភិវឌ្ឍន៍ផ្ទៃក្នុង និងការអនុវត្តការអនុវត្ត DevOps នៅ VTB៖

• យើងបានបង្កើតដំណើរការអភិវឌ្ឍន៍ផ្ទៃក្នុងសម្រាប់ប្រព័ន្ធចំនួន 12;
• យើងបានបើកដំណើរការបំពង់ចំនួន 15 ដែល XNUMX ត្រូវបាននាំយកទៅផលិត។
• សេណារីយ៉ូសាកល្បងស្វ័យប្រវត្តិចំនួន ១៤៤៥;
• យើងបានអនុវត្តការចេញផ្សាយមួយចំនួនដោយជោគជ័យដែលរៀបចំដោយក្រុមក្នុងផ្ទះ។

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

ដំបូងឡើយ ក្បួនដោះស្រាយការអនុវត្តហាក់ដូចជាសាមញ្ញ និងច្បាស់លាស់៖

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

ក្នុងអំឡុងពេលនេះ ក្រុមអភិវឌ្ឍន៍នៃទំហំដែលត្រូវការត្រូវតែអភិវឌ្ឍជំនាញ និងបង្កើនចំណែកនៃការរួមចំណែករបស់ខ្លួនក្នុងការចេញផ្សាយដល់កម្រិតដែលអាចទទួលយកបាន។ ហើយនោះហើយជាវា យើងអាចពិចារណាកិច្ចការដែលបានបញ្ចប់។

វាហាក់ដូចជាថានេះគឺជាផ្លូវសន្សំសំចៃថាមពលទាំងស្រុងទៅកាន់លទ្ធផលដែលត្រូវការ៖ នេះគឺជា DevOps នេះគឺជារង្វាស់នៃការអនុវត្តរបស់ក្រុម នេះគឺជាជំនាញដែលប្រមូលបាន... ប៉ុន្តែនៅក្នុងការអនុវត្ត យើងបានទទួលការបញ្ជាក់មួយទៀតថា DevOps នៅតែនិយាយអំពីទស្សនវិជ្ជា។ និងមិន "បានភ្ជាប់ទៅដំណើរការ gitlab, ansible, nexus និងបន្ថែមទៀតនៅក្នុងបញ្ជី។"

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

តើការអភិវឌ្ឍន៍ផ្ទះចាប់ផ្តើមនៅឯណា? 

វាមិនមែនជាប្រព័ន្ធដែលងាយស្រួលបំផុតក្នុងការធ្វើការជាមួយនោះទេ។ តាមស្ថាបត្យកម្ម វាគឺជា DBMS ដែលមិនមានទំនាក់ទំនងធំមួយ ដែលមានវត្ថុដែលអាចប្រតិបត្តិបានដាច់ដោយឡែកជាច្រើន (ស្គ្រីប នីតិវិធី បាច់។ ការឆ្លើយតប។ ការលំបាកផ្សេងទៀតគួរកត់សម្គាល់រួមមាន:

• ភាសាកម្រ (MUMPS);
• ចំណុចប្រទាក់កុងសូល;
• កង្វះនៃការរួមបញ្ចូលជាមួយឧបករណ៍ស្វ័យប្រវត្តិកម្មពេញនិយមនិងក្របខ័ណ្ឌ;
• បរិមាណទិន្នន័យរាប់សិបតេរ៉ាបៃ;
• ការផ្ទុកលើសពី 2 លានប្រតិបត្តិការក្នុងមួយម៉ោង;
• សារៈសំខាន់ - អាជីវកម្ម - សំខាន់។

ក្នុងពេលជាមួយគ្នានេះ មិនមានឃ្លាំងប្រភពកូដនៅខាងយើងទេ។ ទាំងអស់។ មានឯកសារ ប៉ុន្តែចំណេះដឹង និងសមត្ថភាពសំខាន់ៗទាំងអស់គឺស្ថិតនៅខាងអង្គការខាងក្រៅ។
យើងបានចាប់ផ្តើមធ្វើជាម្ចាស់នៃការអភិវឌ្ឍន៍ប្រព័ន្ធស្ទើរតែពីដំបូង ដោយគិតគូរពីលក្ខណៈពិសេសរបស់វា និងការចែកចាយទាប។ ចាប់ផ្តើមក្នុងខែតុលា ឆ្នាំ ២០១៨៖

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

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

ការធ្វើចំណាកស្រុកឃ្លាំង និងការធ្វើតេស្តស្វ័យប្រវត្តិ

ភារកិច្ចដំបូងរបស់ DevOps គឺឃ្លាំង។ យើងបានយល់ព្រមយ៉ាងឆាប់រហ័សលើការផ្តល់ការចូលប្រើប្រាស់ ប៉ុន្តែវាចាំបាច់ក្នុងការធ្វើចំណាកស្រុកពី SVN បច្ចុប្បន្នជាមួយនឹងសាខាមួយទៅកាន់ Git គោលដៅរបស់យើងជាមួយនឹងការផ្លាស់ប្តូរទៅជាគំរូនៃសាខាជាច្រើន និងការអភិវឌ្ឍន៍នៃ Git Flow ។ យើងក៏មានក្រុមចំនួន 2 ដែលមានហេដ្ឋារចនាសម្ព័ន្ធផ្ទាល់ខ្លួនរបស់ពួកគេ រួមទាំងផ្នែកនៃក្រុមអ្នកលក់នៅក្រៅប្រទេសផងដែរ។ ខ្ញុំត្រូវរស់នៅជាមួយ Gits ពីរ ហើយធានាឱ្យមានភាពស៊ីសង្វាក់គ្នា។ ក្នុង​ស្ថានភាព​បែប​នេះ វា​ជា​អំពើ​អាក្រក់​តិច​ជាង​ពីរ។

ការធ្វើចំណាកស្រុកនៃឃ្លាំងត្រូវបានពន្យារពេលម្តងហើយម្តងទៀត វាត្រូវបានបញ្ចប់ត្រឹមខែមេសា ដោយមានជំនួយពីសហការីពីជួរមុខ។ ជាមួយនឹង Git Flow យើងបានសម្រេចចិត្តរក្សាអ្វីៗឱ្យមានលក្ខណៈសាមញ្ញសម្រាប់ការចាប់ផ្តើម និងដោះស្រាយលើគ្រោងការណ៍បុរាណជាមួយនឹងកម្មវិធី hotfix បង្កើត និងចេញផ្សាយ។ ពួកគេបានសម្រេចចិត្តបោះបង់ចោលម្ចាស់ (ហៅកាត់ថាជាផលិតផល)។ ខាងក្រោម​នេះ​យើង​នឹង​ពន្យល់​ពី​មូលហេតុ​ដែល​ជម្រើស​នេះ​ក្លាយ​ជា​ជម្រើស​ល្អ​បំផុត​សម្រាប់​យើង។ ឃ្លាំងខាងក្រៅដែលជាកម្មសិទ្ធិរបស់អ្នកលក់ ដែលជាទូទៅសម្រាប់ក្រុមពីរត្រូវបានគេប្រើជាកម្មករ។ វាធ្វើសមកាលកម្មជាមួយឃ្លាំងខាងក្នុងតាមកាលវិភាគ។ ឥឡូវនេះជាមួយ Git និង Gitlab វាអាចដំណើរការដោយស្វ័យប្រវត្តិ។

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

របៀបដែលវាគឺ: គំរូមុនពេលស្វ័យប្រវត្តិកម្ម

គំរូដែលមានស្រាប់នៃដំណើរការអនុវត្តគឺជារឿងដាច់ដោយឡែក។ ការកែប្រែនីមួយៗត្រូវបានផ្ទេរដោយដៃជាកញ្ចប់ដំឡើងបន្ថែមដាច់ដោយឡែក។ បន្ទាប់បានមកការចុះឈ្មោះដោយដៃនៅក្នុង Jira និងការដំឡើងដោយដៃនៅលើបរិស្ថាន។ សម្រាប់កញ្ចប់បុគ្គល អ្វីគ្រប់យ៉ាងមើលទៅច្បាស់ ប៉ុន្តែជាមួយនឹងការរៀបចំនៃការចេញផ្សាយ អ្វីៗកាន់តែស្មុគស្មាញ។

ការជួបប្រជុំគ្នាត្រូវបានអនុវត្តនៅកម្រិតនៃការចែកចាយបុគ្គលដែលជាវត្ថុឯករាជ្យ។ ការផ្លាស់ប្តូរណាមួយគឺជាការចែកចាយថ្មី។ ក្នុងចំណោមរបស់ផ្សេងទៀត កំណែបច្ចេកទេស 60-70 ត្រូវបានបន្ថែមទៅកញ្ចប់ 10-15 នៃសមាសភាពនៃការចេញផ្សាយចម្បង - កំណែដែលទទួលបាននៅពេលបន្ថែមឬមិនរាប់បញ្ចូលអ្វីមួយពីការចេញផ្សាយ និងការឆ្លុះបញ្ចាំងពីការផ្លាស់ប្តូរនៃការលក់នៅខាងក្រៅការចេញផ្សាយ។

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

ដើម្បីទទួលបានកំណែដែលត្រូវការនៃកូដ ចាំបាច់ត្រូវធ្វើតាមលំដាប់ដំឡើងយ៉ាងតឹងរ៉ឹង ក្នុងអំឡុងពេលនោះវត្ថុត្រូវបានសរសេរឡើងវិញជាច្រើនដង ខ្លះ 10-12 ដង។

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

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

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

ការអាប់ដេតដំបូង៖ ធ្វើការដំឡើង និងការចែកចាយ

ស្វ័យប្រវត្តិកម្មបានចាប់ផ្តើមដោយការបញ្ជូនលេខកូដតាមបំពង់តាមផ្លូវនេះ៖

• ទទួលយកការដឹកជញ្ជូនដែលបានបញ្ចប់ពីការផ្ទុក;
• ដំឡើងវានៅលើបរិស្ថានជាក់លាក់;
• ដំណើរការ autotests;
• វាយតម្លៃលទ្ធផលនៃការដំឡើង;
• ហៅបំពង់បង្ហូរខាងក្រោមនៅផ្នែកម្ខាងនៃពាក្យបញ្ជាសាកល្បង។

បំពង់បង្ហូរប្រេងបន្ទាប់គួរតែចុះឈ្មោះកិច្ចការនៅក្នុង Jira ហើយរង់ចាំការចែកចាយពាក្យបញ្ជាទៅកាន់រង្វិលជុំសាកល្បងដែលបានជ្រើសរើស ដែលអាស្រ័យលើពេលវេលានៃការអនុវត្តភារកិច្ច។ កេះ - លិខិតអំពីការត្រៀមខ្លួនសម្រាប់ការដឹកជញ្ជូនទៅកាន់អាសយដ្ឋានដែលបានផ្តល់ឱ្យ។ នេះជាការពិតណាស់ ជាឈើច្រត់ជាក់ស្តែង ប៉ុន្តែខ្ញុំត្រូវចាប់ផ្តើមនៅកន្លែងណាមួយ។ នៅខែឧសភា ឆ្នាំ 2019 ការផ្ទេរលេខកូដបានចាប់ផ្តើមជាមួយនឹងការត្រួតពិនិត្យបរិស្ថានរបស់យើង។ ដំណើរការបានចាប់ផ្តើមហើយ អ្វីដែលនៅសេសសល់គឺត្រូវនាំវាទៅជាទម្រង់សមរម្យ៖

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

បន្ទាប់ពីនេះមានជំហានដែលមានរួចហើយដើម្បីពិនិត្យមើលនិងផ្ទេរលេខកូដដើម្បីបើកដំណើរការបំពង់និងប្រមូលផ្តុំនៅខាងរបស់យើង។

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

ដំណោះស្រាយចុងក្រោយ៖ កញ្ចប់ដំឡើងបន្ថែម 

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

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

នៅ​សល់​តែ​ជាង​មួយ​ខែ​ទៀត គ្រឿង​ផ្គត់ផ្គង់​ដែល​រើស​ដោយ​ដៃ​បាន​ប្រាប់​យ៉ាង​ច្បាស់​ថា​ពេល​វេលា​ជិត​អស់​ហើយ។ ពួក​គេ​បាន​សម្រេច​ចិត្ត​ធ្វើ​ការ​សាង​សង់​ពី​សាខា​ចេញ ប៉ុន្តែ​ហេតុ​អ្វី​បាន​ជា​ត្រូវ​បំបែក​វា? យើងមិនមាន Prod-like ទេ ហើយសាខាដែលមានស្រាប់គឺមិនល្អទេ - មានលេខកូដដែលមិនចាំបាច់ច្រើន។ យើង​ត្រូវ​កាត់​ការ​ចូលចិត្ត​ផលិតផល​ជា​បន្ទាន់ ហើយ​នេះ​គឺ​ជាង​បី​ពាន់​ការ​ប្រព្រឹត្ត។ ការប្រមូលផ្តុំដោយដៃមិនមែនជាជម្រើសទាល់តែសោះ។ យើង​បាន​គូរ​ចេញ​នូវ​ស្គ្រីប​ដែល​ដំណើរការ​តាម​កំណត់​ហេតុ​នៃ​ការ​ដំឡើង​ផលិតផល និង​ប្រមូល​ការ​សន្យា​ទៅ​សាខា។ លើកទីបីវាដំណើរការបានត្រឹមត្រូវ ហើយបន្ទាប់ពី "បញ្ចប់ដោយឯកសារ" សាខាបានរួចរាល់។ 

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

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

បញ្ហាប្រឈមមួយបន្ថែមទៀតគឺចំនួនដ៏ច្រើននៃការមិនចេញផ្សាយដែលត្រូវតែយកមកពិចារណា។ ប៉ុន្តែជាមួយនឹងសាខាដូច Prod និង Rebase កិច្ចការនេះបានក្លាយជាតម្លាភាព។

លើកដំបូង រហ័ស និងគ្មានកំហុស

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

គួរឱ្យភ្ញាក់ផ្អើល ការចេញផ្សាយទាំងមូលដែលមានវត្ថុជាង 800 បានចាប់ផ្តើមត្រឹមត្រូវ ជាលើកដំបូង និងត្រឹមតែ 10 នាទីប៉ុណ្ណោះ។ យើង​បាន​ចំណាយ​ពេល​មួយ​ម៉ោង​ដើម្បី​ពិនិត្យ​មើល​កំណត់​ហេតុ​ដើម្បី​រក​កំហុស ប៉ុន្តែ​រក​មិន​ឃើញ​ទេ។

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

ឥទ្ធិពលបន្ថែមពីឥទ្ធិពលកកកុញគឺការកើនឡើងនៃគុណភាពនៃការផ្គុំ និងការធ្វើតេស្ត។ ដោយសារតែការដំឡើងជាច្រើននៃការចេញផ្សាយពេញលេញ កំហុសក្នុងការសាងសង់ និងកំហុសក្នុងការដាក់ពង្រាយត្រូវបានកំណត់ក្នុងលក្ខណៈទាន់ពេលវេលា។ ការធ្វើតេស្តនៅក្នុងការកំណត់រចនាសម្ព័ន្ធការចេញផ្សាយពេញលេញបានធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីកំណត់បន្ថែមនូវពិការភាពនៅក្នុងឥទ្ធិពលទៅវិញទៅមកនៃវត្ថុដែលមិនលេចឡើងកំឡុងពេលដំឡើងបន្ថែម។ វាពិតជាជោគជ័យ ជាពិសេសដោយសារការរួមចំណែក 57% របស់យើងក្នុងការចេញផ្សាយ។

លទ្ធផលនិងការសន្និដ្ឋាន

ក្នុងរយៈពេលតិចជាងមួយឆ្នាំ យើងបានគ្រប់គ្រង៖

• កសាងការអភិវឌ្ឍន៍ផ្ទៃក្នុងពេញលេញដោយប្រើប្រព័ន្ធកម្រនិងអសកម្ម;
• លុបបំបាត់ភាពអាស្រ័យរបស់អ្នកលក់សំខាន់;
• បើកដំណើរការ CI/CD សម្រាប់កេរ្តិ៍ដំណែលដែលមិនរាក់ទាក់ខ្លាំង។
• បង្កើនដំណើរការអនុវត្តទៅកម្រិតបច្ចេកទេសថ្មី;
• កាត់បន្ថយពេលវេលាដាក់ពង្រាយយ៉ាងសំខាន់;
• កាត់បន្ថយចំនួននៃកំហុសក្នុងការអនុវត្តយ៉ាងសំខាន់;
• ប្រកាសខ្លួនឯងដោយទំនុកចិត្តថាជាអ្នកជំនាញអភិវឌ្ឍន៍ឈានមុខគេ។

ជាការពិតណាស់ ភាគច្រើននៃអ្វីដែលត្រូវបានពណ៌នាមើលទៅហាក់ដូចជាឆ្កួតៗ ប៉ុន្តែទាំងនេះគឺជាលក្ខណៈពិសេសនៃប្រព័ន្ធ និងការកំណត់ដំណើរការដែលមាននៅក្នុងវា។ នៅពេលនេះ ការផ្លាស់ប្តូរបានប៉ះពាល់ដល់ផលិតផល និងសេវាកម្មរបស់ IS Profile (គណនីមេ កាតផ្លាស្ទិច គណនីសន្សំ ប្រាក់កម្ចីសាច់ប្រាក់) ប៉ុន្តែវិធីសាស្រ្តអាចត្រូវបានអនុវត្តចំពោះ IS ណាមួយដែលភារកិច្ចនៃការអនុវត្ត DevOps ត្រូវបានកំណត់។ គំរូប្រមូលផ្ដុំអាចត្រូវបានចម្លងដោយសុវត្ថិភាពសម្រាប់ការអនុវត្តជាបន្តបន្ទាប់ (រួមទាំងការមិនចេញផ្សាយ) ពីការចែកចាយជាច្រើន។

ប្រភព: www.habr.com