ការអនុវត្ត DevOps ល្អបំផុតសម្រាប់អ្នកអភិវឌ្ឍន៍។ Anton Boyko (2017)

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

អនុញ្ញាតឱ្យខ្ញុំណែនាំខ្លួនខ្ញុំ ខ្ញុំទទួលស្គាល់យ៉ាងពេញលេញថាមានមនុស្សនៅក្នុងបន្ទប់ដែលមិនស្គាល់ខ្ញុំ។ ឈ្មោះរបស់ខ្ញុំគឺ Anton Boyko ខ្ញុំជា Microsoft Azure MVP ។ តើ MVP ជាអ្វី? នេះគឺជា Model-View-Presenter។ Model-View-Presenter គឺពិតជាខ្ញុំ។

លើសពីនេះ បច្ចុប្បន្នខ្ញុំកាន់តំណែងជាស្ថាបត្យករដំណោះស្រាយនៅ Ciklum ។ ហើយថ្មីៗនេះ ខ្ញុំបានទិញដែនដ៏ស្រស់ស្អាតមួយដោយខ្លួនឯង ហើយខ្ញុំបានអាប់ដេតអ៊ីមែលរបស់ខ្ញុំ ដែលជាធម្មតាខ្ញុំបង្ហាញនៅឯបទបង្ហាញ។ អ្នកអាចសរសេរមកខ្ញុំតាមរយៈ៖ ខ្ញុំ [ឆ្កែ] byokoant.pro ។ អ្នកអាចផ្ញើអ៊ីមែលមកខ្ញុំជាមួយនឹងសំណួរ។ ជាធម្មតាខ្ញុំឆ្លើយពួកគេ។ រឿងតែមួយគត់គឺថា ខ្ញុំមិនចង់ទទួលសំណួរតាមអ៊ីមែលដែលទាក់ទងនឹងប្រធានបទពីរ៖ នយោបាយ និងសាសនា។ អ្នកអាចសរសេរមកខ្ញុំអំពីអ្វីៗផ្សេងទៀតតាមអ៊ីមែល។ ពេលវេលានឹងកន្លងផុតទៅ ខ្ញុំនឹងឆ្លើយ។

ពាក្យពីរបីអំពីខ្លួនអ្នក៖

• ខ្ញុំបាននៅក្នុងវិស័យនេះអស់រយៈពេល 10 ឆ្នាំមកហើយ។
• ខ្ញុំបានធ្វើការនៅ Microsoft ។
• ខ្ញុំជាបិតាស្ថាបនិកនៃសហគមន៍ Azure អ៊ុយក្រែន ដែលយើងបានបង្កើតនៅកន្លែងណាមួយក្នុងឆ្នាំ 2014 ។ ហើយយើងនៅតែមានវា ហើយកំពុងអភិវឌ្ឍវា។
• ខ្ញុំក៏ជាឪពុករបស់ស្ថាបនិកនៃសន្និសីទ Azure ដែលយើងកំពុងធ្វើជាម្ចាស់ផ្ទះនៅអ៊ុយក្រែន។
• ខ្ញុំក៏ជួយរៀបចំ Global Azure Bootcamp នៅ Kyiv ផងដែរ។
• ដូចដែលខ្ញុំបាននិយាយ ខ្ញុំជា Microsoft Azure MVP ។
• ខ្ញុំ​និយាយ​នៅ​សន្និសីទ​ញឹកញាប់។ ខ្ញុំ​ពិត​ជា​ចូល​ចិត្ត​និយាយ​នៅ​សន្និសីទ។ កាល​ពី​ឆ្នាំ​មុន ខ្ញុំ​អាច​សម្ដែង​បាន​ប្រហែល ៤០​ដង។ ប្រសិនបើអ្នកឆ្លងកាត់អ៊ុយក្រែន បេឡារុស ប៉ូឡូញ ប៊ុលហ្គារី ស៊ុយអែត ដាណឺម៉ាក ហូឡង់ អេស្ប៉ាញ ឬផ្តល់ឱ្យឬយកប្រទេសផ្សេងទៀតនៅអឺរ៉ុប នោះវាពិតជាអាចទៅរួចដែលអ្នកទៅសន្និសីទដែលមានប្រធានបទពពកនៅក្នុងស្ទ្រីមរបស់វា។ អ្នកអាចឃើញខ្ញុំនៅក្នុងបញ្ជីអ្នកនិយាយ។
• ខ្ញុំក៏ជាអ្នកគាំទ្រ Star Trek ដែរ។

សូម​និយាយ​បន្តិច​អំពី​របៀបវារៈ។ របៀបវារៈរបស់យើងគឺសាមញ្ញណាស់៖

• យើងនឹងនិយាយអំពីអ្វីដែល DevOps ។ សូម​និយាយ​ថា​ហេតុ​អ្វី​បាន​ជា​នេះ​សំខាន់។ កាលពីមុន DevOps គឺជាពាក្យគន្លឹះដែលអ្នកបានសរសេរនៅលើប្រវត្តិរូបសង្ខេបរបស់អ្នក ហើយភ្លាមៗទទួលបានប្រាក់ខែ +500 ដុល្លារ។ ឥឡូវនេះអ្នកត្រូវសរសេរឧទាហរណ៍ blockchain នៅក្នុងប្រវត្តិរូបរបស់អ្នកដើម្បីទទួលបាន +500 ដុល្លារដល់ប្រាក់ខែរបស់អ្នក។
• ហើយបន្ទាប់មកនៅពេលដែលយើងយល់បន្តិចបន្តួចអំពីអ្វីដែលនេះគឺជា យើងនឹងនិយាយអំពីអ្វីដែលការអនុវត្ត DevOps ។ ប៉ុន្តែមិនច្រើនទេនៅក្នុងបរិបទនៃ DevOps ជាទូទៅ ប៉ុន្តែអំពីការអនុវត្ត DevOps ទាំងនោះដែលអាចចាប់អារម្មណ៍សម្រាប់អ្នកអភិវឌ្ឍន៍។ ខ្ញុំនឹងប្រាប់អ្នកពីមូលហេតុដែលពួកគេប្រហែលជាចាប់អារម្មណ៍ចំពោះអ្នក។ ខ្ញុំ​នឹង​ប្រាប់​អ្នក​ពី​មូលហេតុ​ដែល​អ្នក​គួរ​ធ្វើ​បែប​នេះ និង​របៀប​ដែល​វា​អាច​ជួយ​អ្នក​ឱ្យ​មាន​ការឈឺចាប់​តិច​ជាង​មុន​។

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

ប្រហែលជាប្រសិនបើអ្នកមិនអាចមានអារម្មណ៍ថាវាច្បាស់នៅក្នុង DevOps និងនាយកដ្ឋានប្រតិបត្តិការ អ្នកអាចគូរភាពស្រដៀងគ្នាជាមួយនាយកដ្ឋាន Dev និង QA ។ មានមនុស្សដែលបង្កើតកម្មវិធី ហើយមានមនុស្ស QA ដែលអាក្រក់តាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍។ ជាឧទាហរណ៍ ខ្ញុំដាក់លេខកូដដ៏អស្ចារ្យរបស់ខ្ញុំទៅឃ្លាំង ហើយមានអ្នកមើលងាយមួយចំនួនដែលអង្គុយនៅទីនោះ ដែលប្រគល់លេខកូដនេះមកខ្ញុំ ហើយនិយាយថាលេខកូដរបស់អ្នកមិនល្អ។

ទាំងអស់នេះកើតឡើងដោយសារតែមនុស្សមិនទាក់ទងគ្នាទៅវិញទៅមក។ ហើយពួកគេបានបោះកញ្ចប់ខ្លះ កម្មវិធីខ្លះទៅគ្នាទៅវិញទៅមក តាមរយៈជញ្ជាំងនៃការយល់ច្រលំ ហើយព្យាយាមធ្វើអ្វីមួយជាមួយពួកគេ។

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

ហើយនៅពេលដែលយើងនិយាយអំពី DevOps នរណាម្នាក់នឹងប្រាប់អ្នកថា DevOps គឺជាពេលដែលគម្រោងមានការរួមបញ្ចូលជាបន្តបន្ទាប់។ នរណាម្នាក់នឹងនិយាយថា DevOps គឺប្រសិនបើគម្រោងអនុវត្ត "ហេដ្ឋារចនាសម្ព័ន្ធជាកូដ" ។ នរណាម្នាក់នឹងនិយាយថាជំហានដំបូងទៅកាន់ DevOps គឺការបំបែកមុខងារ ទង់មុខងារ។

សំខាន់ នេះជាការពិតទាំងអស់តាមវិធីរបស់វា។ ប៉ុន្តែទាំងនេះគ្រាន់តែជាការអនុវត្តចុងក្រោយដែលយើងមាន។ មុនពេលបន្តទៅការអនុវត្តទាំងនេះ ខ្ញុំស្នើឱ្យមើលស្លាយនេះ ដែលបង្ហាញពី 3 ដំណាក់កាលនៃការអនុវត្តវិធីសាស្រ្ត Dev-Ops នៅក្នុងគម្រោងរបស់អ្នក នៅក្នុងក្រុមហ៊ុនរបស់អ្នក។

ស្លាយនេះក៏មានឈ្មោះក្រៅផ្លូវការទីពីរផងដែរ។ អ្នកអាចស្វែងរកតាមអ៊ិនធរណេតដើម្បីរកមើលថាតើ Musketeers 3 នាក់នៃ DevOps ជាអ្វី។ វាអាចទៅរួចដែលអ្នកនឹងរកឃើញអត្ថបទនេះ។ ហេតុអ្វីបានជា 3 Musketeers? ខាងក្រោមវានិយាយថា៖ មនុស្ស ដំណើរការ និងផលិតផល i.e. PPP - Porthos, Porthos និង Porthos ។ នេះគឺជា Musketeers 3 នាក់របស់ DevOps ។ អត្ថបទនេះពិពណ៌នាលម្អិតបន្ថែមទៀតថាហេតុអ្វីបានជាវាសំខាន់ និងអ្វីដែលវារួមបញ្ចូល។

នៅពេលអ្នកចាប់ផ្តើមអនុវត្តវប្បធម៌ DevOps វាមានសារៈសំខាន់ខ្លាំងណាស់ដែលវាត្រូវបានអនុវត្តតាមលំដាប់ដូចខាងក្រោម។

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

សន្និសីទរបស់យើងត្រូវបានគេហៅថា DotNet Fest ។ ហើយដូចដែលអ្នករៀបចំបានប្រាប់ខ្ញុំ យើងបានអញ្ជើញទស្សនិកជនរបស់អ្នកអភិវឌ្ឍន៍នៅទីនេះជាចម្បង ដូច្នេះហើយខ្ញុំសង្ឃឹមថាមនុស្សភាគច្រើននៅក្នុងបន្ទប់គឺចូលរួមក្នុងការអភិវឌ្ឍន៍។

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

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

តើ QAs ចង់បានអ្វីជាងគេ? ខ្ញុំមិនដឹងថាតើពួកគេនៅក្នុងសាល។ វាពិបាកសម្រាប់ខ្ញុំក្នុងការនិយាយថាខ្ញុំចង់បាន QA ព្រោះខ្ញុំមិនធ្លាប់មាន។ ហើយ​គ្មាន​ការ​ប្រមាថ​ចំពោះ​បុរស​នោះ​ទេ វា​នឹង​ត្រូវ​បាន​គេ​និយាយ​ថា​ខ្ញុំ​សង្ឃឹម​ថា​ខ្ញុំ​នឹង​មិន​ដែល​នឹង​។ ប៉ុន្តែមិនមែនសម្រាប់ហេតុផលដែលខ្ញុំចាត់ទុកការងាររបស់ពួកគេគ្មានន័យ និងគ្មានប្រយោជន៍នោះទេ ប៉ុន្តែដោយសារតែខ្ញុំមិនបានចាត់ទុកខ្លួនឯងថាជាមនុស្សដែលអាចធ្វើការងារនេះប្រកបដោយប្រសិទ្ធភាព ដូច្នេះខ្ញុំក៏មិនព្យាយាមធ្វើវាដែរ។ ប៉ុន្តែតាមអ្វីដែលខ្ញុំយល់ អ្វីដែល QA មិនចូលចិត្តបំផុតគឺនឹងដំណើរការនៅពេលព្រឹក ដោយដំណើរការការធ្វើតេស្តតំរែតំរង់ជាបន្តបន្ទាប់ ដោយបោះជំហានលើកំហុសដដែលដែលពួកគេបានរាយការណ៍ទៅអ្នកអភិវឌ្ឍន៍ 3 ដងមុន ហើយនិយាយថា "តើអ្នកនឹងនៅពេលណា Monsieur D 'Artagnan, ជួសជុលកំហុសនេះ។' ហើយ Monsieur D'Artagnan ឆ្លើយគាត់ថា "បាទ បាទ បាទ ខ្ញុំបានជួសជុលវារួចហើយ" ។ ហើយតើវាកើតឡើងដោយរបៀបណាដែលខ្ញុំបានជួសជុលកំហុសមួយ និងបង្កើត 5 នៅតាមផ្លូវ។

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

ហើយនៅពេលដែលអ្នកពន្យល់មនុស្សថាពួកគេមានបំណងដោះស្រាយបញ្ហាដូចគ្នា អ្នកអាចបន្តទៅការរៀបចំដំណើរការជាផ្លូវការ។ វា​ពិតជា​សំខាន់ណាស់។ ហេតុអ្វី? ពីព្រោះនៅពេលដែលយើងនិយាយថា "ការធ្វើជាផ្លូវការ" វាជារឿងសំខាន់សម្រាប់អ្នកក្នុងការពិពណ៌នាអំពីរបៀបដែលដំណើរការរបស់អ្នកកើតឡើងយ៉ាងហោចណាស់នៅកន្លែងណាមួយនៅលើកន្សែង។ អ្នកត្រូវយល់ថា ប្រសិនបើអ្នកជាឧទាហរណ៍ ដាក់ពង្រាយទៅកាន់បរិស្ថាន QA ឬបរិយាកាសផលិតកម្ម នោះវាតែងតែកើតឡើងនៅក្នុងលំដាប់នេះ នៅដំណាក់កាលទាំងនេះដែលយើងដំណើរការ ឧទាហរណ៍ ការធ្វើតេស្តឯកតាស្វ័យប្រវត្តិ និងការធ្វើតេស្ត UI ។ បន្ទាប់ពីការដាក់ពង្រាយ យើងពិនិត្យមើលថាតើការដាក់ពង្រាយដំណើរការល្អឬមិនល្អ។ ប៉ុន្តែអ្នកមានបញ្ជីសកម្មភាពច្បាស់លាស់រួចហើយ ដែលត្រូវតែធ្វើឡើងម្តងហើយម្តងទៀត នៅពេលអ្នកដាក់ពង្រាយទៅផលិតកម្ម។

ហើយនៅពេលដែលដំណើរការរបស់អ្នកត្រូវបានធ្វើឱ្យជាផ្លូវការ តើអ្នកចាប់ផ្តើមជ្រើសរើសផលិតផលដែលនឹងជួយអ្នកឱ្យដំណើរការដោយស្វ័យប្រវត្តិនូវដំណើរការទាំងនេះដែរឬទេ។

ជាអកុសល ខ្ញុំឃើញរឿងនេះកើតឡើងជាញឹកញាប់។ នៅពេលនរណាម្នាក់ឮពាក្យ "DevOps" ពួកគេស្នើឱ្យដំឡើង Jenkins ភ្លាមៗ ព្រោះពួកគេជឿថា នៅពេលពួកគេដំឡើង Jenkins ពួកគេនឹងមាន DevOps ។ ពួកគេបានដំឡើង Jenkins អានអត្ថបទ "How to" នៅលើគេហទំព័រ Jenkins ព្យាយាមបញ្ចូលដំណើរការទៅក្នុងអត្ថបទ How to ទាំងនេះ ហើយបន្ទាប់មកបានមករកមនុស្ស ហើយពត់មនុស្សដោយនិយាយថាសៀវភៅនិយាយថាអ្នកត្រូវធ្វើវាតាមវិធីនេះ។ ដូច្នេះយើងធ្វើវាតាមរបៀបនេះ។

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

ចូរនិយាយអំពីការអនុវត្ត DevOps ជាទូទៅ។ តើពួកគេជាអ្វី? តើអ្វីជាភាពខុសគ្នា? តើធ្វើដូចម្តេចដើម្បីសាកល្បងពួកវា? ហេតុអ្វីបានជាពួកគេសំខាន់?

ការអនុវត្តដំបូងដែលអ្នកប្រហែលជាធ្លាប់លឺត្រូវបានគេហៅថា សមាហរណកម្មបន្ត។ ប្រហែលជាមាននរណាម្នាក់នៅក្នុងគម្រោងមានការរួមបញ្ចូលជាបន្តបន្ទាប់ (CI)។

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

តាមពិតការអនុវត្ត CI គឺគ្រាន់តែមានគោលបំណងបញ្ចូលកូដដែលមនុស្សផ្សេងគ្នាសរសេរទៅក្នុងប្រភេទនៃមូលដ្ឋានកូដតែមួយប៉ុណ្ណោះ។ អស់ហើយ។

រួមជាមួយ CI ជាធម្មតាមានការអនុវត្តផ្សេងទៀតនៅតាមផ្លូវ - ដូចជាការដាក់ពង្រាយបន្ត ការគ្រប់គ្រងការចេញផ្សាយ ប៉ុន្តែយើងនឹងនិយាយអំពីវានៅពេលក្រោយ។

CI ខ្លួនវាប្រាប់យើងថា មនុស្សផ្សេងគ្នាសរសេរកូដ ហើយកូដនេះត្រូវតែបញ្ចូលជាបន្តបន្ទាប់ទៅក្នុងមូលដ្ឋានកូដតែមួយ។

តើនេះផ្តល់អ្វីដល់យើង ហើយហេតុអ្វីវាសំខាន់? ប្រសិនបើយើងមាន DotNet នោះជាការល្អ វាជាភាសាដែលបានចងក្រង យើងអាចចងក្រងកម្មវិធីរបស់យើង។ ប្រសិនបើវាចងក្រង នោះនេះគឺជាសញ្ញាល្អរួចទៅហើយ។ នេះ​មិន​មាន​ន័យ​អ្វី​នៅ​ឡើយ​ទេ ប៉ុន្តែ​វា​ជា​សញ្ញា​ល្អ​ដំបូង​ដែល​យើង​អាច​ចងក្រង​បាន។

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

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

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

ខ្ញុំនឹងប្រាប់អ្នកពីរឿងដ៏សោកសៅមួយពីជីវិតរបស់ខ្ញុំ។ តាំងពីយូរយារណាស់មកហើយ ដែលខ្ញុំនៅក្មេង និងសង្ហា។ ឥឡូវ​នេះ​ខ្ញុំ​នៅ​ក្មេង​ហើយ​ស្អាត​ហើយ​ឆ្លាត​ហើយ​សុភាព។ មួយរយៈមុនខ្ញុំស្ថិតនៅក្នុងគម្រោងមួយ។ យើងមានក្រុមធំមួយដែលមានអ្នកអភិវឌ្ឍន៍ប្រហែល 30 នាក់។ ហើយ​យើង​មាន​គម្រោង​សហគ្រាស​ធំ​មួយ​ដែល​បាន​អភិវឌ្ឍ​ប្រហែល​ 10 ឆ្នាំ។ ហើយយើងមានសាខាផ្សេងៗគ្នា។ នៅក្នុងឃ្លាំងយើងមានសាខាមួយដែលអ្នកអភិវឌ្ឍន៍បានដើរ។ ហើយមានសាខាមួយដែលបង្ហាញកំណែនៃកូដដែលកំពុងផលិត។

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

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

ប្រសិនបើ​យើង​មាន​ការអនុវត្ត​ការ​រួមបញ្ចូល​ជា​បន្តបន្ទាប់ នោះ​វា​អនុញ្ញាត​ឱ្យ​យើង​ពិនិត្យ​មើល​វា​ជាមួយ​នឹង​ឧបករណ៍​ស្វ័យប្រវត្តិ​ជាច្រើន​នៅទីនេះ និង​ឥឡូវនេះ ដរាបណា​ខ្ញុំ​បាន​សរសេរ​កូដ​របស់ខ្ញុំ។ នេះប្រហែលជាមិនផ្តល់ឱ្យខ្ញុំនូវរូបភាពពេញលេញទេ ប៉ុន្តែយ៉ាងណាក៏ដោយ វានឹងដកចេញនូវហានិភ័យមួយចំនួន។ ហើយប្រសិនបើមានកំហុសដែលអាចកើតមាន ខ្ញុំនឹងដឹងអំពីវាឥឡូវនេះ ពោលគឺក្នុងរយៈពេលពីរបីនាទី។ ខ្ញុំ​នឹង​មិន​ចាំបាច់​វិល​ត្រឡប់​មក​វិញ 3 ខែ​។ ខ្ញុំ​នឹង​ត្រូវ​ការ​ត្រឡប់​មក​វិញ​តែ 2 នាទី​ប៉ុណ្ណោះ។ ម៉ាស៊ីនឆុងកាហ្វេដ៏ល្អមួយនឹងមិនមានពេលសម្រាប់ឆុងកាហ្វេក្នុងរយៈពេល 2 នាទី ដូច្នេះវាត្រជាក់ណាស់។

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

តើយើងអាចវាស់ស្ទង់ភាពជោគជ័យ ឬបរាជ័យនៃការអនុវត្តនេះដោយរបៀបណា? ប្រសិនបើអ្នករាយការណ៍ទៅចៅហ្វាយធំនូវអ្វីដែលយើងអនុវត្តលើគម្រោង CI គាត់ឮ blah blah blah ។ យើង​បាន​អនុវត្ត​វា​ហើយ យល់ព្រម ប៉ុន្តែ​ហេតុអ្វី​បាន​ជា​វា​នាំ​មក​នូវ​អ្វី​មក​លើ​យើង តើ​យើង​វាស់វែង​វា​ដោយ​របៀប​ណា តើ​យើង​អនុវត្ត​វា​ត្រឹមត្រូវ ឬ​មិន​ត្រឹមត្រូវ?

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

ការអនុវត្តមួយទៀតដែលយើងមានគឺការអនុវត្តតេស្តស្វ័យប្រវត្តិកម្ម ដែលភាគច្រើនមកជាមួយការអនុវត្ត CI ។ ពួកគេទៅចាប់ដៃគ្នា។

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

យើងក៏មានការធ្វើតេស្តសមាហរណកម្មដែលអនុញ្ញាតឱ្យយើងយល់ពីរបៀបដែលម៉ូឌុលផ្សេងគ្នារួមបញ្ចូលគ្នាទៅវិញទៅមក។ វាក៏ល្អផងដែរ។

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

ការធ្វើតេស្តជាក់លាក់ដែលអ្នកដំណើរការអាចប៉ះពាល់ដល់រយៈពេលដែលអ្នកដំណើរការពួកវា។ ការធ្វើតេស្តឯកតាជាធម្មតាត្រូវបានសរសេរខ្លី និងតូច។ ហើយពួកគេអាចត្រូវបានដាក់ឱ្យដំណើរការជាទៀងទាត់។

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

ខ្ញុំមានគម្រោងមួយទៀតដែលខ្ញុំបាននិងកំពុងធ្វើ។ យើង​មាន​ការ​រត់​ពីរ​សប្តាហ៍​លើ​គម្រោង​នេះ។ គម្រោងនេះមានទំហំធំ មានសារៈសំខាន់សម្រាប់វិស័យហិរញ្ញវត្ថុ ហើយកំហុសមិនអាចកើតឡើងបានទេ។ ហើយបន្ទាប់ពីការរត់រយៈពេលពីរសប្តាហ៍ វដ្តនៃការអភិវឌ្ឍន៍ត្រូវបានបន្តដោយដំណើរការសាកល្បង ដែលចំណាយពេល 4 សប្តាហ៍ទៀត។ ព្យាយាមស្រមៃមើលទំហំនៃសោកនាដកម្ម។ យើងសរសេរកូដរយៈពេលពីរសប្តាហ៍ បន្ទាប់មកយើងធ្វើវា ala CodeFreeze វេចខ្ចប់វាទៅក្នុងកំណែថ្មីនៃកម្មវិធី ហើយរមៀលវាចេញទៅកាន់អ្នកសាកល្បង។ អ្នកសាកល្បងសាកល្បងវាសម្រាប់រយៈពេល 4 សប្តាហ៍ទៀតពោលគឺឧ។ ខណៈពេលដែលពួកគេកំពុងសាកល្បង យើងមានពេលដើម្បីរៀបចំកំណែពីរបន្ថែមទៀតសម្រាប់ពួកគេ។ នេះ​ជា​ករណី​ដ៏​គួរ​ឲ្យ​សោកស្ដាយ។

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

អនុវត្តការដាក់ពង្រាយជាបន្តបន្ទាប់។ ល្អណាស់ អ្នកបានសាងសង់ហើយ។ នេះគឺល្អរួចទៅហើយ។ លេខកូដរបស់អ្នកត្រូវបានចងក្រង។ ឥឡូវនេះ វាជាការប្រសើរណាស់ក្នុងការដាក់ពង្រាយការសាងសង់នេះនៅលើបរិស្ថានមួយចំនួន។ ចូរនិយាយថានៅក្នុងបរិយាកាសសម្រាប់អ្នកអភិវឌ្ឍន៍។

ហេតុអ្វីបានជាវាសំខាន់? ជាដំបូង អ្នកអាចមើលថាតើអ្នកជោគជ័យប៉ុណ្ណាជាមួយនឹងដំណើរការដាក់ពង្រាយខ្លួនឯង។ ខ្ញុំបានជួបគម្រោងដូចនេះ នៅពេលដែលខ្ញុំសួរថា "តើអ្នកដាក់កម្មវិធីកំណែថ្មីដោយរបៀបណា?" បុរសៗប្រាប់ខ្ញុំថា "យើងប្រមូលផ្តុំវា ហើយខ្ចប់វាទៅក្នុងប័ណ្ណសារហ្ស៊ីប។ យើងផ្ញើវាទៅអ្នកគ្រប់គ្រងតាមសំបុត្រ។ អ្នកគ្រប់គ្រងទាញយក និងពង្រីកប័ណ្ណសារនេះ។ ហើយ​ការិយាល័យ​ទាំង​មូល​ចាប់​ផ្ដើម​អធិស្ឋាន​សុំ​ឲ្យ​ម៉ាស៊ីន​មេ​នឹង​យក​កំណែ​ថ្មី»។

ចូរចាប់ផ្តើមជាមួយអ្វីដែលសាមញ្ញ។ ឧទាហរណ៍ ពួកគេភ្លេចដាក់ CSS នៅក្នុងប័ណ្ណសារ ឬភ្លេចផ្លាស់ប្តូរ hashtag ក្នុងឈ្មោះឯកសារ JavaScript។ ហើយនៅពេលដែលយើងធ្វើការស្នើសុំទៅ ម៉ាស៊ីនបម្រើកម្មវិធីរុករកតាមអ៊ីនធឺណិតគិតថាវាមានឯកសារ JavaScript រួចហើយ ហើយសម្រេចចិត្តមិនទាញយកវាទេ។ ប៉ុន្តែកំណែចាស់បានបាត់អ្វីមួយ។ សរុបមក វាអាចមានបញ្ហាជាច្រើន។ ដូច្នេះ ការអនុវត្តការដាក់ពង្រាយជាបន្តបន្ទាប់អនុញ្ញាតឱ្យអ្នកសាកល្បងយ៉ាងហោចណាស់នូវអ្វីដែលកើតឡើងប្រសិនបើអ្នកយករូបភាពយោងស្អាត ហើយរុញវាទៅកាន់បរិស្ថានថ្មីស្អាតទាំងស្រុង។ អ្នកអាចមើលឃើញអ្វីដែលកើតឡើង។

ដូចគ្នានេះផងដែរនៅពេលដែលអ្នកបញ្ចូលកូដរវាងគ្នាទៅវិញទៅមក i.e. រវាងពាក្យបញ្ជា វាអនុញ្ញាតឱ្យអ្នកមើលពីរបៀបដែលវាមើលទៅលើ UI ផងដែរ។

បញ្ហាមួយក្នុងចំណោមបញ្ហាដែលកើតឡើងនៅកន្លែងជាច្រើននៃ vanilla java-script ត្រូវបានគេប្រើប្រាស់គឺថាអ្នកអភិវឌ្ឍន៍ពីរនាក់បានប្រកាសយ៉ាងប្រញាប់ប្រញាល់នូវអថេរដែលមានឈ្មោះដូចគ្នានៅក្នុងវត្ថុបង្អួច។ ហើយបន្ទាប់មកអាស្រ័យលើសំណាងរបស់អ្នក។ ឯកសារ java-script ដែល​ត្រូវ​បាន​ទាញ​ចេញ​ទីពីរ នឹង​សរសេរ​ជាន់​លើ​ការ​ផ្លាស់​ប្តូរ​ផ្សេង​ទៀត។ វាក៏គួរឱ្យរំភើបផងដែរ។ អ្នកចូលមក៖ របស់មួយដំណើរការសម្រាប់មនុស្សម្នាក់ មួយទៀតមិនដំណើរការសម្រាប់មនុស្សម្នាក់ទៀត។ ហើយវា "អស្ចារ្យ" នៅពេលដែលវាចេញនៅក្នុងផលិតកម្ម។

ការអនុវត្តបន្ទាប់ដែលយើងមានគឺការអនុវត្ត Automatic Restore ពោលគឺវិលត្រលប់ទៅកំណែមុននៃកម្មវិធី។

ហេតុអ្វីបានជាវាសំខាន់សម្រាប់អ្នកអភិវឌ្ឍន៍? នៅតែមានអ្នកដែលចងចាំឆ្ងាយ 90s ឆ្ងាយនៅពេលដែលកុំព្យូទ័រមានទំហំធំហើយកម្មវិធីតូច។ ហើយមធ្យោបាយតែមួយគត់ក្នុងការអភិវឌ្ឍន៍គេហទំព័រគឺតាមរយៈ PHP ។ វាមិនមែនថា PHP គឺជាភាសាអាក្រក់ទេ ទោះបីវាជាភាសាក៏ដោយ។

ប៉ុន្តែបញ្ហាគឺខុសគ្នា។ នៅពេលដែលយើងដាក់ពង្រាយកំណែថ្មីនៃគេហទំព័រ php របស់យើង តើយើងដាក់ពង្រាយវាដោយរបៀបណា? ភាគច្រើនជាញឹកញាប់យើងបានបើក Far Manager ឬអ្វីផ្សេងទៀត។ ហើយបានបង្ហោះឯកសារទាំងនេះទៅ FTP ។ ហើយភ្លាមៗនោះយើងដឹងថាយើងមានកំហុសតូចតាចមួយចំនួន ឧទាហរណ៍ យើងភ្លេចដាក់សញ្ញាក្បៀស ឬភ្លេចប្តូរលេខសម្ងាត់សម្រាប់មូលដ្ឋានទិន្នន័យ ហើយមានលេខសម្ងាត់សម្រាប់មូលដ្ឋានទិន្នន័យ ដែលស្ថិតនៅលើម៉ាស៊ីនមូលដ្ឋាន។ ហើយ​យើង​សម្រេច​ចិត្ត​ភ្ជាប់​ទៅ FTP យ៉ាង​រហ័ស និង​កែសម្រួល​ឯកសារ​នៅ​ទីនោះ។ នេះគ្រាន់តែជាភ្លើង! នេះគឺជាអ្វីដែលពេញនិយមនៅក្នុងទសវត្សរ៍ទី 90 ។

ប៉ុន្តែប្រសិនបើអ្នកមិនបានមើលប្រតិទិនទេ ទសវត្សរ៍ទី 90 គឺជិត 30 ឆ្នាំមុន។ ឥឡូវនេះអ្វីគ្រប់យ៉ាងកំពុងកើតឡើងខុសគ្នាបន្តិចបន្តួច។ ហើយព្យាយាមស្រមៃមើលទំហំនៃសោកនាដកម្មនេះ នៅពេលពួកគេប្រាប់អ្នកថា “យើងបានដាក់ពង្រាយទៅផលិតកម្ម ប៉ុន្តែមានអ្វីមួយខុសនៅទីនោះ។ នេះជាការចូល និងពាក្យសម្ងាត់ FTP របស់អ្នក ភ្ជាប់ទៅផលិតកម្ម ហើយជួសជុលវានៅទីនោះយ៉ាងលឿន។ ប្រសិនបើអ្នកជា Chuck Norris វានឹងដំណើរការ។ បើមិនដូច្នោះទេ អ្នកប្រថុយថាប្រសិនបើអ្នកជួសជុលកំហុសមួយ អ្នកនឹងបង្កើត 10 បន្ថែមទៀត នេះជាហេតុផលដែលការអនុវត្តនៃការវិលត្រលប់ទៅកំណែមុននេះអនុញ្ញាតឱ្យអ្នកសម្រេចបានច្រើន។

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

ឥឡូវ​នេះ​យើង​ព្យាយាម​ផ្សំ​វិធី​ទាំង​ពីរ​ពី​មុន​មក​រួម​គ្នា​។ យើងនឹងទទួលបានផ្នែកទីបីហៅថា ការគ្រប់គ្រងការចេញផ្សាយ។

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

ក្រៅ​ពី​នេះ​នៅ​មាន​ទុក្ខ​មួយ​ទៀត។ នៅពេលអ្នកសាងសង់ សូម្បីតែនៅលើម៉ាស៊ីនដូចគ្នា អ្នកនឹងសាងសង់ប្រភពដូចគ្នា អ្នកនៅតែមិនមានការធានាថាម៉ាស៊ីននេះស្ថិតក្នុងស្ថានភាពដូចកាលពីពេលបង្កើតចុងក្រោយនោះទេ។

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

ដូច្នេះ ការអនុវត្តការគ្រប់គ្រងការចេញផ្សាយស្នើឱ្យណែនាំអរូបីបន្ថែមដែលហៅថា ឃ្លាំងវត្ថុបុរាណ ឬវិចិត្រសាល ឬបណ្ណាល័យ។ អ្នកអាចហៅវាតាមអ្វីដែលអ្នកចង់បាន។

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

បន្ទាប់មកយើងយកវា ហើយដាក់ពង្រាយវាដោយស្វ័យប្រវត្តិទៅកាន់បរិស្ថានអ្នកអភិវឌ្ឍន៍។ យើង​ប្រណាំង​នៅ​ទី​នោះ ហើយ​ប្រសិន​បើ​គ្រប់​យ៉ាង​ល្អ យើង​ដាក់​ទៅ​លើ​ឆាក។ ប្រសិនបើអ្វីៗទាំងអស់ល្អ នោះយើងដាក់ពង្រាយបណ្ណសារដូចគ្នាទៅផលិតកម្ម ដែលជាប្រព័ន្ធគោលពីរដូចគ្នា ចងក្រងតែម្តង។

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

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

នៅពេលដែលយើងនិយាយអំពីហេដ្ឋារចនាសម្ព័ន្ធនិម្មិត មនុស្សជាច្រើនគិតថាវាជាអ្វីមួយដែលអ្នកគ្រប់គ្រងបានដំឡើង។ ដូច្នេះ ប្រសិនបើអ្នកត្រូវការ ឧទាហរណ៍ ម៉ាស៊ីនមេថ្មីដើម្បីសាកល្បងកំណែថ្មីនៃកម្មវិធីរបស់អ្នក អ្នកត្រូវដាក់សំបុត្រជាមួយអ្នកគ្រប់គ្រង ឬ DevOps។ DevOps នឹងចំណាយពេលបីសប្តាហ៍ដើម្បីធ្វើដូចនេះ។ ហើយបន្ទាប់ពីបីសប្តាហ៍ ពួកគេនឹងប្រាប់អ្នកថា យើងបានដំឡើងម៉ាស៊ីននិម្មិតសម្រាប់អ្នកជាមួយនឹងស្នូលមួយ RAM ពីរជីហ្គាបៃ និង... Windows- ម៉ាស៊ីនមេដែលគ្មាន DotNet។ អ្នកនិយាយថា "ប៉ុន្តែខ្ញុំចង់បាន DotNet"។ ពួកគេនិយាយថា "យល់ព្រម ត្រលប់មកវិញក្នុងរយៈពេលបីសប្តាហ៍"។

គំនិតនេះគឺថាដោយប្រើហេដ្ឋារចនាសម្ព័ន្ធជាការអនុវត្តកូដ អ្នកអាចចាត់ទុកហេដ្ឋារចនាសម្ព័ន្ធនិម្មិតរបស់អ្នកគ្រាន់តែជាធនធានមួយផ្សេងទៀត។

ប្រហែលជាប្រសិនបើអ្នកណាមួយកំពុងបង្កើតកម្មវិធីនៅលើ DotNet អ្នកប្រហែលជាធ្លាប់បានឮអំពីបណ្ណាល័យមួយដែលមានឈ្មោះថា Entity Framework។ ហើយអ្នកប្រហែលជាធ្លាប់លឺថា Entity Framework គឺជាវិធីសាស្រ្តមួយដែលក្រុមហ៊ុន Microsoft កំពុងជំរុញយ៉ាងសកម្ម។ សម្រាប់ធ្វើការជាមួយមូលដ្ឋានទិន្នន័យ នេះគឺជាវិធីសាស្រ្តដែលហៅថា Code First ។ នេះគឺជាពេលដែលអ្នកពណ៌នានៅក្នុងកូដអំពីរបៀបដែលអ្នកចង់ឱ្យមូលដ្ឋានទិន្នន័យរបស់អ្នកមើលទៅ។ ហើយបន្ទាប់មកអ្នកដាក់ពង្រាយកម្មវិធី។ វាភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ វាកំណត់ដោយខ្លួនឯងថាតើតារាងណានៅទីនោះ ហើយតារាងណាដែលមិនមាន ហើយបង្កើតអ្វីគ្រប់យ៉ាងដែលអ្នកត្រូវការ។

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

ការអនុវត្តបន្ទាប់ដែលមាន និងមានសារៈសំខាន់ផងដែរ ប៉ុន្តែមានមនុស្សតិចណាស់ដែលប្រើនោះគឺ ការត្រួតពិនិត្យការអនុវត្តកម្មវិធី។

ខ្ញុំចង់និយាយតែរឿងមួយអំពីការត្រួតពិនិត្យការអនុវត្តកម្មវិធី។ តើអ្វីសំខាន់បំផុតអំពីការអនុវត្តនេះ? នេះគឺជាអ្វីដែលកម្មវិធីត្រួតពិនិត្យការអនុវត្តគឺដូចគ្នានឹងការជួសជុលអាផាតមិនដែរ។ នេះមិនមែនជារដ្ឋចុងក្រោយទេ វាជាដំណើរការ។ អ្នកត្រូវធ្វើវាឱ្យបានទៀងទាត់។

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

ហេតុអ្វីបានជាវាសំខាន់? ដោយសារតែប្រសិនបើអ្នកស្រាប់តែជួបប្រទះនឹងការធ្លាក់ចុះនៃការសម្តែង នោះអ្នកត្រូវយល់ច្បាស់ពីមូលហេតុ។ ប្រសិនបើក្រុមរបស់អ្នកមានការរត់រយៈពេលពីរសប្តាហ៍ បន្ទាប់មកយ៉ាងហោចណាស់ម្តងរៀងរាល់ពីរសប្តាហ៍ អ្នកគួរតែដាក់ពង្រាយកម្មវិធីរបស់អ្នកទៅកាន់ម៉ាស៊ីនមេដាច់ដោយឡែកមួយចំនួន ដែលអ្នកមាន processor, RAM, disks ជាដើម។ ហើយដំណើរការការធ្វើតេស្តដំណើរការដូចគ្នា . អ្នកទទួលបានលទ្ធផល។ សូមមើលពីរបៀបដែលវាបានផ្លាស់ប្តូរពីការរត់មុន។

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

ការអនុវត្តបន្ទាប់ដែលយើងមានគឺការអនុវត្តការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ។ មាន​មនុស្ស​តិច​ណាស់​ដែល​យក​ចិត្ត​ទុក​ដាក់​ចំពោះ​រឿង​នេះ។ ប៉ុន្តែជឿខ្ញុំ នេះពិតជារឿងធ្ងន់ធ្ងរណាស់។

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

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

ការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ។ យើងប្រហែលជាមានការកំណត់រចនាសម្ព័ន្ធផ្សេងៗគ្នានៅក្នុងបរិយាកាសផ្សេងៗគ្នា។ ឧទាហរណ៍ យើងអាចមានការចូល និងពាក្យសម្ងាត់ផ្សេងគ្នាសម្រាប់មូលដ្ឋានទិន្នន័យសម្រាប់ QA ការបង្ហាញ បរិយាកាសផលិតកម្ម។ល។

ការកំណត់រចនាសម្ព័ន្ធនេះក៏អាចដោយស្វ័យប្រវត្តិផងដែរ។ វាគួរតែដាច់ដោយឡែកពីកម្មវិធីខ្លួនវាជានិច្ច។ ហេតុអ្វី? ដោយសារតែអ្នកបានបង្កើតកម្មវិធីម្តង ហើយបន្ទាប់មកកម្មវិធីមិនខ្វល់ថាតើអ្នកភ្ជាប់ទៅម៉ាស៊ីនមេ SQL តាមរយៈ IP បែបនេះ ឬបែបនេះ និង IP បែបនេះទេ វាគួរតែដំណើរការដូចគ្នា។ ហេតុដូច្នេះហើយ ប្រសិនបើភ្លាមៗនោះ មានអ្នកណាមួយនៅតែ hardcoding ការតភ្ជាប់ខ្សែអក្សរនៅក្នុងកូដនោះ ចូរចងចាំថា ខ្ញុំនឹងស្វែងរកអ្នក ហើយដាក់ទោសអ្នក ប្រសិនបើអ្នកឃើញខ្លួនអ្នកនៅលើគម្រោងដូចគ្នាជាមួយខ្ញុំ។ វាតែងតែត្រូវបានដាក់ក្នុងការកំណត់រចនាសម្ព័ន្ធដាច់ដោយឡែក ឧទាហរណ៍នៅក្នុង web.config ។

ហើយ​ការកំណត់​រចនាសម្ព័ន្ធ​នេះ​ត្រូវបាន​គ្រប់គ្រង​ដោយ​ឡែក​ពី​គ្នា​រួច​ទៅ​ហើយ ពោល​គឺ​ពិតជា​ពេល​ដែល​អ្នក​អភិវឌ្ឍន៍​និង​អ្នកគ្រប់គ្រង​អាច​មក​អង្គុយ​ក្នុង​បន្ទប់​តែមួយ។ ហើយ​អ្នក​អភិវឌ្ឍន៍​អាច​និយាយ​ថា​៖ «​មើល នេះ​ជា​ប្រព័ន្ធគោលពីរ​នៃ​កម្មវិធី​របស់ខ្ញុំ។ ពួកគេធ្វើការ។ កម្មវិធីត្រូវការមូលដ្ឋានទិន្នន័យដើម្បីដំណើរការ។ នៅទីនេះនៅជាប់នឹងប្រព័ន្ធគោលពីរ មានឯកសារមួយ។ នៅក្នុងឯកសារនេះ វាលនេះទទួលខុសត្រូវចំពោះការចូល នេះគឺសម្រាប់ពាក្យសម្ងាត់ នេះគឺសម្រាប់ IP ។ ដាក់​ពង្រាយ​វា​នៅ​កន្លែង​ណា​ក៏​បាន»។ ហើយ​វា​សាមញ្ញ​និង​ច្បាស់​សម្រាប់​អ្នក​គ្រប់គ្រង។ គាត់​អាច​ប្រើ​វា​បាន​គ្រប់​ទីកន្លែង​ដោយ​ការ​គ្រប់គ្រង​ការ​កំណត់​រចនាសម្ព័ន្ធ​នេះ។

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

ខ្ញុំដឹងថាមានមនុស្សមួយចំនួននៅក្នុងសន្និសីទនេះពីក្រុមដែលខ្ញុំធ្វើការជាមួយ។ ហើយជាមួយនឹងក្រុមទាំងអស់ដែលខ្ញុំធ្វើការជាមួយ យើងប្រើការអនុវត្តនេះ។

ហេតុអ្វី? ជាការពិតណាស់ វាពិតជាល្អណាស់ប្រសិនបើអ្នកអភិវឌ្ឍន៍នីមួយៗមានម៉ាស៊ីននិម្មិតដែលនឹងធ្វើការ 24/7 ។ ប៉ុន្តែប្រហែលជានេះជាដំណឹងសម្រាប់អ្នក ប្រហែលជាអ្នកមិនបានយកចិត្តទុកដាក់ទេ ប៉ុន្តែអ្នកអភិវឌ្ឍន៍ខ្លួនឯងមិនដំណើរការ 24/7 ទេ។ អ្នកអភិវឌ្ឍន៍ជាធម្មតាធ្វើការ 8 ម៉ោងក្នុងមួយថ្ងៃ។ ទោះបីជាគាត់មកធ្វើការលឿនក៏ដោយ គាត់មានអាហារថ្ងៃត្រង់ធំមួយក្នុងអំឡុងពេលដែលគាត់ទៅកន្លែងហាត់ប្រាណ។ សូមឱ្យវាមានរយៈពេល 12 ម៉ោងក្នុងមួយថ្ងៃនៅពេលដែលអ្នកអភិវឌ្ឍន៍ពិតជាប្រើប្រាស់ធនធានទាំងនេះ។ យោងតាមច្បាប់របស់យើង យើងមាន 5 ក្នុងចំណោម 7 ថ្ងៃក្នុងមួយសប្តាហ៍ដែលត្រូវបានចាត់ទុកថាជាថ្ងៃធ្វើការ។

ដូច្នោះហើយ នៅថ្ងៃធ្វើការម៉ាស៊ីននេះមិនគួរដំណើរការ 24 ម៉ោងទេ ប៉ុន្តែមានតែ 12 ប៉ុណ្ណោះ ហើយនៅចុងសប្តាហ៍ម៉ាស៊ីននេះមិនគួរដំណើរការទាល់តែសោះ។ វាហាក់ដូចជាថាអ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់ ប៉ុន្តែអ្វីដែលសំខាន់ក្នុងការនិយាយនៅទីនេះ? តាមរយៈការអនុវត្តការអនុវត្តដ៏សាមញ្ញនេះនៅលើកាលវិភាគជាមូលដ្ឋាននេះ វាអនុញ្ញាតឱ្យអ្នកកាត់បន្ថយការចំណាយលើការថែរក្សាបរិស្ថានទាំងនេះបាន 70% ពោលគឺអ្នកបានយកតម្លៃនៃ dev, QA, demo, បរិស្ថានរបស់អ្នក ហើយបែងចែកវាដោយ 3 ។

សំណួរសួរថា តើត្រូវធ្វើអ្វីជាមួយលុយដែលនៅសល់? ឧទាហរណ៍ អ្នកអភិវឌ្ឍន៍គួរតែទិញ ReSharper ប្រសិនបើពួកគេមិនទាន់មាន។ ឬមានពិធីជប់លៀងស្រាក្រឡុក។ ប្រសិនបើអ្នកពីមុនមានបរិយាកាសមួយដែលទាំង dev និង QA ស៊ីស្មៅ ហើយនោះហើយជាវា ឥឡូវនេះអ្នកអាចបង្កើត 3 ផ្សេងគ្នាដែលនឹងនៅដាច់ដោយឡែក ហើយមនុស្សនឹងមិនជ្រៀតជ្រែកគ្នាទៅវិញទៅមកទេ។

ទាក់ទងនឹងស្លាយជាមួយនឹងការវាស់វែងការអនុវត្តបន្ត តើយើងអាចប្រៀបធៀបការអនុវត្តបានដោយរបៀបណា ប្រសិនបើយើងមានកំណត់ត្រា 1 នៅក្នុងមូលដ្ឋានទិន្នន័យនៅក្នុងគម្រោង ពីរខែក្រោយមកមានមួយលាន? តើធ្វើដូចម្តេចដើម្បីយល់ពីមូលហេតុ និងអ្វីដែលជាចំណុចនៃការវាស់វែងការអនុវត្ត?

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

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

តើយើងកំពុងនិយាយអំពីការវាស់វែងការអនុវត្តនៅក្នុងបរិយាកាសសាកល្បងពិសេសឬ? នោះ​គឺ​ថា​នេះ​មិន​មែន​ជា​ការ​ផលិត​?

បាទ នេះមិនមែនជាការផលិតទេ នេះជាបរិយាកាសសាកល្បង ដែលតែងតែដូចគ្នា ដូច្នេះអ្នកអាចប្រៀបធៀបវាបានជាមួយនឹងការវាស់វែងពីមុន។

យល់ហើយ អរគុណ!

ប្រសិនបើគ្មានសំណួរទេ ខ្ញុំគិតថាយើងអាចបញ្ចប់បាន។ សូមអរគុណ!

ប្រភព: www.habr.com