Microsoft Azure DevOps

មាតិកា៖

• សង្ខេប
  • បញ្ហា
  • ការសម្រេចចិត្ត
  • ស្ថានភាព
• ព័ត៌មានលម្អិត
  • ការសន្មត់
  • ឧបសគ្គ
  • ជំហរ
  • អាគុយម៉ង់
  • ផលវិបាក
• ពាក់ព័ន្ធ
  • ការសម្រេចចិត្តពាក់ព័ន្ធ
  • តម្រូវការពាក់ព័ន្ធ
  • វត្ថុពាក់ព័ន្ធ
  • គោលការណ៍ពាក់ព័ន្ធ
• កំណត់ចំណាំ
  • Microsoft Devops CI ដំណើរផ្សងព្រេងមិនពេញចិត្ត
  • ចំណុចលេចធ្លោនៃការពិភាក្សាលើ Hacker News
  • Windows Development MVP
  • សេចក្តីសង្ខេបរបស់ Edward Thomson ជា Azure PM

សង្ខេប

បញ្ហា

យើងចង់ប្រើ devops ដើម្បី build រួមបញ្ចូល ដាក់ពង្រាយ និងបង្ហោះគម្រោងរបស់យើង។ យើងកំពុងពិចារណា Microsoft Azure DevOps។

• យើងចង់ឱ្យបទពិសោធន៍អ្នកអភិវឌ្ឍន៍លឿន និងអាចទុកចិត្តបាន ទាំងសម្រាប់ការដំឡើង devops ឧ. ការកំណត់រចនាសម្ព័ន្ធ ព្រមទាំងការប្រើប្រាស់ជាបន្តបន្ទាប់ ឧ. ពេលវេលា build លឿន។

• យើងចង់ពិចារណាប្រើ Microsoft Azure ទាំងមូល សម្រាប់បង្ហោះកម្មវិធីគម្រោង មូលដ្ឋានទិន្នន័យ ។ល។

ការសម្រេចចិត្ត

បានសម្រេចមិនជ្រើស Microsoft Azure DevOps។

ស្ថានភាព

បានសម្រេច។ បើកចំហក្នុងការពិនិត្យឡើងវិញ ប្រសិនបើ/នៅពេលដែលព័ត៌មានសំខាន់ថ្មីមកដល់។

ព័ត៌មានលម្អិត

ការសន្មត់

ការសន្មត់ devops ធម្មតាទាំងអស់ ដូចជានៅក្នុងសៀវភៅ Accelerate។

• ការ build លឿនជាជំនួយយ៉ាងសំខាន់។ នេះបង្កើនល្បឿនរង្វិលមតិកែលម្អ។

• យើងអាចដូរចូល/ចេញផ្នែកពីអ្នកលក់ជំនួស ពោលគឺយើងអាចចង់នាំយកម៉ាស៊ីនមេ build ល្បឿនខ្ពស់របស់យើងផ្ទាល់ ឬប្រើជម្រើសប្រព័ន្ធត្រួតពិនិត្យកំណែរបស់យើងផ្ទាល់ ឬសម្របសម្រួលជាមួយម៉ាស៊ីនមេរួមបញ្ចូលជាបន្តបន្ទាប់ដែលបង្ហោះដោយខ្លួនឯង។

• ភាពងាយប្រើដែលសម្រួលជាជំនួយយ៉ាងសំខាន់ សម្រាប់បទពិសោធន៍អ្នកអភិវឌ្ឍន៍ ហើយបន្តសម្រាប់ផ្នែកស្រាលៗដូចជាភាពស៊ីសង្វាក់ ភាពច្បាស់លាស់ សុវត្ថិភាព និងភាពងាយនៃខ្សែកោងរៀន។

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

ឧបសគ្គ

មិនស្គាល់។ Azure មានការប្តេជ្ញាចិត្តដែលបានផ្សព្វផ្សាយក្នុងការធ្វើការបានល្អជាមួយឧបករណ៍ខាងក្រៅ។

ជំហរ

យើងបានពិចារណាប្រើ Microsoft Azure Devops ប្រៀបធៀប AWS ដែលជាអ្នកកាន់តំណែង។

យើងបានពិសោធជាមួយ Azure DevOps, Azure Pipelines, Azure Repo និងការបង្កើតម៉ាស៊ីនមេថ្មីរបស់ Azure តាមរយៈ Terraform។

យើងបានពិសោធការទទួលបានជំនួយពីតំណាង Microsoft។

យើងបានប្រមូលព័ត៌មានពីមិត្តភក្តិនៅលើប្លក់ និង Hacker News។

អាគុយម៉ង់

Azure DevOps ផ្សព្វផ្សាយសំណុំផលិតផលដ៏ល្អឥតខ្ចោះ ប៉ុន្តែពួកវាមិនស្របតាមការអះអាង ហើយមិនដំណើរការល្អជាមួយគ្នា ហើយការគាំទ្រគឺអន់។

បទពិសោធន៍ផ្ទាល់របស់យើង៖

• ការដំឡើង Azure គឺជាភាពច្របូកច្របល់នៃ UI ដែលខ្លះត្រួតស៊ីគ្នាជាមួយគណនី Microsoft ហើយខ្លះមិនត្រួតស៊ីទេ។ ឧទាហរណ៍ មានការចូល Azure ការចូល Microsoft.com ការចូល Live.com ។ល។ ហើយទាំងអស់កំពុងដំណើរការក្នុងពេលតែមួយ។

• យើងបានជួបបញ្ហាសុវត្ថិភាពតូចមួយក្នុងអំឡុងពេលដំឡើង ហើយមិនឃើញដំណោះស្រាយទេ។ យើងបានព្យាយាមរាយការណ៍វាតាមវិធីជាច្រើន ទៅកាន់តំណាង Microsoft ជាច្រើន ដោយមិនជោគជ័យ។ យើងបានរាយការណ៍ទៅផ្នែកសុវត្ថិភាព Microsoft ដោយជោគជ័យ ដែលបានឆ្លើយតបថា won't fix។

• ឯកសារជារឿយៗខុស ឬហួសសម័យ។ យ៉ាងហោចណាស់ផ្នែកខ្លះនៃនេះដោយសារម៉ាស៊ីនស្វែងរកមិនល្អរបស់ Microsoft ហើយខ្លះទៀតដោយសារ SEO ក្រោមស្តង់ដារ។

• ការដំឡើង Terraform ត្រូវបានចងក្រងឯកសារយ៉ាងល្អ ហើយដំណើរការ។ ទោះយ៉ាងណា ការគាំទ្រ Terraform ខ្សោយធៀបនឹង AWS ព្រោះ Microsoft កំពុងកសាងទំនាក់ទំនងអាជីវកម្មជាមួយអ្នកលក់ ដើម្បីធ្វើឧទាហរណ៍ការដំឡើង Terraform តាមខ្សែសង្វាក់។

បទពិសោធន៍របស់មិត្តភក្តិ៖

• បន្ទាប់ពីយើងបានធ្វើការវាយតម្លៃដោយខ្វាក់របស់យើងផ្ទាល់ យើងបានស្វែងរកបទពិសោធន៍របស់មិត្តភក្តិ។ អ្វីដែលយើងរកឃើញបានបញ្ជាក់បទពិសោធន៍របស់យើង។

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

• យើងបានរកឃើញការចូលរួមដ៏ឆ្នើមពីមិត្តរួមក្រុម Azure នៅក្នុងតំបន់ពិភាក្សា។ សូមសរសើរ Microsoft ចំពោះរឿងនេះ។ យើងចាប់អារម្មណ៍ជាពិសេសចំពោះ Edward Thomson ដែលជា Azure PM និងអ្នកសរសេរកូដ ដោយសារការចូលរួម ភាពត្រង់ និងការពន្យល់បច្ចេកទេសរបស់គាត់។

ផលវិបាក

ការជ្រើសរើស Microsoft Azure DevOps មើលទៅទំនងជាថ្លៃជាង (~3 ដង) ទាំងពេលវេលា និងថ្លៃដើម ជាងការមិនជ្រើស Azure។

ពាក់ព័ន្ធ

ការសម្រេចចិត្តពាក់ព័ន្ធ

ប្រសិនបើយើងជ្រើស Azure DevOps មានផលិតផលពាក់ព័ន្ធជាច្រើន រួមមាន Azure Repo, Azure Pipeline ។ល។ យើងជឿថាប្រសិនបើយើងជ្រើស Azure Devops នេះអាចធ្វើឱ្យងាយស្រួលជាងក្នុងការប្រើសមត្ថភាព Azure បន្ថែម ឬអាចធ្វើឱ្យពិបាកជាងក្នុងការប្រើសមត្ថភាពរបស់អ្នកលក់ផ្សេងទៀត។

យើងជឿថា Microsoft កំពុងមានវឌ្ឍនភាពធំក្នុងបទពិសោធន៍អ្នកអភិវឌ្ឍន៍ ហើយយើងឃើញ Microsoft ធ្វើការទិញយកឧបករណ៍អ្នកអភិវឌ្ឍន៍ដ៏ធំ (ឧ. GitHub) និងភាពអាស្រ័យ (ឧ. Citus)។

ប្រសិនបើយើងជ្រើស Azure DevOps នោះយើងអាចចង់សង្កត់ធ្ងន់លើការជ្រើសរើសផលិតផលដែលទិញយកដោយ Microsoft ហើយយើងក៏អាចចង់ចូលទៅរកផលិតផលដែលទិញយកទាំងនោះដោយប្រុងប្រយ័ត្ន/ការវាយតម្លៃច្រើនជាង ដោយសារការបដិសេធសរីរាង្គដែលអាចកើតមាន ឧ. ហានិភ័យនៃការចាកចេញរបស់បុគ្គលិក។

តម្រូវការពាក់ព័ន្ធ

យើងចង់ឱ្យពេលវេលា build លឿនណាស់។ យើងទទួលយកការបង់ប្រាក់ថ្លៃជាងធម្មតាខ្ពស់សម្រាប់រឿងនេះ។ នេះដោយសារយើងចង់ធ្វើវដ្តលឿនខ្លាំង។

យើងចង់ឱ្យភាពអាចទុកចិត្តបានខ្ពស់ណាស់។ យើងទទួលយកការបង់ប្រាក់ថ្លៃជាងធម្មតាខ្ពស់សម្រាប់រឿងនេះ។ នេះដោយសារយើងកំពុងសាកល្បងករណីប្រើប្រាស់តម្លៃខ្ពស់ រួមទាំងប្រតិបត្តិការហិរញ្ញវត្ថុ ប្រតិបត្តិការសម្ងាត់ ។ល។

KPI devops កំពូលទាំង 4 របស់យើងរួមមានពេលវេលាមធ្យមដើម្បីស្តារឡើងវិញ ដែលតម្រូវឱ្យមានការ build លឿន និងភាពអាចទុកចិត្តបានខ្ពស់។

វត្ថុពាក់ព័ន្ធ

យើងចង់ឱ្យប្រព័ន្ធ build ចេញវត្ថុដែលសមស្រប សម្រាប់ប្រើក្នុងប្រព័ន្ធផ្សេងទៀត ដូចជា Artifactory។

គោលការណ៍ពាក់ព័ន្ធ

អាចត្រឡប់វិញបានយ៉ាងងាយ។ យើងអាចវាយតម្លៃ Azure DevOps ស្របគ្នាជាមួយ AWS ដែលជាអ្នកកាន់តំណែង។

កំណត់ចំណាំ

Microsoft Devops CI ដំណើរផ្សងព្រេងមិនពេញចិត្ត

https://toxicbakery.github.io/vsts-devops/microsoft-devops-ci/

ប្លក់។

“ក្នុងនាមជាអ្នកអភិវឌ្ឍកម្មវិធី ខ្ញុំដឹងដោយផ្ទាល់ថាវាពិបាកប៉ុណ្ណាក្នុងការកសាងផលិតផលគុណភាពឱ្យលឿន និងថោក។ វាជាសិល្បៈមួយដែលជួនកាលយើងធ្វើបានត្រឹមត្រូវ ហើយពេលផ្សេងទៀតវាធ្លាក់ចុះទៅជាអ្វីមួយស្រដៀងនឹងគេហទំព័ររដ្ឋាភិបាលថែទាំសុខភាពសម័យ Obama។ កម្រិតនៃការគ្រប់គ្រងរបស់យើងលើផលិតផលដែលបានចេញមកប្រែប្រួល ហើយការស្តីបន្ទោសចំពោះការបរាជ័យជារឿយៗធ្លាក់លើអ្នកខុសក្នុងឋានានុក្រមនៃការសម្រេចចិត្ត។ Azure DevOps របស់ Microsoft (ពីមុនស្គាល់ថា Visual Studio Team Services) ទោះបីមានចេតនាល្អយ៉ាងច្បាស់ក៏ដោយ គឺជាព្យុះដ៏ល្អឥតខ្ចោះនៃការសម្រេចចិត្តអាក្រក់ និងការអនុវត្តមិនល្អ។”

ចំណុចលេចធ្លោនៃការពិភាក្សាលើ Hacker News

https://news.ycombinator.com/item?id=18983586

“យើងប្រើ Azure DevOps យ៉ាងទូលំទូលាយនៅកន្លែងធ្វើការរបស់ខ្ញុំ ហើយបន្ទាប់ពីបានប្រើ GitHub, Gitlab, ដំណោះស្រាយបង្ហោះដោយខ្លួនឯង, Jenkins, TeamCity... Azure DevOps ឈរចំណាត់ថ្នាក់ចុងក្រោយបំផុត។”

“UI គឺច្របូកច្របល់ខ្លាំងគ្រប់ទីកន្លែង។ អាក្រក់បំផុតសម្រាប់ខ្ញុំគឺ pull request។ ពិបាកខ្លាំងណាស់ក្នុងការធ្វើការជាមួយមនុស្សលើ pull request។ ខ្ញុំសូម្បីតែមិនអាចចង្អុលបង្ហាញបញ្ហា “មួយ” ជាក់លាក់ទេ ព្រោះសម្រាប់យើងវាខូចគ្រប់ទីកន្លែង។”

“Azure Devops គឺជាអ្វីមួយដែលខ្ញុំចង់ស្រលាញ់។ UI បន្តផ្លាស់ប្តូរ ប៉ុន្តែមិនដោះស្រាយកំហុសមូលដ្ឋានដែលមានអស់រយៈពេលជាយូរទេ។”

“ឧបករណ៍មិនរួមបញ្ចូលគ្នាល្អទេ UI យឺតណាស់ មិនមានទិដ្ឋភាពផ្ទាំងគ្រប់គ្រងនៃ pull request ដែលសកម្ម build ការចេញផ្សាយ ។ល។ សម្រាប់ repo ដែលខ្ញុំចូលចិត្តទេ។ ពេលវេលា Build/ដាក់ពង្រាយយឺតគួរឱ្យអស្ចារ្យ។”

“យើងបានព្យាយាមប្រើ Azure Boards ផងដែរ (Work Items, Boards, Backlogs ។ល។)។ អូ៎។ វាជាភាពច្របូកច្របល់ទាំងស្រុងនៃ UI នៃគំនិតដែលមិនជាប់ទាក់ទងគ្នា។ ជំនួសឱ្យការអនុវត្តរឿងមួយឱ្យបានល្អ ពួកគេបានអនុវត្តរឿងម្ភៃបួនយ៉ាងយ៉ាងអាក្រក់។”

Windows Development MVP

ខ្ញុំជា Windows Development MVP។ ខ្ញុំមានអារម្មណ៍ថាខ្ញុំត្រូវទទួលខុសត្រូវខ្លះចំពោះការមិនបានបន្លឺសម្លេងឱ្យខ្លាំងអំពីបញ្ហាទាំងនេះ។ ប៉ុន្តែត្រូវនិយាយថា ខ្ញុំខកចិត្តដែលបានឮថាអ្នក “ភ្ញាក់ផ្អើល” អំពីបញ្ហា UX។ ខ្ញុំបានប្រាប់ក្រុមរបស់អ្នកថា UX គឺអាក្រក់ខ្លាំង (ឧ. តាំងពីមុនពេលចាប់ផ្តើម) ហើយបានឮតបវិញជានិច្ចថា “យើងដឹង យើងកំពុងកែវា”។ ខ្ញុំនឹងចាប់ផ្តើមធ្វើឱ្យមតិកែលម្អមានរូបភាពផ្លូវការ ហើយរុញវាតាមបំពង់ សូមតាមដាន។ ខ្ញុំក៏នៅក្នុងតំបន់ (Bellevue) ដែរ ចង់ចូលមកព្យាយាមដាក់កម្មវិធី oss .net/wpf/uwp ដ៏សាមញ្ញរបស់យើងចូលបំពង់។ ខ្ញុំសង្ស័យថាវានឹងបើកភ្នែកទាំងពីរនាក់យើង។

ឧទាហរណ៍មួយចំនួន៖

• អ្នកមិនអាចសាងសង់បំពង់ជាមួយ git repo ដែលមាន submodule បានទេ

• ខ្ញុំរកឃើញថាវាមិនអាចកែ PATH សម្រាប់ឧបករណ៍ផ្ទាល់ខ្លួនមួយចំនួនបានទេ

• បទពិសោធន៍បំពង់ថ្មី (New Pipeline) មិនសមហេតុផលទាល់តែសោះ អ្នកប្រើថ្មីដែលចុចជុំវិញនឹងបញ្ចប់នៅឯឯកសារខុសនៅទីបំផុត។

សេចក្តីសង្ខេបរបស់ Edward Thomson ជា Azure PM

ខ្ញុំបានសរសេរកូដដែលបញ្ចូល pull request របស់អ្នក។ អ្នកគ្រប់គ្រងកម្មវិធី (Program Manager) នៅ Microsoft សម្រាប់ Azure DevOps។ ពីមុនជាវិស្វករកម្មវិធីលើឧបករណ៍ត្រួតពិនិត្យកំណែនៅ GitHub, Microsoft, SourceGear។

https://www.edwardthomson.com/

អ្នកថែទាំរួមនៃ libgit2។ https://libgit2.github.io

អ្នកសហសម្របសម្រួលនៃ All Things Git ផតខាស្តអំពី Git។ https://www.allthingsgit.com/

អ្នកតម្រៀបនៃ Developer Tools Weekly ព្រឹត្តិប័ត្រព័ត៌មានអំពីឧបករណ៍អភិវឌ្ឍន៍។ https://developertoolsweekly.com/