Microsoft Azure DevOps

ສາລະບານ:

• ບົດສະຫຼຸບ
  • ບັນຫາ
  • ການຕັດສິນໃຈ
  • ສະຖານະ
• ລາຍລະອຽດ
  • ສົມມຸດຕິຖານ
  • ຂໍ້ຈຳກັດ
  • ຈຸດຢືນ
  • ຂໍ້ໂຕ້ແຍ້ງ
  • ຜົນໄດ້ຮັບ
• ທີ່ກ່ຽວຂ້ອງ
  • ການຕັດສິນໃຈທີ່ກ່ຽວຂ້ອງ
  • ຄວາມຕ້ອງການທີ່ກ່ຽວຂ້ອງ
  • ຜະລິດຕະພັນທີ່ກ່ຽວຂ້ອງ
  • ຫຼັກການທີ່ກ່ຽວຂ້ອງ
• ໝາຍເຫດ
  • Microsoft Devops CI: ການຜະຈົນໄພທີ່ບໍ່ພໍໃຈ
  • ຈຸດເດັ່ນຂອງການສົນທະນາໃນ Hacker News
  • MVP ດ້ານການພັດທະນາ Windows
  • ບົດສະຫຼຸບຂອງ Edward Thomson (PM ຂອງ Azure)

ບົດສະຫຼຸບ

ບັນຫາ

ພວກເຮົາຢາກໃຊ້ 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 ແລະ ພວກເຮົາຄາດວ່າຈະ build ຫຼາຍຄັ້ງຕໍ່ມື້.

• ພວກເຮົາພົບການມີສ່ວນຮ່ວມທີ່ດີເລີດຈາກເພື່ອນຮ່ວມທີມ Azure ໃນພື້ນທີ່ສົນທະນາ. ຂໍຊົມເຊີຍ Microsoft ສຳລັບເລື່ອງນີ້. ພວກເຮົາປະທັບໃຈເປັນພິເສດກັບ Edward Thomson, PM ແລະ ຜູ້ຂຽນໂຄ້ດຂອງ Azure ເພາະການມີສ່ວນຮ່ວມ, ຄວາມກົງໄປກົງມາ ແລະ ຄຳອະທິບາຍດ້ານເຕັກນິກຂອງລາວ.

ຜົນໄດ້ຮັບ

ການເລືອກ Microsoft Azure DevOps ເບິ່ງຄືວ່າມີແນວໂນ້ມທີ່ຈະແພງກວ່າ (~3 ເທົ່າ) ທັງດ້ານເວລາ ແລະ ຕົ້ນທຶນ ກວ່າການບໍ່ເລືອກ Azure.

ທີ່ກ່ຽວຂ້ອງ

ການຕັດສິນໃຈທີ່ກ່ຽວຂ້ອງ

ຖ້າພວກເຮົາເລືອກ Azure DevOps ມີຜະລິດຕະພັນທີ່ກ່ຽວຂ້ອງຫຼາຍຢ່າງ ລວມທັງ Azure Repo, Azure Pipeline ແລະ ອື່ນໆ. ພວກເຮົາເຊື່ອວ່າຖ້າພວກເຮົາເລືອກ Azure Devops ສິ່ງນີ້ອາດເຮັດໃຫ້ໃຊ້ຄວາມສາມາດຂອງ Azure ຫຼາຍຂຶ້ນໄດ້ງ່າຍຂຶ້ນ ຫຼື ອາດເຮັດໃຫ້ໃຊ້ຄວາມສາມາດຂອງຜູ້ຂາຍອື່ນຍາກຂຶ້ນ.

ພວກເຮົາເຊື່ອວ່າ Microsoft ກຳລັງກ້າວໄປຢ່າງໃຫຍ່ຫຼວງໃນດ້ານປະສົບການຂອງນັກພັດທະນາ ແລະ ພວກເຮົາເຫັນ Microsoft ຊື້ກິດຈະການເຄື່ອງມືນັກພັດທະນາຂະໜາດໃຫຍ່ (ເຊັ່ນ GitHub) ແລະ ສິ່ງທີ່ຂຶ້ນກັບກັນ (ເຊັ່ນ Citus).

ຖ້າພວກເຮົາເລືອກ Azure DevOps ພວກເຮົາອາດຕ້ອງການເນັ້ນການເລືອກຜະລິດຕະພັນທີ່ Microsoft ຊື້ມາ ແລະ ພວກເຮົາອາດຕ້ອງການເຂົ້າຫາຜະລິດຕະພັນທີ່ຊື້ມາດ້ວຍການປະເມີນ/ຄວາມລະມັດລະວັງຫຼາຍຂຶ້ນ ເພາະອາດເກີດການປະຕິເສດເນື້ອເຍື່ອ ເຊັ່ນ ຄວາມສ່ຽງທີ່ພະນັກງານລາອອກ.

ຄວາມຕ້ອງການທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຕ້ອງການເວລາ build ທີ່ໄວຫຼາຍ. ພວກເຮົາຍອມຈ່າຍຄ່າພຣີມຽມສູງສຳລັບເລື່ອງນີ້. ນີ້ເປັນເພາະພວກເຮົາຢາກວົນຊ້ຳໃຫ້ໄວຫຼາຍ.

ພວກເຮົາຕ້ອງການຄວາມເຊື່ອຖືໄດ້ທີ່ສູງຫຼາຍ. ພວກເຮົາຍອມຈ່າຍຄ່າພຣີມຽມສູງສຳລັບເລື່ອງນີ້. ນີ້ເປັນເພາະພວກເຮົາກຳລັງທົດສອບກໍລະນີການນຳໃຊ້ທີ່ມີມູນຄ່າສູງ ລວມທັງທຸລະກຳທາງການເງິນ, ທຸລະກຳລັບ ແລະ ອື່ນໆ.

KPI devops ສີ່ອັນດັບຕົ້ນຂອງພວກເຮົາລວມເວລາສະເລ່ຍໃນການກູ້ຄືນ ເຊິ່ງຈຳເປັນຕ້ອງມີ 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, release ແລະ ອື່ນໆທີ່ກຳລັງດຳເນີນສຳລັບ repo ທີ່ຂ້ອຍມັກ. ເວລາ Build/Deploy ຊ້າຈົນບ້າ."

"ພວກເຮົາພະຍາຍາມໃຊ້ Azure Boards ດ້ວຍ (Work Items, Boards, Backlogs ແລະ ອື່ນໆ). ໂອ້ຍ. ມັນເປັນ UI ທີ່ວຸ່ນວາຍຂອງແນວຄິດທີ່ຂາດຕອນ. ແທນທີ່ຈະເຮັດສິ່ງດຽວໃຫ້ດີ ພວກເຂົາເຮັດຊາວສີ່ຢ່າງໃຫ້ຢ່າງຮ້າຍແຮງ."

MVP ດ້ານການພັດທະນາ Windows

ຂ້ອຍເປັນ MVP ດ້ານການພັດທະນາ Windows. ຂ້ອຍຮູ້ສຶກວ່າຂ້ອຍຕ້ອງຮັບຜິດຊອບບາງສ່ວນໃນເລື່ອງນີ້ທີ່ບໍ່ໄດ້ເວົ້າດັງກ່ຽວກັບບັນຫາເຫຼົ່ານີ້. ແຕ່ຕ້ອງເວົ້າວ່າ ຂ້ອຍຜິດຫວັງທີ່ໄດ້ຍິນວ່າພວກເຈົ້າ "ແປກໃຈ" ກັບບັນຫາ UX. ຂ້ອຍບອກທີມຂອງພວກເຈົ້າມາຕະຫຼອດວ່າ UX ແຍ່ຫຼາຍ (ເຊັ່ນ ຕັ້ງແຕ່ກ່ອນເປີດຕົວ) ແລະ ໄດ້ຍິນຕອບກັບມາສະເໝີວ່າ "ພວກເຮົາຮູ້, ກຳລັງແກ້ໄຂຢູ່". ຂ້ອຍຈະເລີ່ມເຮັດຄຳຕິຊົມໃຫ້ເປັນທາງການ ແລະ ສົ່ງຜ່ານທໍ່, ຕິດຕາມຕໍ່. ຂ້ອຍຢູ່ໃນທ້ອງຖິ່ນ (Bellevue) ດ້ວຍ ຢາກເຂົ້າໄປລອງສ້າງທໍ່ໃຫ້ແອັບ .net/wpf/uwp ຊອດເປີດທີ່ຄ່ອນຂ້າງງ່າຍຂອງພວກເຮົາ. ຂ້ອຍສົງໄສວ່າມັນຈະເປີດຕາທັງສອງຝ່າຍ.

ຕົວຢ່າງບາງຢ່າງ:

• ທ່ານບໍ່ສາມາດສ້າງທໍ່ກັບ git repo ທີ່ມີ submodule

• ພົບວ່າເປັນໄປບໍ່ໄດ້ທີ່ຈະແກ້ໄຂ PATH ສຳລັບເຄື່ອງມືກຳນົດເອງບາງຢ່າງ

• ປະສົບການ New Pipeline ບໍ່ສົມເຫດສົມຜົນເລີຍ ຜູ້ໃຊ້ໃໝ່ທີ່ຄລິກໄປມາຈະຈົບລົງທີ່ເອກະສານທີ່ຜິດໃນທີ່ສຸດ.

ບົດສະຫຼຸບຂອງ Edward Thomson (PM ຂອງ Azure)

ຂ້ອຍຂຽນໂຄ້ດທີ່ລວມ pull request ຂອງທ່ານ. ຜູ້ຈັດການໂຄງການຢູ່ 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/