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

នៅពេលអ្នកសរសេរកូដរបស់អ្នកហើយ អ្នកត្រូវតែប្រាកដថាវា៖

1. ធ្វើការ។
2. វាមិនខូចអ្វីទាំងអស់ រួមទាំងលេខកូដដែលមិត្តរួមការងាររបស់អ្នកបានសរសេរផងដែរ។

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

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

• មនុស្សជាទីគោរព. មួយម៉ោងនៃការងាររបស់អ្នកសរសេរកម្មវិធីណាមួយមានតម្លៃថ្លៃជាងមួយម៉ោងនៃការងាររបស់ម៉ាស៊ីនមេណាមួយ។
• មនុស្សធ្វើខុស. ដូច្នេះ ស្ថានភាពអាចកើតឡើងនៅពេលដែលការធ្វើតេស្តត្រូវបានដំណើរការលើសាខាខុស ឬកំហុសត្រូវបានចងក្រងសម្រាប់អ្នកសាកល្បង។
• មនុស្សខ្ជិល។. យូរៗម្ដង ពេលខ្ញុំបញ្ចប់កិច្ចការមួយ គំនិតកើតឡើងថា “តើមានអ្វីដែលត្រូវពិនិត្យ? ខ្ញុំសរសេរពីរជួរ - អ្វីៗដំណើរការ! ខ្ញុំគិតថា អ្នកខ្លះក៏មានគំនិតបែបនេះដែរ។ ប៉ុន្តែអ្នកគួរពិនិត្យមើលជានិច្ច។

របៀបដែលសមាហរណកម្មបន្តត្រូវបានអនុវត្ត និងបង្កើតនៅក្នុងក្រុមអភិវឌ្ឍន៍ឧបករណ៍ចល័ត Avito របៀបដែលពួកគេបានទៅពី 0 ទៅ 450 សាងសង់ក្នុងមួយថ្ងៃ ហើយម៉ាស៊ីនដែលបង្កើតបានប្រមូលផ្តុំ 200 ម៉ោងក្នុងមួយថ្ងៃ បាននិយាយថា Nikolai Nesterov (ណេស្តេរ៉ូវ) គឺជាអ្នកចូលរួមក្នុងការផ្លាស់ប្តូរវិវត្តន៍ទាំងអស់នៃកម្មវិធី CI/CD Android ។

រឿងនេះគឺផ្អែកលើឧទាហរណ៍នៃពាក្យបញ្ជា Android ប៉ុន្តែវិធីសាស្រ្តភាគច្រើនអាចអនុវត្តបាននៅលើ iOS ផងដែរ។

មានពេលមួយ មនុស្សម្នាក់បានធ្វើការនៅក្នុងក្រុម Avito Android ។ តាមនិយមន័យ គាត់មិនត្រូវការអ្វីពីសមាហរណកម្មបន្តទេ៖ គ្មាននរណាម្នាក់អាចរួមបញ្ចូលជាមួយបានទេ។

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

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

ពិនិត្យ

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

• ដំបូងយើងពិនិត្យ ការជួបប្រជុំគ្នា ARK.
• ច្រើន ការធ្វើតេស្ត Junit.
• យើងពិចារណាលើការគ្របដណ្តប់កូដចាប់តាំងពីយើងកំពុងដំណើរការការធ្វើតេស្ត។

ដើម្បីយល់ពីរបៀបដែលការត្រួតពិនិត្យទាំងនេះគួរតែដំណើរការ សូមមើលដំណើរការអភិវឌ្ឍន៍នៅក្នុង Avito ។

វាអាចត្រូវបានតំណាងដោយគ្រោងការណ៍ដូចនេះ:

• អ្នកអភិវឌ្ឍន៍សរសេរកូដនៅលើកុំព្យូទ័រយួរដៃរបស់គាត់។ អ្នកអាចដំណើរការការត្រួតពិនិត្យការរួមបញ្ចូលនៅទីនេះ - ទាំងជាមួយ commit hook ឬគ្រាន់តែដំណើរការការត្រួតពិនិត្យនៅក្នុងផ្ទៃខាងក្រោយ។
• បន្ទាប់​ពី​អ្នក​អភិវឌ្ឍន៍​បាន​រុញ​កូដ​រួច គាត់​បើក​សំណើ​ទាញ។ ដើម្បីឱ្យលេខកូដរបស់វាត្រូវបានរួមបញ្ចូលនៅក្នុងសាខាអភិវឌ្ឍន៍ វាចាំបាច់ត្រូវឆ្លងកាត់ការពិនិត្យកូដ និងប្រមូលចំនួនការបញ្ជាក់ដែលត្រូវការ។ អ្នកអាចបើកការត្រួតពិនិត្យ និងបង្កើតនៅទីនេះ៖ រហូតដល់ការស្ថាបនាទាំងអស់ទទួលបានជោគជ័យ សំណើទាញមិនអាចបញ្ចូលចូលគ្នាបានទេ។
• បន្ទាប់​ពី​សំណើ​ទាញ​ត្រូវ​បាន​បញ្ចូល​គ្នា ហើយ​កូដ​ត្រូវ​បាន​រួម​បញ្ចូល​ក្នុង​ការ​អភិវឌ្ឍ អ្នក​អាច​ជ្រើសរើស​ពេល​វេលា​ដ៏​ងាយស្រួល​មួយ៖ ឧទាហរណ៍ នៅ​ពេល​យប់ ពេល​ម៉ាស៊ីន​មេ​ទាំងអស់​ទំនេរ ហើយ​ដំណើរការ​ពិនិត្យ​ច្រើន​តាម​ដែល​អ្នក​ចូលចិត្ត។

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

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

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

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

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

វាត្រូវចំណាយពេលពីរថ្ងៃដើម្បីរៀបចំ CI មូលដ្ឋានទាំងស្រុង (បន្ទាប់ការប៉ាន់ស្មានពេលវេលាគឺប្រហាក់ប្រហែល ត្រូវការសម្រាប់ខ្នាត)។

បន្ទាប់ពីនោះយើងចាប់ផ្តើមគិតបន្ថែមទៀត - តើយើងពិនិត្យមើលត្រឹមត្រូវទេ? តើ​យើង​កំពុង​ដំណើរការ​បង្កើត​តាម​សំណើ​ទាញ​ត្រឹមត្រូវ​ឬ​ទេ?

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

ដើម្បីធ្វើដូចនេះយើងសរសេរស្គ្រីប bash សាមញ្ញ premerge.sh៖

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

វាចំណាយពេលបីថ្ងៃដើម្បីធ្វើមូលដ្ឋានីយកម្មបញ្ហា ស្វែងរកដំណោះស្រាយ និងសរសេរស្គ្រីបនេះ។

កម្មវិធីដែលបានអភិវឌ្ឍ ការងារកាន់តែច្រើនឡើងៗបានបង្ហាញខ្លួន ក្រុមការងារបានរីកចម្រើន ហើយពេលខ្លះ premerge.sh បានចាប់ផ្តើមធ្វើឱ្យយើងខកចិត្ត។ Develop មានការផ្លាស់ប្តូរដែលផ្ទុយគ្នាដែលបំបែកការស្ថាបនា។

ឧទាហរណ៍នៃរបៀបដែលវាកើតឡើង៖

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

អ្នកអភិវឌ្ឍន៍បញ្ចប់ការងាររបស់ពួកគេ ហើយបើកសំណើទាញក្នុងពេលតែមួយ។ ការស្ថាបនាត្រូវបានបើកដំណើរការ premerge.sh ពិនិត្យសំណើទាញទាំងពីរទាក់ទងនឹងស្ថានភាពអភិវឌ្ឍន៍ចុងក្រោយបង្អស់ - ការត្រួតពិនិត្យទាំងអស់មានពណ៌បៃតង។ បន្ទាប់ពីនោះ សំណើទាញនៃមុខងារ A ត្រូវបានបញ្ចូលចូលគ្នា សំណើទាញនៃមុខងារ B ត្រូវបានបញ្ចូល... ប៊ូម! អភិវឌ្ឍការបំបែកដោយសារតែកូដអភិវឌ្ឍន៍មានការហៅទៅកាន់មុខងារដែលមិនមាន។

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

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

ដោយសារវាមិនសមនឹងយើង យើងចាប់ផ្តើមស្វែងរកជម្រើសអំពីរបៀបការពារបញ្ហានេះ។

ធ្វើ​ម៉េច​កុំ​ឲ្យ​ខូច​អភិវឌ្ឍន៍

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

ដើម្បីយល់ពីរយៈពេលដែលវានឹងចំណាយពេលយូរ សូមពិចារណាឧទាហរណ៍ជាមួយ PRs ពីរ។ យើងបើក PRs ពីរ: ការបង្កើតពីរ, ការត្រួតពិនិត្យពីរ។ បន្ទាប់ពី PR ទីមួយត្រូវបានបញ្ចូលទៅក្នុងការអភិវឌ្ឍន៍ កន្លែងទីពីរត្រូវសាងសង់ឡើងវិញ។ សរុបមក PRs ពីរតម្រូវឱ្យមានការត្រួតពិនិត្យចំនួនបី: 2 + 1 = 3 ។

ជាគោលការណ៍វាមិនអីទេ។ ប៉ុន្តែយើងបានមើលស្ថិតិហើយស្ថានភាពធម្មតានៅក្នុងក្រុមរបស់យើងគឺ 10 PRs បើកចំហហើយបន្ទាប់មកចំនួននៃការត្រួតពិនិត្យគឺជាផលបូកនៃវឌ្ឍនភាព: 10 + 9 + ... + 1 = 55 ។ នោះគឺដើម្បីទទួលយក 10 ។ PRs អ្នកត្រូវសាងសង់ឡើងវិញ 55 ដង។ ហើយនេះគឺស្ថិតក្នុងស្ថានភាពដ៏ល្អមួយ នៅពេលដែលការត្រួតពិនិត្យទាំងអស់ឆ្លងកាត់ជាលើកដំបូង នៅពេលដែលគ្មាននរណាម្នាក់បើកសំណើរទាញបន្ថែម ខណៈពេលដែលរាប់សិបទាំងនេះកំពុងដំណើរការ។

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

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

ជាលទ្ធផលមានតែជម្រើសទីបីប៉ុណ្ណោះដែលនៅសល់ - កង់. កូដរបស់យើងទាំងអស់ ប្រភពរបស់យើងទាំងអស់ត្រូវបានរក្សាទុកនៅក្នុងឃ្លាំងមួយនៅលើម៉ាស៊ីនមេ Bitbucket ។ ដូច្នោះហើយ យើងត្រូវតែបង្កើតកម្មវិធីជំនួយសម្រាប់ Bitbucket ។

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

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

មុនពេលអនុវត្តកម្មវិធីជំនួយនេះ យើងបានវាយតម្លៃជាមធ្យម 2,7 ដំណើរការក្នុងមួយសំណើទាញ។ ជាមួយនឹងកម្មវិធីជំនួយមានការបើកដំណើរការ 3,6 ។ នេះសមនឹងយើង។

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

យើងចំណាយពេលពីរសប្តាហ៍ដើម្បីសរសេរកំណែដំបូងនៃកម្មវិធីជំនួយ Bitbucket ។

ការត្រួតពិនិត្យថ្មី។

ទន្ទឹមនឹងនេះ ក្រុមរបស់យើងបានបន្តរីកចម្រើន។ ការត្រួតពិនិត្យថ្មីត្រូវបានបន្ថែម។

យើង​គិត​ថា​៖ ​ហេតុ​អ្វី​បាន​ជា​ធ្វើ​ខុស​ប្រសិន​បើ​ពួក​គេ​អាច​ត្រូវ​បាន​រារាំង? នោះហើយជាមូលហេតុដែលពួកគេអនុវត្ត ការវិភាគកូដឋិតិវន្ត. យើងបានចាប់ផ្តើមជាមួយ lint ដែលត្រូវបានរួមបញ្ចូលនៅក្នុង Android SDK ។ ប៉ុន្តែនៅពេលនោះគាត់មិនដឹងពីរបៀបធ្វើការជាមួយកូដ Kotlin ទាល់តែសោះ ហើយយើងមាន 75% នៃកម្មវិធីដែលបានសរសេរនៅក្នុង Kotlin រួចហើយ។ ដូច្នេះ វត្ថុដែលភ្ជាប់មកជាមួយត្រូវបានបញ្ចូលទៅក្នុងស្រទាប់ឈើ Android Studio ពិនិត្យ។

ដើម្បីធ្វើដូច្នេះ យើងត្រូវធ្វើការបំប្លែងជាច្រើន៖ យក Android Studio ដាក់កញ្ចប់វានៅក្នុង Docker ហើយដំណើរការវានៅលើ CI ជាមួយនឹងម៉ូនីទ័រនិម្មិត ដើម្បីឱ្យវាគិតថាវាដំណើរការលើកុំព្យូទ័រយួរដៃពិតប្រាកដ។ ប៉ុន្តែវាដំណើរការ។

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

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

មន្ទីរពិសោធន៍ Firebase

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

វាចំណាយពេលប្រហែលបីសប្តាហ៍ដើម្បីអនុវត្ត Firebase Test Lab ទៅក្នុង CI របស់យើង។

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

Docker + Python + bash

យើងបានយក Docker បញ្ចូលកម្មវិធីត្រាប់តាមទៅក្នុងវា សរសេរកម្មវិធីសាមញ្ញមួយនៅក្នុង Python ដែលនៅពេលត្រឹមត្រូវនាំមកនូវចំនួនកម្មវិធីត្រាប់តាមដែលទាមទារនៅក្នុងកំណែដែលត្រូវការ ហើយបញ្ឈប់វានៅពេលចាំបាច់។ ហើយជាការពិតណាស់ ស្គ្រីប bash ពីរបី - តើយើងនឹងនៅឯណាដោយគ្មានពួកវា?

វាចំណាយពេលប្រាំសប្តាហ៍ដើម្បីបង្កើតបរិយាកាសសាកល្បងផ្ទាល់ខ្លួនរបស់យើង។

ជាលទ្ធផល សម្រាប់រាល់ការស្នើសុំទាញ មានបញ្ជីត្រួតពិនិត្យរួមបញ្ចូលគ្នាយ៉ាងទូលំទូលាយ៖

• ការជួបប្រជុំគ្នា ARK;
• ការធ្វើតេស្ត Junit;
• លីង;
• ពិនិត្យ Android Studio;
• ការធ្វើតេស្តឧបករណ៍;
• ការធ្វើតេស្តរូបថតអេក្រង់។

នេះបានរារាំងការបែកបាក់ដែលអាចកើតមានជាច្រើន។ តាមបច្ចេកទេសគ្រប់យ៉ាងដំណើរការ ប៉ុន្តែអ្នកអភិវឌ្ឍន៍បានត្អូញត្អែរថាការរង់ចាំលទ្ធផលគឺយូរពេក។

តើ​យូរ​ប៉ុណ្ណា​ទៅ? យើងបានផ្ទុកទិន្នន័យពី Bitbucket និង TeamCity ទៅក្នុងប្រព័ន្ធវិភាគ ហើយបានដឹងថា ពេលវេលារង់ចាំជាមធ្យម 45 នាទី។. នោះគឺអ្នកអភិវឌ្ឍន៍ នៅពេលបើកសំណើទាញ រង់ចាំជាមធ្យម 45 នាទីសម្រាប់លទ្ធផលសាងសង់។ តាមគំនិតរបស់ខ្ញុំ នេះគឺច្រើនណាស់ ហើយអ្នកមិនអាចធ្វើការដូចនោះទេ។

ជា​ការ​ពិត​ណាស់ យើង​បាន​សម្រេច​ចិត្ត​ពន្លឿន​ការ​សាង​សង់​របស់​យើង​ទាំង​អស់។

តោះបង្កើនល្បឿន

ដោយឃើញសំណង់នោះច្រើនតែឈរជាជួរ រឿងដំបូងដែលយើងធ្វើគឺ បានទិញ Hardware បន្ថែមទៀត - ការអភិវឌ្ឍន៍ទូលំទូលាយគឺសាមញ្ញបំផុត។ Builds បានបញ្ឈប់ការតម្រង់ជួរ ប៉ុន្តែពេលវេលារង់ចាំបានថយចុះបន្តិចប៉ុណ្ណោះ ដោយសារតែការត្រួតពិនិត្យមួយចំនួនដោយខ្លួនឯងចំណាយពេលយូរណាស់។

ការដកមូលប្បទានប័ត្រដែលចំណាយពេលយូរពេក

ការរួមបញ្ចូលជាបន្តបន្ទាប់របស់យើងអាចចាប់យកប្រភេទនៃកំហុស និងបញ្ហាទាំងនេះ។

• មិនទៅ. CI អាចចាប់កំហុសក្នុងការចងក្រងនៅពេលដែលអ្វីមួយមិនបង្កើតដោយសារតែការផ្លាស់ប្តូរដែលផ្ទុយគ្នា។ ដូចដែលខ្ញុំបាននិយាយរួចមកហើយ គ្មាននរណាម្នាក់អាចប្រមូលផ្តុំអ្វីបានឡើយ ការអភិវឌ្ឍន៍ក៏ឈប់ ហើយគ្រប់គ្នាមានការភ័យខ្លាច។
• កំហុសក្នុងអាកប្បកិរិយា. ឧទាហរណ៍ នៅពេលដែលកម្មវិធីត្រូវបានបង្កើតឡើង ប៉ុន្តែគាំងនៅពេលអ្នកចុចប៊ូតុង ឬប៊ូតុងមិនត្រូវបានចុចទាល់តែសោះ។ នេះមិនល្អទេ ព្រោះកំហុសបែបនេះអាចទៅដល់អ្នកប្រើប្រាស់។
• កំហុសក្នុងប្លង់. ឧទាហរណ៍ ប៊ូតុងមួយត្រូវបានចុច ប៉ុន្តែបានផ្លាស់ទី 10 ភីកសែលទៅខាងឆ្វេង។
• ការកើនឡើងនៃបំណុលបច្ចេកទេស.

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

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

ជាលទ្ធផលយើងនៅសល់៖

• ការជួបប្រជុំគ្នា ARK;
• ការធ្វើតេស្ត Junit;
• ការធ្វើតេស្តឧបករណ៍។

Gradle ឃ្លាំងសម្ងាត់ពីចម្ងាយ

បើគ្មានការត្រួតពិនិត្យធ្ងន់ៗទេ អ្វីៗបានប្រសើរឡើង ប៉ុន្តែគ្មានដែនកំណត់ចំពោះភាពល្អឥតខ្ចោះទេ!

កម្មវិធីរបស់យើងត្រូវបានបំបែកទៅជាម៉ូឌុល gradle ប្រហែល 150 រួចហើយ។ ឃ្លាំងសម្ងាត់ពីចម្ងាយ Gradle ជាធម្មតាដំណើរការល្អក្នុងករណីនេះ ដូច្នេះយើងបានសម្រេចចិត្តសាកល្បងវា។

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

ការដំណើរការឃ្លាំងសម្ងាត់ពីចម្ងាយ Gradle គឺងាយស្រួលព្រោះ Gradle ផ្តល់នូវរូបភាព Docker ។ យើងអាចធ្វើវាបានក្នុងរយៈពេលបីម៉ោង។

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

ខាងក្រោម​នេះ​គឺ​ជា​ឃ្លាំង​សម្ងាត់​នឹក​ក្រាហ្វ។

នៅដើមដំបូង ភាគរយនៃការបាត់ឃ្លាំងសម្ងាត់គឺប្រហែល 65 ។ បន្ទាប់ពីបីសប្តាហ៍ យើងអាចបង្កើនតម្លៃនេះដល់ 20% ។ វាបានប្រែក្លាយថាភារកិច្ចដែលកម្មវិធី Android ប្រមូលបានមានភាពអាស្រ័យអន្តរកាលចម្លែកដោយសារតែការដែល Gradle ខកខានឃ្លាំងសម្ងាត់។

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

ការវិភាគផលប៉ះពាល់

តាមសំណើរទាញ យើងប្រមូល git diff ហើយស្វែងរកម៉ូឌុល Gradle ដែលបានកែប្រែ។

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

ការ​ធ្វើ​តេស្ត​ឧបករណ៍​មិន​សាមញ្ញ​ទេ ព្រោះ​វា​ត្រូវ​តែ​មាន​ទីតាំង​នៅ​ក្នុង​ម៉ូឌុល​កម្មវិធី​កម្រិត​កំពូល។ យើងបានប្រើ heuristics ជាមួយនឹងការវិភាគ bytecode ដើម្បីយល់ពីម៉ូឌុលនីមួយៗនៃការធ្វើតេស្តនីមួយៗ។

ការធ្វើឱ្យប្រសើរឡើងនូវប្រតិបត្តិការនៃការធ្វើតេស្តឧបករណ៍ដើម្បីឱ្យពួកគេសាកល្បងតែម៉ូឌុលដែលពាក់ព័ន្ធចំណាយពេលប្រហែលប្រាំបីសប្តាហ៍។

វិធានការ​ដើម្បី​ពន្លឿន​ការ​ត្រួតពិនិត្យ​បាន​ដំណើរការ​ដោយ​ជោគជ័យ។ ចាប់ពី 45 នាទី យើងឡើងដល់ប្រហែល 15។ វាជារឿងធម្មតាទៅហើយក្នុងការរង់ចាំមួយភាគបួននៃមួយម៉ោងសម្រាប់ការសាងសង់។

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

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

ប្រាំមួយសប្តាហ៍ត្រូវបានចំណាយលើមតិកែលម្អលម្អិត។

ផែនការ

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

លើសពីនេះទៀតមានផែនការផ្សេងទៀត។

• ត្រឡប់ Lint (និងការវិភាគឋិតិវន្តផ្សេងទៀត) ។ យើងកំពុងធ្វើការក្នុងទិសដៅនេះរួចហើយ។
• ដំណើរការអ្វីគ្រប់យ៉ាងនៅលើ PR blocker ការធ្វើតេស្តបញ្ចប់ នៅលើកំណែ SDK ទាំងអស់។

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

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

ប្រសិនបើ​ខ្ញុំ​អាច​ផ្តល់​ដំបូន្មាន​តែ​មួយ​ផ្នែក​នោះ វា​នឹង​មាន​ដូច​នេះ៖

សូមប្រយ័ត្នជាមួយស្គ្រីបសែល!

Bash គឺជាឧបករណ៍ដែលអាចបត់បែនបាន និងមានថាមពលខ្លាំង វាងាយស្រួល និងរហ័សក្នុងការសរសេរស្គ្រីប។ ប៉ុន្តែអ្នកអាចធ្លាក់ចូលទៅក្នុងអន្ទាក់ជាមួយវា ហើយជាអកុសលយើងបានធ្លាក់ចូលទៅក្នុងវា។

វាទាំងអស់បានចាប់ផ្តើមជាមួយនឹងស្គ្រីបសាមញ្ញដែលដំណើរការលើម៉ាស៊ីនបង្កើតរបស់យើង៖

#!/usr/bin/env bash
./gradlew assembleDebug

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

អ្នកអាចស្រមៃមើលតម្លៃពលកម្មសម្រាប់ការអភិវឌ្ឍន៍ស្គ្រីបបែបនេះ។ ខ្ញុំណែនាំអ្នកកុំឱ្យធ្លាក់ចូលក្នុងអន្ទាក់នេះ។

តើអ្វីអាចជំនួសបាន?

• ភាសាស្គ្រីបណាមួយ។ សរសេរ​ទៅកាន់ Python ឬ Kotlin Script កាន់តែងាយស្រួលព្រោះវាជាកម្មវិធីមិនមែនស្គ្រីបទេ។
• ឬពិពណ៌នាអំពីតក្កវិជ្ជាស្ថាបនាទាំងអស់ក្នុងទម្រង់ កិច្ចការ​កម្រិត​ផ្ទាល់​ខ្លួន សម្រាប់គម្រោងរបស់អ្នក។

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

គន្លឹះទី 2: រក្សាទុកហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងកូដ។

វាងាយស្រួលនៅពេលដែលការកំណត់ការរួមបញ្ចូលជាបន្តបន្ទាប់ត្រូវបានរក្សាទុកមិននៅក្នុងចំណុចប្រទាក់ UI របស់ Jenkins ឬ TeamCity ជាដើម។ ប៉ុន្តែជាទម្រង់ឯកសារអត្ថបទដោយផ្ទាល់នៅក្នុងឃ្លាំងគម្រោង។ នេះផ្តល់នូវលទ្ធភាពនៃកំណែ។ វានឹងមិនពិបាកក្នុងការវិលត្រលប់ ឬបង្កើតកូដនៅលើសាខាផ្សេងនោះទេ។

ស្គ្រីបអាចត្រូវបានរក្សាទុកក្នុងគម្រោង។ អ្វីដែលត្រូវធ្វើជាមួយបរិស្ថាន?

គន្លឹះទី 3៖ Docker អាចជួយដល់បរិស្ថាន។

វាពិតជានឹងជួយអ្នកអភិវឌ្ឍន៍ប្រព័ន្ធប្រតិបត្តិការ Android; iOS មិនទាន់មាននៅឡើយទេ។

នេះគឺជាឧទាហរណ៍នៃឯកសារ docker សាមញ្ញដែលមាន jdk និង android-sdk៖

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

ដោយបានសរសេរឯកសារ Docker នេះ (ខ្ញុំនឹងប្រាប់អ្នកពីអាថ៌កំបាំងមួយ អ្នកមិនចាំបាច់សរសេរវាទេ ប៉ុន្តែគ្រាន់តែទាញវារួចរាល់ដែលផលិតពី GitHub) ហើយផ្គុំរូបភាពនោះ អ្នកនឹងទទួលបានម៉ាស៊ីននិម្មិតដែលអ្នកអាចបង្កើតកម្មវិធីបាន។ និងដំណើរការការធ្វើតេស្ត Junit ។

មូលហេតុសំខាន់ពីរដែលធ្វើឲ្យយល់បានគឺ លទ្ធភាពធ្វើមាត្រដ្ឋាន និងលទ្ធភាពធ្វើម្តងទៀត។ ដោយប្រើ docker អ្នកអាចបង្កើនភ្នាក់ងារបង្កើតរាប់សិបយ៉ាងឆាប់រហ័សដែលនឹងមានបរិយាកាសដូចគ្នាទៅនឹងកម្មវិធីមុនដែរ។ នេះធ្វើឱ្យជីវិតរបស់វិស្វករ CI កាន់តែងាយស្រួល។ វាងាយស្រួលណាស់ក្នុងការរុញ android-sdk ចូលទៅក្នុង docker ប៉ុន្តែជាមួយនឹងកម្មវិធីត្រាប់តាមវាពិបាកជាងនេះបន្តិច៖ អ្នកនឹងត្រូវប្រឹងប្រែងបន្តិច (ឬទាញយកកម្មវិធីដែលបានបញ្ចប់ពី GitHub ម្តងទៀត)។

គន្លឹះទី៤៖ កុំភ្លេចថា អធិការកិច្ចមិនមែនធ្វើឡើងដើម្បីជាប្រយោជន៍ដល់អធិការកិច្ចទេ ប៉ុន្តែសម្រាប់មនុស្ស។

រហ័ស ហើយសំខាន់បំផុត មតិកែលម្អច្បាស់លាស់គឺមានសារៈសំខាន់ណាស់សម្រាប់អ្នកអភិវឌ្ឍន៍៖ អ្វី​ដែល​បាន​បែកធ្លាយ ការ​សាកល្បង​អ្វី​ដែល​បាន​បរាជ័យ តើខ្ញុំ​អាច​មើល​កំណត់ហេតុ​សាងសង់​នៅឯណា។

គន្លឹះទី 5: មានភាពប្រាកដនិយមនៅពេលបង្កើតការរួមបញ្ចូលជាបន្តបន្ទាប់។

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

គន្លឹះទី៦៖ ប្រើឧបករណ៍ដែលត្រៀមរួចជាស្រេច។

ឥឡូវនេះមានក្រុមហ៊ុនជាច្រើនដែលផ្តល់ Cloud CI ។

នេះគឺជាដំណោះស្រាយដ៏ល្អសម្រាប់ក្រុមតូចៗ។ អ្នកមិនចាំបាច់គាំទ្រអ្វីនោះទេ គ្រាន់តែចំណាយប្រាក់បន្តិចបន្តួច បង្កើតកម្មវិធីរបស់អ្នក និងសូម្បីតែដំណើរការការធ្វើតេស្តឧបករណ៍។

គន្លឹះទី 7: នៅក្នុងក្រុមធំ ដំណោះស្រាយក្នុងផ្ទះមានផលចំណេញច្រើនជាង។

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

សេដ្ឋកិច្ចពិពណ៌នាអំពីជីវិតទាំងមូលរបស់យើង រួមទាំងការរួមបញ្ចូលជាបន្តបន្ទាប់។ ខ្ញុំបានបង្កើតកាលវិភាគនៃថ្លៃពលកម្មសម្រាប់ដំណាក់កាលនីមួយៗនៃការអភិវឌ្ឍន៍នៃសមាហរណកម្មបន្តរបស់យើង។

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

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

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

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

អនុវត្តការរួមបញ្ចូលជាបន្តបន្ទាប់។ ប៉ុន្តែក្នុងកម្រិតមធ្យម។

ដោយវិធីនេះ Nikolai Nesterov មិនត្រឹមតែផ្តល់របាយការណ៍ដ៏អស្ចារ្យដោយខ្លួនឯងប៉ុណ្ណោះទេថែមទាំងជាសមាជិកនៃគណៈកម្មាធិការកម្មវិធីផងដែរ។ AppsConf និងជួយអ្នកដទៃរៀបចំសុន្ទរកថាដ៏មានអត្ថន័យសម្រាប់អ្នក។ ភាពពេញលេញ និងអត្ថប្រយោជន៍នៃកម្មវិធីសន្និសីទបន្ទាប់អាចត្រូវបានវាយតម្លៃដោយប្រធានបទនៅក្នុង កាលវិភាគ. ហើយសម្រាប់ព័ត៌មានលម្អិត សូមមកកាន់ Infospace នៅថ្ងៃទី 22-23 ខែមេសា។

ប្រភព: www.habr.com