យើងបានបង្កើត DevOps តាមដែលអាចធ្វើបាន។ មានពួកយើង 8 នាក់ ហើយ Vasya គឺត្រជាក់បំផុតនៅក្នុង Windows ។ ភ្លាមៗនោះ Vasya បានចាកចេញ ហើយខ្ញុំមានភារកិច្ចចាប់ផ្តើមគម្រោងថ្មីមួយដែលត្រូវបានផ្គត់ផ្គង់ដោយការអភិវឌ្ឍន៍វីនដូ។ ពេលខ្ញុំបោះចោលជង់អភិវឌ្ឍន៍ Windows ទាំងមូលនៅលើតុ ខ្ញុំបានដឹងថាស្ថានភាពនេះជាការឈឺចាប់...
នេះជារបៀបដែលរឿងចាប់ផ្តើម អាឡិចសាន់ត្រាស៊ីនឈីណូវ៉ា នៅលើ . នៅពេលដែលអ្នកឯកទេស Windows ឈានមុខគេបានចាកចេញពីក្រុមហ៊ុន អាឡិចសាន់ឌឺ ឆ្ងល់ថាតើត្រូវធ្វើអ្វីឥឡូវនេះ។ ប្តូរទៅលីនុច ពិតណាស់! អាឡិចសាន់ឌឺនឹងប្រាប់អ្នកពីរបៀបដែលគាត់បានគ្រប់គ្រងដើម្បីបង្កើតគំរូមុន និងផ្ទេរផ្នែកនៃការអភិវឌ្ឍន៍វីនដូទៅលីនុចដោយប្រើឧទាហរណ៍នៃគម្រោងដែលបានបញ្ចប់សម្រាប់អ្នកប្រើប្រាស់ 100 នាក់។
តើធ្វើដូចម្តេចដើម្បីបញ្ជូនគម្រោងទៅ RPM យ៉ាងងាយស្រួល និងដោយមិនចាំបាច់ប្រើ TFS, Puppet, Linux .NET core? តើធ្វើដូចម្តេចដើម្បីគាំទ្រកំណែនៃមូលដ្ឋានទិន្នន័យគម្រោង ប្រសិនបើក្រុមអភិវឌ្ឍន៍បានឮពាក្យ Postgres និង Flyway ជាលើកដំបូង ហើយថ្ងៃផុតកំណត់គឺជាថ្ងៃបន្ទាប់? តើធ្វើដូចម្តេចដើម្បីរួមបញ្ចូលជាមួយ Docker? តើធ្វើដូចម្តេចដើម្បីជំរុញអ្នកអភិវឌ្ឍន៍ .NET ឱ្យបោះបង់ Windows និង smoothies ដើម្បីពេញចិត្តនឹង Puppet និង Linux? តើធ្វើដូចម្តេចដើម្បីដោះស្រាយជម្លោះមនោគមវិជ្ជា ប្រសិនបើមិនមានកម្លាំង ឬបំណងប្រាថ្នា ឬធនធានដើម្បីរក្សា Windows នៅក្នុងផលិតកម្ម? អំពីបញ្ហានេះ ក៏ដូចជាអំពី Web Deploy, testing, CI អំពីការអនុវត្តនៃការប្រើប្រាស់ TFS នៅក្នុងគម្រោងដែលមានស្រាប់ ហើយពិតណាស់អំពីឈើច្រត់ដែលខូច និងដំណោះស្រាយការងារ នៅក្នុងប្រតិចារឹកនៃរបាយការណ៍របស់ Alexander ។
ដូច្នេះ Vasya បានចាកចេញ ភារកិច្ចគឺស្ថិតនៅលើខ្ញុំអ្នកអភិវឌ្ឍន៍កំពុងរង់ចាំដោយអន្ទះអន្ទែងជាមួយ pitchforks ។ នៅពេលដែលខ្ញុំដឹងថា Vasya មិនអាចត្រលប់មកវិញបាន ខ្ញុំបានចុះទៅរកស៊ី។ ដើម្បីចាប់ផ្តើមជាមួយ ខ្ញុំបានវាយតម្លៃភាគរយនៃ Win VMs នៅក្នុងកងនាវារបស់យើង។ ពិន្ទុមិនពេញចិត្តនឹង Windows ទេ។
ដោយសារយើងកំពុងអភិវឌ្ឍ DevOps យ៉ាងសកម្ម ខ្ញុំបានដឹងថាអ្វីមួយត្រូវការផ្លាស់ប្តូរក្នុងវិធីសាស្រ្តក្នុងការផ្តល់កម្មវិធីថ្មី។ មានដំណោះស្រាយតែមួយគត់ - បើអាចធ្វើបាន ផ្ទេរអ្វីៗគ្រប់យ៉ាងទៅលីនុច។ Google បានជួយខ្ញុំ - នៅពេលនោះ .Net ត្រូវបានបញ្ជូនទៅលីនុចរួចហើយ ហើយខ្ញុំបានដឹងថានេះគឺជាដំណោះស្រាយ!
ហេតុអ្វីបានជាស្នូល .NET ភ្ជាប់ជាមួយលីនុច?
មានហេតុផលជាច្រើនសម្រាប់រឿងនេះ។ រវាង "បង់លុយ" និង "មិនបង់" ភាគច្រើននឹងជ្រើសរើសទីពីរ - ដូចខ្ញុំ។ អាជ្ញាប័ណ្ណសម្រាប់ MSDB មានតម្លៃប្រហែល $1; សម្រាប់ក្រុមហ៊ុនធំនេះគឺជាការចំណាយដ៏ធំមួយ។ នោះហើយជាមូលហេតុដែល សន្សំ - ហេតុផលដំបូង. មិនមែនជាអ្វីដែលសំខាន់បំផុតនោះទេ ប៉ុន្តែសំខាន់បំផុតមួយ។
ម៉ាស៊ីននិម្មិត Windows យកធនធានច្រើនជាងបងប្អូនលីនុចរបស់ពួកគេទៅទៀត - ពួកគេធ្ងន់. ដោយគិតពីទំហំក្រុមហ៊ុនធំ យើងបានជ្រើសរើសលីនុច។
ប្រព័ន្ធនេះត្រូវបានរួមបញ្ចូលយ៉ាងសាមញ្ញទៅក្នុង CI ដែលមានស្រាប់. យើងចាត់ទុកខ្លួនយើងថា DevOps រីកចម្រើន យើងប្រើ Bamboo, Jenkins និង GitLab CI ដូច្នេះការងាររបស់យើងភាគច្រើនដំណើរការលើលីនុច។
ហេតុផលចុងក្រោយគឺ អមដំណើរងាយស្រួល។ យើងត្រូវបន្ថយរបាំងសម្រាប់ការចូលសម្រាប់ "អ្នកអមការពារ" - បុរសដែលយល់ពីផ្នែកបច្ចេកទេស ធានានូវសេវាកម្មដែលមិនមានការរំខាន និងថែរក្សាសេវាកម្មពីជួរទីពីរ។ ពួកគេបានស្គាល់រួចហើយជាមួយជង់លីនុច ដូច្នេះវាកាន់តែងាយស្រួលសម្រាប់ពួកគេក្នុងការយល់ គាំទ្រ និងថែរក្សាផលិតផលថ្មីជាជាងចំណាយធនធានបន្ថែមដើម្បីយល់ពីមុខងារដូចគ្នានៃកម្មវិធីសម្រាប់វេទិកាវីនដូ។
តម្រូវការ
ដំបូងនិងសំខាន់បំផុត - ភាពងាយស្រួលនៃដំណោះស្រាយថ្មីសម្រាប់អ្នកអភិវឌ្ឍន៍. មិនមែនពួកគេទាំងអស់ត្រៀមខ្លួនសម្រាប់ការផ្លាស់ប្តូរនោះទេ ជាពិសេសបន្ទាប់ពីពាក្យលីនុចត្រូវបាននិយាយ។ អ្នកអភិវឌ្ឍន៍ចង់បាន Visual Studio ដែលពួកគេចូលចិត្ត TFS ជាមួយនឹងការធ្វើតេស្តដោយស្វ័យប្រវត្តិសម្រាប់ការជួបប្រជុំគ្នា និង smoothies ។ របៀបដែលការដឹកជញ្ជូនទៅផលិតកម្មកើតឡើងគឺមិនសំខាន់សម្រាប់ពួកគេទេ។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តមិនផ្លាស់ប្តូរដំណើរការធម្មតា ហើយទុកឱ្យអ្វីៗមិនផ្លាស់ប្តូរសម្រាប់ការអភិវឌ្ឍន៍វីនដូ។
ត្រូវការគម្រោងថ្មី។ បញ្ចូលទៅក្នុង CI ដែលមានស្រាប់. ផ្លូវដែកមានរួចហើយ ហើយការងារទាំងអស់ត្រូវធ្វើដោយគិតគូរពីប៉ារ៉ាម៉ែត្រនៃប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ ស្តង់ដារដឹកជញ្ជូនដែលទទួលយក និងប្រព័ន្ធត្រួតពិនិត្យ។
ភាពងាយស្រួលនៃការគាំទ្រ និងប្រតិបត្តិការជាលក្ខខណ្ឌសម្រាប់កម្រិតចូលអប្បបរមាសម្រាប់អ្នកចូលរួមថ្មីទាំងអស់មកពីផ្នែកផ្សេងៗ និងផ្នែកគាំទ្រ។
ថ្ងៃផុតកំណត់ - ម្សិលមិញ.
ក្រុមហ៊ុន Win Development Group
តើក្រុម Windows ធ្វើការជាមួយអ្វីពេលនោះ?
ឥឡូវនេះខ្ញុំអាចនិយាយដោយទំនុកចិត្ត អត្តសញ្ញាណម៉ាស៊ីនបម្រើ ៤ គឺជាជម្រើសឥតគិតថ្លៃសម្រាប់ ADFS ដែលមានសមត្ថភាពស្រដៀងគ្នា ឬអ្វី ស្នូលក្របខ័ណ្ឌអង្គភាព - ឋានសួគ៌សម្រាប់អ្នកអភិវឌ្ឍន៍ ដែលអ្នកមិនចាំបាច់រំខានការសរសេរស្គ្រីប SQL ប៉ុន្តែពណ៌នាសំណួរនៅក្នុងមូលដ្ឋានទិន្នន័យក្នុងលក្ខខណ្ឌ OOP ។ ប៉ុន្តែបន្ទាប់មក ក្នុងអំឡុងពេលពិភាក្សាអំពីផែនការសកម្មភាព ខ្ញុំបានមើលទៅលើជង់នេះ ហាក់ដូចជាវាជាទម្រង់ Sumerian cuneiform ដោយទទួលស្គាល់តែ PostgreSQL និង Git ប៉ុណ្ណោះ។
នៅពេលនោះយើងកំពុងប្រើយ៉ាងសកម្ម Puppet ជាប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ។ នៅក្នុងគម្រោងរបស់យើងភាគច្រើនយើងបានប្រើ GitLab ស៊ីអាយ, យឺតសេវាផ្ទុកខ្ពស់ប្រកបដោយតុល្យភាពដោយប្រើ HAProxy បានត្រួតពិនិត្យអ្វីគ្រប់យ៉ាងជាមួយ Zabbix, សរសៃចង ហ្គ្រេណាណា и Prometheus, នាងហិនទ័រហើយអ្វីៗទាំងអស់នេះត្រូវបានបង្វិលលើបំណែកដែក HP c ESXi នៅលើ VMware. មនុស្សគ្រប់គ្នាស្គាល់វា - បុរាណនៃប្រភេទ។
សូមក្រឡេកមើល ហើយព្យាយាមយល់ពីអ្វីដែលបានកើតឡើង មុនពេលយើងចាប់ផ្តើមអន្តរាគមន៍ទាំងអស់នេះ។
តើមានអ្វីកើតឡើង
TFS គឺជាប្រព័ន្ធដ៏មានអានុភាពដែលមិនត្រឹមតែផ្តល់លេខកូដពីអ្នកអភិវឌ្ឍន៍ទៅកាន់ម៉ាស៊ីនផលិតចុងក្រោយប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានសំណុំសម្រាប់ការរួមបញ្ចូលដែលអាចបត់បែនបានជាមួយនឹងសេវាកម្មផ្សេងៗផងដែរ - ដើម្បីផ្តល់ CI នៅកម្រិតឆ្លងវេទិកា។
ពីមុនទាំងនេះគឺជាបង្អួចរឹង។ TFS បានប្រើភ្នាក់ងារសាងសង់ជាច្រើន ដែលត្រូវបានប្រើដើម្បីប្រមូលផ្តុំគម្រោងជាច្រើន។ ភ្នាក់ងារនីមួយៗមានកម្មករពី 3 ទៅ 4 នាក់ ដើម្បីបំពេញការងារស្របគ្នា និងបង្កើនប្រសិទ្ធភាពដំណើរការ។ បន្ទាប់មក យោងតាមផែនការចេញផ្សាយ TFS បានបញ្ជូន Build ដែលទើបតែដុតនំថ្មីៗទៅកាន់ម៉ាស៊ីនមេកម្មវិធីវីនដូ។
តើយើងចង់សម្រេចបានអ្វីខ្លះ?
យើងប្រើ TFS សម្រាប់ការដឹកជញ្ជូន និងការអភិវឌ្ឍន៍ ហើយដំណើរការកម្មវិធីនៅលើម៉ាស៊ីនមេកម្មវិធីលីនុច ហើយវាមានប្រភេទវេទមន្តមួយចំនួនរវាងពួកវា។ នេះ។ ប្រអប់វេទមន្ត។ ហើយមានអំបិលនៃការងារនៅខាងមុខ។ មុននឹងខ្ញុំដកវាចេញ ខ្ញុំនឹងបោះជំហានមួយឡែក ហើយនិយាយពាក្យពីរបីអំពីកម្មវិធី។
គម្រោង
កម្មវិធីផ្តល់នូវមុខងារសម្រាប់គ្រប់គ្រងកាតបង់ប្រាក់ជាមុន។
ម៉ាស៊ីនភ្ញៀវ
មានអ្នកប្រើប្រាស់ពីរប្រភេទ។ ដំបូង ទទួលបានការចូលប្រើដោយការចូលដោយប្រើវិញ្ញាបនបត្រ SSL SHA-2 ។ យូ ទីពីរ មានការចូលប្រើប្រាស់ដោយប្រើការចូល និងពាក្យសម្ងាត់។
HAProxy
បន្ទាប់មកសំណើអតិថិជនបានទៅ HAProxy ដែលដោះស្រាយបញ្ហាដូចខាងក្រោមៈ
- ការអនុញ្ញាតបឋម;
- ការបញ្ចប់ SSL;
- លៃតម្រូវសំណើ HTTP;
- ការស្នើសុំការផ្សាយ។
វិញ្ញាបនបត្រអតិថិជនត្រូវបានផ្ទៀងផ្ទាត់តាមខ្សែសង្វាក់។ យើង - អំណាច ហើយយើងអាចមានលទ្ធភាពទិញនេះ ចាប់តាំងពីយើងខ្លួនយើងចេញវិញ្ញាបនបត្រដល់អតិថិជនសេវាកម្ម។
យកចិត្តទុកដាក់លើចំណុចទី 3 យើងនឹងត្រលប់ទៅវាបន្តិចក្រោយមក។
កម្មវិធីខាងក្រោយ។
ពួកគេគ្រោងបង្កើតកម្មវិធីខាងក្រោយនៅលើលីនុច។ កម្មវិធីខាងក្រោយធ្វើអន្តរកម្មជាមួយមូលដ្ឋានទិន្នន័យ ផ្ទុកបញ្ជីសិទ្ធិចាំបាច់ ហើយបន្ទាប់មក អាស្រ័យលើសិទ្ធិរបស់អ្នកប្រើប្រាស់ដែលមានការអនុញ្ញាត ផ្តល់សិទ្ធិចូលប្រើប្រាស់ដើម្បីចុះហត្ថលេខាលើឯកសារហិរញ្ញវត្ថុ និងផ្ញើពួកវាសម្រាប់ប្រតិបត្តិ ឬបង្កើតរបាយការណ៍មួយចំនួន។
ការសន្សំជាមួយ HAProxy
បន្ថែមពីលើបរិបទពីរដែលអតិថិជននីមួយៗបានរុករក វាក៏មានបរិបទអត្តសញ្ញាណផងដែរ។ អត្តសញ្ញាណម៉ាស៊ីនបម្រើ ៤ គ្រាន់តែអនុញ្ញាតឱ្យអ្នកចូល, នេះគឺជា analogue ឥតគិតថ្លៃនិងមានអនុភាពសម្រាប់ ADFS - សេវាកម្មសហព័ន្ធថតសកម្ម.
សំណើសុំអត្តសញ្ញាណត្រូវបានដំណើរការក្នុងជំហានជាច្រើន។ ជំហានដំបូង - អតិថិជន បានចូលទៅក្នុងផ្នែកខាងក្រោយដែលបានទាក់ទងជាមួយម៉ាស៊ីនមេនេះ និងបានពិនិត្យវត្តមាននៃសញ្ញាសម្ងាត់សម្រាប់ម៉ាស៊ីនភ្ញៀវ។ ប្រសិនបើវាមិនត្រូវបានរកឃើញ សំណើត្រូវបានបញ្ជូនត្រឡប់ទៅបរិបទដែលវាបានមក ប៉ុន្តែជាមួយនឹងការបញ្ជូនបន្ត ហើយជាមួយនឹងការប្តូរទិស វាបានទៅអត្តសញ្ញាណ។
ជំហានទីពីរ - សំណើត្រូវបានទទួល ទៅទំព័រអនុញ្ញាតក្នុង IdentityServer, ដែលជាកន្លែងដែលអតិថិជនបានចុះឈ្មោះ ហើយសញ្ញាសម្ងាត់ដែលបានរង់ចាំជាយូរមកហើយនោះបានបង្ហាញខ្លួននៅក្នុងមូលដ្ឋានទិន្នន័យ IdentityServer ។
ជំហានទីបី - អតិថិជនត្រូវបានបញ្ជូនបន្តត្រឡប់មកវិញ ទៅនឹងបរិបទដែលវាបានមក។
IdentityServer4 មានមុខងារមួយ៖ វាត្រឡប់ការឆ្លើយតបទៅនឹងសំណើត្រឡប់មកវិញតាមរយៈ HTTP. មិនថាយើងតស៊ូជាមួយការដំឡើងម៉ាស៊ីនមេប៉ុណ្ណាទេ មិនថាយើងបំភ្លឺខ្លួនយើងជាមួយឯកសារប៉ុណ្ណានោះទេ រាល់ពេលដែលយើងទទួលបានសំណើអតិថិជនដំបូងជាមួយ URL ដែលមកតាមរយៈ HTTPS ហើយ IdentityServer ត្រឡប់បរិបទដូចគ្នា ប៉ុន្តែជាមួយ HTTP ។ យើងភ្ញាក់ផ្អើល! ហើយយើងបានផ្ទេរអ្វីៗទាំងអស់នេះតាមរយៈបរិបទអត្តសញ្ញាណទៅ HAProxy ហើយនៅក្នុងបឋមកថា យើងត្រូវកែប្រែពិធីការ HTTP ទៅ HTTPS ។
តើអ្វីជាការកែលម្អ ហើយតើអ្នកសន្សំនៅឯណា?
យើងបានសន្សំប្រាក់ដោយប្រើដំណោះស្រាយឥតគិតថ្លៃសម្រាប់ការផ្តល់សិទ្ធិដល់ក្រុមអ្នកប្រើប្រាស់ ធនធាន ដោយសារយើងមិនបានដាក់ IdentityServer4 ជាថ្នាំងដាច់ដោយឡែកនៅក្នុងផ្នែកដាច់ដោយឡែកមួយ ប៉ុន្តែបានប្រើវារួមគ្នាជាមួយផ្នែកខាងក្រោយនៅលើម៉ាស៊ីនមេដូចគ្នា ដែលផ្នែកខាងក្រោយនៃកម្មវិធីដំណើរការ។ .
របៀបដែលវាគួរតែដំណើរការ
ដូច្នេះដូចដែលខ្ញុំបានសន្យា - ប្រអប់វេទមន្ត។ យើងយល់រួចហើយថាយើងត្រូវបានធានាដើម្បីឆ្ពោះទៅរកលីនុច។ ចូរយើងបង្កើតកិច្ចការជាក់លាក់ដែលទាមទារដំណោះស្រាយ។
អាយ៉ងបង្ហាញ។ ដើម្បីចែកចាយ និងគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធកម្មវិធី និងសេវាកម្ម រូបមន្តត្រជាក់ត្រូវតែសរសេរ។ ខ្មៅដៃមួយរំកិលបង្ហាញឱ្យឃើញពីរបៀបដែលវាត្រូវបានធ្វើយ៉ាងរហ័ស និងមានប្រសិទ្ធភាព។
វិធីសាស្រ្តដឹកជញ្ជូន។ ស្តង់ដារគឺ RPM ។ មនុស្សគ្រប់គ្នាយល់ថានៅក្នុងលីនុចអ្នកមិនអាចធ្វើបានដោយគ្មានវាទេប៉ុន្តែគម្រោងខ្លួនវាបន្ទាប់ពីការជួបប្រជុំគ្នាគឺជាសំណុំនៃឯកសារ DLL ដែលអាចប្រតិបត្តិបាន។ មានប្រហែល 150 នាក់ គម្រោងនេះពិបាកណាស់។ ដំណោះស្រាយចុះសម្រុងគ្នាតែមួយគត់គឺត្រូវខ្ចប់ប្រព័ន្ធគោលពីរនេះទៅក្នុង RPM ហើយដាក់ពង្រាយកម្មវិធីពីវា។
កំណែ។ យើងត្រូវតែបញ្ចេញជាញឹកញាប់ ហើយយើងត្រូវសម្រេចចិត្តពីរបៀបបង្កើតឈ្មោះកញ្ចប់។ នេះគឺជាសំណួរនៃកម្រិតនៃការរួមបញ្ចូលជាមួយ TFS ។ យើងមានភ្នាក់ងារបង្កើតនៅលើលីនុច។ នៅពេល TFS ផ្ញើភារកិច្ចទៅអ្នកដោះស្រាយ - កម្មករ - ទៅភ្នាក់ងារបង្កើត វាក៏បញ្ជូនវានូវអថេរជាច្រើនដែលបញ្ចប់នៅក្នុងបរិយាកាសនៃដំណើរការអ្នកដោះស្រាយ។ អថេរបរិស្ថានទាំងនេះមាន ឈ្មោះ Build ឈ្មោះកំណែ និងអថេរផ្សេងទៀត។ សូមអានបន្ថែមអំពីរឿងនេះនៅក្នុងផ្នែក "ការកសាងកញ្ចប់ RPM" ។
ការដំឡើង TFS បានចុះមករៀបចំបំពង់បង្ហូរប្រេង។ ពីមុន យើងបានប្រមូលគម្រោង Windows ទាំងអស់នៅលើភ្នាក់ងារ Windows ប៉ុន្តែឥឡូវនេះភ្នាក់ងារលីនុចលេចឡើង - ភ្នាក់ងារ Build ដែលត្រូវការបញ្ចូលក្នុងក្រុមសាងសង់ សំបូរទៅដោយវត្ថុបុរាណមួយចំនួន ហើយប្រាប់ថាតើគម្រោងប្រភេទណាដែលនឹងត្រូវបានបង្កើតនៅលើភ្នាក់ងារ Build នេះ។ និងកែប្រែបំពង់បង្ហូរប្រេងដោយរបៀបណា។
អត្តសញ្ញាណម៉ាស៊ីនបម្រើ ADFS មិនមែនជាផ្លូវរបស់យើងទេ យើងនឹងស្វែងរកប្រភពបើកចំហ។
ចូរយើងឆ្លងកាត់សមាសធាតុ។
ប្រអប់វេទមន្ត។
មានបួនផ្នែក។
ភ្នាក់ងារបង្កើតលីនុច។ លីនុច ពីព្រោះយើងបង្កើតសម្រាប់វា - វាជាឡូជីខល។ ផ្នែកនេះត្រូវបានធ្វើឡើងជាបីជំហាន។
- កំណត់រចនាសម្ព័ន្ធកម្មករ ហើយមិនមែនតែម្នាក់ឯងទេ ចាប់តាំងពីការងារចែកចាយលើគម្រោងត្រូវបានរំពឹងទុក។
- ដំឡើង .NET Core 1.x. ហេតុអ្វីបានជា 1.x នៅពេលដែល 2.0 មានរួចហើយនៅក្នុងឃ្លាំងស្ដង់ដារ? ដោយសារតែនៅពេលដែលយើងចាប់ផ្តើមការអភិវឌ្ឍន៍ កំណែដែលមានស្ថេរភាពគឺ 1.09 ហើយវាត្រូវបានសម្រេចចិត្តបង្កើតគម្រោងដោយផ្អែកលើវា។
- Git 2.x.
RPM-ឃ្លាំង។ កញ្ចប់ RPM ត្រូវការរក្សាទុកនៅកន្លែងណាមួយ។ វាត្រូវបានគេសន្មត់ថាយើងនឹងប្រើឃ្លាំង RPM របស់ក្រុមហ៊ុនដូចគ្នាដែលមានសម្រាប់ម៉ាស៊ីនលីនុចទាំងអស់។ នោះហើយជាអ្វីដែលពួកគេបានធ្វើ។ ម៉ាស៊ីនមេឃ្លាំងត្រូវបានកំណត់រចនាសម្ព័ន្ធ ទំពក់គេហទំព័រ ដែលបានទាញយកកញ្ចប់ RPM ដែលត្រូវការពីទីតាំងដែលបានបញ្ជាក់។ កំណែកញ្ចប់ត្រូវបានរាយការណ៍ទៅ webhook ដោយភ្នាក់ងារ Build ។
ហ្គីតឡាប។ យកចិត្តទុកដាក់! GitLab នៅទីនេះមិនត្រូវបានប្រើដោយអ្នកអភិវឌ្ឍន៍ទេ ប៉ុន្តែដោយនាយកដ្ឋានប្រតិបត្តិការដើម្បីគ្រប់គ្រងកំណែកម្មវិធី កំណែកញ្ចប់ តាមដានស្ថានភាពនៃម៉ាស៊ីនលីនុចទាំងអស់ ហើយវារក្សាទុករូបមន្ត - ការបង្ហាញអាយ៉ងទាំងអស់។
Puppet - ដោះស្រាយបញ្ហាចម្រូងចម្រាសទាំងអស់ និងផ្តល់នូវការកំណត់រចនាសម្ព័ន្ធដែលយើងចង់បានពី Gitlab ។
យើងចាប់ផ្តើមមុជទឹក។ តើការដឹកជញ្ជូន DLL ទៅ RPM ដំណើរការយ៉ាងដូចម្តេច?
ការដឹកជញ្ជូន DDL ទៅ RPM
ឧបមាថាយើងមានតារារ៉ុកអភិវឌ្ឍន៍ .NET ។ វាប្រើ Visual Studio និងបង្កើតសាខាចេញផ្សាយ។ បន្ទាប់ពីនោះវាផ្ទុកវាទៅ Git ហើយ Git នៅទីនេះគឺជាអង្គភាព TFS ពោលគឺវាជាឃ្លាំងកម្មវិធីដែលអ្នកអភិវឌ្ឍន៍ធ្វើការ។
បន្ទាប់ពីនោះ TFS ឃើញថាការប្តេជ្ញាចិត្តថ្មីមួយបានមកដល់។ កម្មវិធីមួយណា? នៅក្នុងការកំណត់ TFS មានស្លាកមួយដែលបង្ហាញពីធនធានដែលភ្នាក់ងារបង្កើតជាក់លាក់មាន។ ក្នុងករណីនេះ គាត់មើលឃើញថាយើងកំពុងបង្កើតគម្រោង .NET Core ហើយជ្រើសរើសភ្នាក់ងារ Linux Build ពីអាង។
ភ្នាក់ងារ Build ទទួលបានប្រភព និងទាញយកអ្វីដែលចាំបាច់ ភាពអាស្រ័យ ពីឃ្លាំង .NET, npm ជាដើម។ ហើយបន្ទាប់ពីបង្កើតកម្មវិធីដោយខ្លួនឯង និងការវេចខ្ចប់ជាបន្តបន្ទាប់ ផ្ញើកញ្ចប់ RPM ទៅឃ្លាំង RPM ។
ម៉្យាងវិញទៀត ហេតុការណ៍ខាងក្រោមនេះកើតឡើង។ វិស្វករផ្នែកប្រតិបត្តិការត្រូវបានចូលរួមដោយផ្ទាល់នៅក្នុងការចាប់ផ្តើមនៃគម្រោងនេះ: គាត់ផ្លាស់ប្តូរកំណែនៃកញ្ចប់នៅក្នុង ហៀរ៉ា នៅក្នុងឃ្លាំងដែលរូបមន្តកម្មវិធីត្រូវបានរក្សាទុក បន្ទាប់ពីនោះអាយ៉ងកេះ យ៉ុមទាញយកកញ្ចប់ថ្មីពីឃ្លាំង ហើយកំណែថ្មីនៃកម្មវិធីគឺរួចរាល់ក្នុងការប្រើប្រាស់។
អ្វីគ្រប់យ៉ាងគឺសាមញ្ញនៅក្នុងពាក្យ ប៉ុន្តែតើមានអ្វីកើតឡើងនៅក្នុងភ្នាក់ងារ Build ខ្លួនវា?
ការវេចខ្ចប់ DLL RPM
បានទទួលប្រភពគម្រោង និងបង្កើតកិច្ចការពី TFS ។ ភ្នាក់ងារសាងសង់ ចាប់ផ្តើមសាងសង់គម្រោងដោយខ្លួនឯងពីប្រភព. គម្រោងដែលបានផ្គុំគឺអាចរកបានជាសំណុំ ឯកសារ DLLដែលត្រូវបានខ្ចប់ក្នុងប័ណ្ណសារហ្ស៊ីប ដើម្បីកាត់បន្ថយការផ្ទុកនៅលើប្រព័ន្ធឯកសារ។
ប័ណ្ណសារហ្ស៊ីបត្រូវបានបោះចោល ទៅថតឯកសារបង្កើតកញ្ចប់ RPM ។ បន្ទាប់មក ស្គ្រីប Bash ចាប់ផ្តើមអថេរបរិស្ថាន ស្វែងរកកំណែ Build កំណែគម្រោង ផ្លូវទៅកាន់ថតឯកសារ និងដំណើរការ RPM-build ។ នៅពេលដែលការស្ថាបនាត្រូវបានបញ្ចប់ កញ្ចប់នេះត្រូវបានបោះពុម្ពផ្សាយទៅ ឃ្លាំងក្នុងស្រុកដែលមានទីតាំងនៅលើភ្នាក់ងារ Build ។
បន្ទាប់ ពីភ្នាក់ងារ Build ទៅម៉ាស៊ីនមេនៅក្នុងឃ្លាំង RPM សំណើ JSON ត្រូវបានផ្ញើ បង្ហាញឈ្មោះនៃកំណែនិងស្ថាបនា។ Webhook ដែលខ្ញុំបាននិយាយអំពីមុននេះ ទាញយកកញ្ចប់នេះពីឃ្លាំងមូលដ្ឋាននៅលើភ្នាក់ងារ Build និងធ្វើឱ្យការជួបប្រជុំគ្នាថ្មីមានសម្រាប់ដំឡើង។
ហេតុអ្វីបានជាគម្រោងចែកចាយកញ្ចប់ពិសេសនេះទៅកាន់ឃ្លាំង RPM? ហេតុអ្វីបានជាខ្ញុំមិនអាចផ្ញើកញ្ចប់ដែលបានជួបប្រជុំគ្នាភ្លាមៗទៅកាន់ឃ្លាំង? ការពិតគឺថានេះគឺជាលក្ខខណ្ឌសម្រាប់ការធានាសុវត្ថិភាព។ សេណារីយ៉ូនេះកំណត់លទ្ធភាពនៃមនុស្សដែលគ្មានការអនុញ្ញាតក្នុងការបង្ហោះកញ្ចប់ RPM ទៅកាន់ម៉ាស៊ីនមេដែលអាចចូលប្រើបានសម្រាប់ម៉ាស៊ីនលីនុចទាំងអស់។
កំណែមូលដ្ឋានទិន្នន័យ
នៅឯការពិគ្រោះយោបល់ជាមួយក្រុមអភិវឌ្ឍន៍ វាបានប្រែក្លាយថាបុរសទាំងនោះកាន់តែជិតស្និទ្ធជាមួយ MS SQL ប៉ុន្តែនៅក្នុងគម្រោងដែលមិនមែនជាវីនដូភាគច្រើន យើងបានប្រើប្រាស់ PostgreSQL អស់ពីសមត្ថភាពរបស់ពួកគេ។ ដោយសារយើងបានសម្រេចចិត្តបោះបង់អ្វីៗទាំងអស់ដែលបានបង់រួចហើយ យើងក៏ចាប់ផ្តើមប្រើ PostgreSQL នៅទីនេះផងដែរ។
នៅក្នុងផ្នែកនេះ ខ្ញុំចង់ប្រាប់អ្នកពីរបៀបដែលយើងកំណែមូលដ្ឋានទិន្នន័យ និងរបៀបដែលយើងជ្រើសរើសរវាង Flyway និង Entity Framework Core ។ សូមក្រឡេកមើលគុណសម្បត្តិនិងគុណវិបត្តិរបស់ពួកគេ។
Минусы
ផ្លូវហោះហើរទៅតែមួយផ្លូវយើង យើងមិនអាចវិលត្រឡប់មកវិញបានទេ។ - នេះគឺជាគុណវិបត្តិដ៏សំខាន់។ អ្នកអាចប្រៀបធៀបវាជាមួយ Entity Framework Core តាមវិធីផ្សេងទៀត - ទាក់ទងនឹងភាពងាយស្រួលរបស់អ្នកអភិវឌ្ឍន៍។ អ្នកចាំថាយើងដាក់ចំណុចនេះនៅជួរមុខ ហើយលក្ខណៈវិនិច្ឆ័យសំខាន់គឺមិនត្រូវផ្លាស់ប្តូរអ្វីទាំងអស់សម្រាប់ការអភិវឌ្ឍន៍វីនដូ។
សម្រាប់ Flyway យើង ប្រភេទនៃការរុំមួយចំនួនត្រូវបានត្រូវការដូច្នេះថាបុរសមិនសរសេរ សំណួរ SQL. ពួកគេកាន់តែខិតទៅជិតប្រតិបត្តិការនៅក្នុងលក្ខខណ្ឌ OOP ។ យើងបានសរសេរការណែនាំសម្រាប់ធ្វើការជាមួយវត្ថុមូលដ្ឋានទិន្នន័យ បង្កើតសំណួរ SQL និងប្រតិបត្តិវា។ កំណែថ្មីនៃមូលដ្ឋានទិន្នន័យគឺរួចរាល់ សាកល្បង - អ្វីគ្រប់យ៉ាងគឺល្អ អ្វីគ្រប់យ៉ាងដំណើរការ។
Entity Framework Core មានដក - នៅក្រោមបន្ទុកធ្ងន់ បង្កើតសំណួរ SQL ល្អបំផុតហើយការដកថយក្នុងមូលដ្ឋានទិន្នន័យអាចមានសារៈសំខាន់។ ប៉ុន្តែដោយសារយើងមិនមានសេវាកម្មផ្ទុកខ្ពស់ យើងមិនបានគណនាបន្ទុកជា RPS រាប់រយ យើងបានទទួលយកហានិភ័យទាំងនេះ ហើយបានផ្ទេរបញ្ហាទៅឱ្យយើងនាពេលអនាគត។
ផត
ស្នូលក្របខ័ណ្ឌអង្គភាព ធ្វើការចេញពីប្រអប់ ហើយងាយស្រួលក្នុងការអភិវឌ្ឍនិង Flyway រួមបញ្ចូលយ៉ាងងាយស្រួលទៅក្នុង CI ដែលមានស្រាប់. ប៉ុន្តែយើងធ្វើឱ្យវាងាយស្រួលសម្រាប់អ្នកអភិវឌ្ឍន៍ :)
នីតិវិធីរមៀលឡើង
អាយ៉ងមើលឃើញថាការផ្លាស់ប្តូរនៅក្នុងកំណែកញ្ចប់នឹងមកដល់រួមទាំងការទទួលខុសត្រូវសម្រាប់ការធ្វើចំណាកស្រុក។ ជាដំបូង វាដំឡើងកញ្ចប់មួយដែលមានស្គ្រីបផ្ទេរទិន្នន័យ និងមុខងារដែលទាក់ទងនឹងមូលដ្ឋានទិន្នន័យ។ បន្ទាប់ពីនេះ កម្មវិធីដែលធ្វើការជាមួយមូលដ្ឋានទិន្នន័យត្រូវបានចាប់ផ្តើមឡើងវិញ។ បន្ទាប់គឺការដំឡើងសមាសធាតុដែលនៅសល់។ លំដាប់ដែលកញ្ចប់ត្រូវបានដំឡើង និងកម្មវិធីត្រូវបានដាក់ឱ្យដំណើរការត្រូវបានពិពណ៌នានៅក្នុងការបង្ហាញអាយ៉ង។
កម្មវិធីប្រើប្រាស់ទិន្នន័យរសើប ដូចជា ថូខឹន ពាក្យសម្ងាត់ មូលដ្ឋានទិន្នន័យ អ្វីៗទាំងអស់នេះត្រូវបានទាញចូលទៅក្នុងការកំណត់រចនាសម្ព័ន្ធពីមេ Puppet ដែលពួកវាត្រូវបានរក្សាទុកក្នុងទម្រង់ដែលបានអ៊ិនគ្រីប។
បញ្ហា TFS
បន្ទាប់ពីយើងបានសម្រេចចិត្ត និងដឹងថាអ្វីៗពិតជាដំណើរការសម្រាប់យើង ខ្ញុំបានសម្រេចចិត្តរកមើលអ្វីដែលកំពុងកើតឡើងជាមួយនឹងការជួបប្រជុំគ្នានៅក្នុង TFS ទាំងមូលសម្រាប់ផ្នែកអភិវឌ្ឍន៍ Win លើគម្រោងផ្សេងទៀត - ថាតើយើងកំពុងសាងសង់ / ចេញផ្សាយយ៉ាងឆាប់រហ័សឬអត់ ហើយ បានរកឃើញបញ្ហាសំខាន់ៗជាមួយនឹងល្បឿន។
គម្រោងសំខាន់មួយត្រូវចំណាយពេល 12-15 នាទីដើម្បីប្រមូលផ្តុំ - នោះជារយៈពេលយូរ អ្នកមិនអាចរស់នៅដូចនោះទេ។ ការវិភាគរហ័សបានបង្ហាញពីការធ្លាក់ចុះដ៏គួរឱ្យភ័យខ្លាចនៅក្នុង I/O ហើយនេះគឺនៅលើអារេ។
បន្ទាប់ពីការវិភាគវាដោយសមាសភាគខ្ញុំបានកំណត់អត្តសញ្ញាណ foci ចំនួនបី។ ដំបូង - "កំចាត់មេរោគ Kaspersky"ដែលស្កេនប្រភពនៅលើភ្នាក់ងារ Windows Build ទាំងអស់។ ទីពីរ - ប្រព័ន្ធប្រតិបត្តិការ Windows សន្ទស្សន៍។ វាមិនត្រូវបានបិទទេ ហើយអ្វីគ្រប់យ៉ាងត្រូវបានធ្វើលិបិក្រមក្នុងពេលពិតប្រាកដនៅលើភ្នាក់ងារ Build កំឡុងពេលដំណើរការដាក់ពង្រាយ។
ទីបី - ដំឡើង Npm ។ វាប្រែថានៅក្នុងបំពង់ភាគច្រើនយើងបានប្រើសេណារីយ៉ូពិតប្រាកដនេះ។ ហេតុអ្វីបានជាគាត់អាក្រក់? នីតិវិធីដំឡើង Npm ត្រូវបានដំណើរការនៅពេលដែលមែកធាងអាស្រ័យត្រូវបានបង្កើតឡើង កញ្ចប់-lock.jsonដែលជាកន្លែងដែលកំណែនៃកញ្ចប់ដែលនឹងត្រូវបានប្រើដើម្បីសាងសង់គម្រោងត្រូវបានកត់ត្រា។ គុណវិបត្តិគឺថាការដំឡើង Npm ទាញកញ្ចប់កំណែចុងក្រោយបំផុតពីអ៊ីនធឺណិតរាល់ពេល ហើយវានឹងចំណាយពេលច្រើនក្នុងករណីគម្រោងធំ។
ពេលខ្លះអ្នកអភិវឌ្ឍន៍ពិសោធន៍លើម៉ាស៊ីនក្នុងស្រុក ដើម្បីសាកល្បងពីរបៀបដែលផ្នែកជាក់លាក់មួយ ឬគម្រោងទាំងមូលដំណើរការ។ ពេលខ្លះវាបានប្រែក្លាយថាអ្វីគ្រប់យ៉ាងគឺត្រជាក់នៅក្នុងស្រុក ប៉ុន្តែពួកគេបានប្រមូលផ្តុំវា រមៀលវាចេញ ហើយគ្មានអ្វីដំណើរការទេ។ យើងចាប់ផ្តើមស្វែងយល់ថាតើបញ្ហាគឺជាអ្វី - បាទ កំណែផ្សេងៗគ្នានៃកញ្ចប់ដែលមានភាពអាស្រ័យ។
ការសម្រេចចិត្ត
- ប្រភពនៅក្នុងការលើកលែង AV ។
- បិទការធ្វើលិបិក្រម។
- ទៅ npm ស៊ី.
គុណសម្បត្តិរបស់ npm ci គឺយើង យើងប្រមូលមែកធាងអាស្រ័យម្តងហើយយើងទទួលបានឱកាសដើម្បីផ្តល់ជូនអ្នកអភិវឌ្ឍន៍ បញ្ជីកញ្ចប់បច្ចុប្បន្នដែលគាត់អាចពិសោធន៍ក្នុងស្រុកបានច្រើនតាមដែលគាត់ចូលចិត្ត។ នេះ។ សន្សំពេលវេលា អ្នកអភិវឌ្ឍន៍ដែលសរសេរកូដ។
ការកំណត់រចនាសម្ព័ន្ធ
ឥឡូវនេះបន្តិចអំពីការកំណត់រចនាសម្ព័ន្ធឃ្លាំង។ យើងប្រើជាប្រវត្តិសាស្ត្រ ទូរស័ព្ទ Nexus សម្រាប់ការគ្រប់គ្រងឃ្លាំង រួមទាំង REPO ផ្ទៃក្នុង. ឃ្លាំងខាងក្នុងនេះមានធាតុផ្សំទាំងអស់ដែលយើងប្រើសម្រាប់គោលបំណងផ្ទៃក្នុង ឧទាហរណ៍ ការត្រួតពិនិត្យដែលសរសេរដោយខ្លួនឯង។
យើងក៏ប្រើដែរ។ នូហ្គេតដោយសារតែវាមានឃ្លាំងសម្ងាត់ប្រសើរជាងបើធៀបនឹងអ្នកគ្រប់គ្រងកញ្ចប់ផ្សេងទៀត។
លទ្ធផល
បន្ទាប់ពីយើងបង្កើនប្រសិទ្ធភាព Build Agents ពេលវេលាសាងសង់ជាមធ្យមត្រូវបានកាត់បន្ថយពី 12 នាទីមក 7 ។
ប្រសិនបើយើងរាប់ម៉ាស៊ីនទាំងអស់ដែលយើងអាចប្រើសម្រាប់ Windows ប៉ុន្តែបានប្ដូរទៅ Linux ក្នុងគម្រោងនេះ យើងសន្សំបានប្រហែល 10 ដុល្លារ ហើយវាគ្រាន់តែនៅលើអាជ្ញាប័ណ្ណ និងច្រើនទៀតប្រសិនបើយើងគិតអំពីខ្លឹមសារ។
ផែនការ
សម្រាប់ត្រីមាសបន្ទាប់ យើងគ្រោងនឹងធ្វើការលើការបង្កើនប្រសិទ្ធភាពការចែកចាយកូដ។
ប្តូរទៅរូបភាព Docker ដែលបង្កើតជាមុន. TFS គឺជារឿងដ៏ត្រជាក់មួយជាមួយនឹងកម្មវិធីជំនួយជាច្រើនដែលអនុញ្ញាតឱ្យអ្នកបញ្ចូលទៅក្នុង Pipeline រួមទាំងការជួបប្រជុំគ្នាដែលមានមូលដ្ឋានលើគន្លឹះនៃរូបភាព Docker ។ យើងចង់បង្កើតគន្លឹះនេះសម្រាប់តែមួយ កញ្ចប់-lock.json. ប្រសិនបើសមាសភាពនៃសមាសធាតុដែលប្រើសម្រាប់សាងសង់គម្រោងផ្លាស់ប្តូរដូចម្ដេច យើងបង្កើតរូបភាព Docker ថ្មី។ ក្រោយមកវាត្រូវបានប្រើដើម្បីដាក់ពង្រាយកុងតឺន័រជាមួយនឹងកម្មវិធីដែលបានជួបប្រជុំគ្នា។ នេះមិនមែនជាករណីទេឥឡូវនេះ ប៉ុន្តែយើងគ្រោងនឹងប្តូរទៅស្ថាបត្យកម្មមីក្រូសេវាកម្មនៅក្នុង Kubernetes ដែលកំពុងអភិវឌ្ឍយ៉ាងសកម្មនៅក្នុងក្រុមហ៊ុនរបស់យើង និងបានបម្រើដំណោះស្រាយផលិតកម្មអស់រយៈពេលជាយូរ។
សង្ខេប
ខ្ញុំលើកទឹកចិត្តអ្នករាល់គ្នាឲ្យបោះចោល Windows ប៉ុន្តែវាមិនមែនដោយសារខ្ញុំមិនចេះចម្អិនវាទេ។ ហេតុផលគឺថាដំណោះស្រាយ Opensource ភាគច្រើនគឺ ជង់លីនុច. អ្នកមិនអីទេឬ សន្សំលើធនធាន. តាមគំនិតរបស់ខ្ញុំ អនាគតជាកម្មសិទ្ធិរបស់ដំណោះស្រាយប្រភពបើកចំហនៅលើលីនុចជាមួយនឹងសហគមន៍ដ៏មានឥទ្ធិពល។
ប្រវត្តិរូបរបស់វាគ្មិន Alexander Sinchinov .
គឺជាសន្និសីទស្តីពីការរួមបញ្ចូលនៃការអភិវឌ្ឍន៍ ការធ្វើតេស្ត និងដំណើរការប្រតិបត្តិការសម្រាប់អ្នកជំនាញដោយអ្នកជំនាញ។ នោះហើយជាមូលហេតុដែលគម្រោងដែល Alexander និយាយអំពី? បានអនុវត្តនិងដំណើរការហើយនៅថ្ងៃនៃការសម្តែងមានការចេញផ្សាយជោគជ័យចំនួនពីរ។ បើក នៅថ្ងៃទី 27 និង 28 ខែឧសភានឹងមានករណីស្រដៀងគ្នាកាន់តែច្រើនពីអ្នកអនុវត្ត។ អ្នកនៅតែអាចលោតចូលទៅក្នុងរទេះរុញចុងក្រោយ ឬយកពេលវេលារបស់អ្នក។ សំបុត្រ។ ជួបយើងនៅ Skolkovo!
ប្រភព: www.habr.com