.NET Core ໃນ Linux, DevOps ເທິງຫຼັງມ້າ

ພວກເຮົາພັດທະນາ DevOps ເທົ່າທີ່ພວກເຮົາສາມາດເຮັດໄດ້. ມີ 8 ຄົນຂອງພວກເຮົາ, ແລະ Vasya ແມ່ນ coolest ໃນ Windows. ທັນໃດນັ້ນ Vasya ອອກໄປ, ແລະຂ້ອຍມີຫນ້າທີ່ເປີດຕົວໂຄງການໃຫມ່ທີ່ສະຫນອງໂດຍການພັດທະນາ Windows. ໃນ​ເວ​ລາ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ dumped ທັງ​ຫມົດ stack ການ​ພັດ​ທະ​ນາ Windows ໃນ​ຕາ​ຕະ​ລາງ, ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ຮັບ​ຮູ້​ວ່າ​ສະ​ຖາ​ນະ​ການ​ແມ່ນ​ເຈັບ​ປວດ ...

ນີ້ແມ່ນວິທີທີ່ເລື່ອງເລີ່ມຕົ້ນ Alexandra Sinchinova ສຸດ DevOpsConf. ເມື່ອຜູ້ຊ່ຽວຊານດ້ານ Windows ຊັ້ນນໍາອອກຈາກບໍລິສັດ, Alexander ສົງໄສວ່າຈະເຮັດແນວໃດໃນປັດຈຸບັນ. ປ່ຽນເປັນ Linux, ແນ່ນອນ! Alexander ຈະບອກທ່ານວ່າລາວຈັດການແນວໃດເພື່ອສ້າງແບບຢ່າງແລະການໂອນສ່ວນຫນຶ່ງຂອງການພັດທະນາ Windows ກັບ Linux ໂດຍໃຊ້ຕົວຢ່າງຂອງໂຄງການທີ່ສໍາເລັດສໍາລັບຜູ້ໃຊ້ສຸດທ້າຍ 100.

ວິທີການຈັດສົ່ງໂຄງການໄປຫາ RPM ໄດ້ຢ່າງງ່າຍດາຍແລະງ່າຍດາຍໂດຍໃຊ້ TFS, Puppet, Linux .NET core? ວິທີການສະຫນັບສະຫນູນການສະບັບຂອງຖານຂໍ້ມູນໂຄງການຖ້າຫາກວ່າທີມງານພັດທະນາໄດ້ຍິນຄໍາວ່າ Postgres ແລະ Flyway ເປັນຄັ້ງທໍາອິດ, ແລະເສັ້ນຕາຍແມ່ນມື້ອື່ນ? ວິທີການປະສົມປະສານກັບ Docker? ວິທີການກະຕຸ້ນນັກພັດທະນາ .NET ໃຫ້ປະຖິ້ມ Windows ແລະ smoothies ໃນເງື່ອນໄຂຂອງ Puppet ແລະ Linux? ວິທີການແກ້ໄຂຄວາມຂັດແຍ້ງທາງອຸດົມການຖ້າບໍ່ມີຄວາມເຂັ້ມແຂງ, ຫຼືຄວາມປາຖະຫນາ, ຫຼືຊັບພະຍາກອນທີ່ຈະຮັກສາ Windows ໃນການຜະລິດ? ກ່ຽວກັບເລື່ອງນີ້, ເຊັ່ນດຽວກັນກັບ Web Deploy, ການທົດສອບ, CI, ກ່ຽວກັບການປະຕິບັດຂອງການນໍາໃຊ້ TFS ໃນໂຄງການທີ່ມີຢູ່ແລ້ວ, ແລະ, ແນ່ນອນ, ກ່ຽວກັບ crutches ທີ່ແຕກຫັກແລະການແກ້ໄຂການເຮັດວຽກ, ໃນຂໍ້ຄວາມຂອງບົດລາຍງານຂອງ Alexander.

ດັ່ງນັ້ນ, Vasya ຊ້າຍ, ວຽກງານແມ່ນຢູ່ໃນຂ້ອຍ, ນັກພັດທະນາກໍາລັງລໍຖ້າຢ່າງບໍ່ອົດທົນກັບ pitchforks. ເມື່ອຂ້ອຍຮູ້ວ່າ Vasya ບໍ່ສາມາດກັບຄືນມາໄດ້, ຂ້ອຍໄດ້ລົງໄປເຮັດທຸລະກິດ. ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ຂ້າພະເຈົ້າໄດ້ປະເມີນອັດຕາສ່ວນຂອງ Win VMs ໃນເຮືອຂອງພວກເຮົາ. ຄະແນນບໍ່ໄດ້ຢູ່ໃນເງື່ອນໄຂຂອງ Windows.

ເນື່ອງຈາກພວກເຮົາກໍາລັງພັດທະນາ DevOps ຢ່າງຈິງຈັງ, ຂ້ອຍຮູ້ວ່າບາງສິ່ງບາງຢ່າງຕ້ອງມີການປ່ຽນແປງໃນວິທີການສົ່ງຄໍາຮ້ອງສະຫມັກໃຫມ່. ມີພຽງແຕ່ຫນຶ່ງການແກ້ໄຂ - ຖ້າເປັນໄປໄດ້, ໂອນທຸກສິ່ງທຸກຢ່າງໄປ Linux. Google ຊ່ວຍຂ້ອຍ - ໃນເວລານັ້ນ .Net ໄດ້ຖືກ ported ກັບ Linux ແລ້ວ, ແລະຂ້ອຍຮູ້ວ່ານີ້ແມ່ນການແກ້ໄຂ!

ເປັນຫຍັງຫຼັກ .NET ສົມທົບກັບ Linux?

ມີເຫດຜົນຫຼາຍຢ່າງສໍາລັບການນີ້. ລະຫວ່າງ "ຈ່າຍເງິນ" ແລະ "ບໍ່ຈ່າຍ", ສ່ວນໃຫຍ່ຈະເລືອກທີສອງ - ຄືຂ້ອຍ. ໃບ​ອະ​ນຸ​ຍາດ​ສໍາ​ລັບ MSDB ມີ​ລາ​ຄາ​ຖືກ​ປະ​ມານ $1; ການ​ຮັກ​ສາ​ເຮືອ​ຂອງ Windows virtual machines ມີ​ຄ່າ​ຫຼາຍ​ຮ້ອຍ​ໂດ​ລາ​. ສໍາລັບບໍລິສັດຂະຫນາດໃຫຍ່ນີ້ແມ່ນຄ່າໃຊ້ຈ່າຍອັນໃຫຍ່ຫຼວງ. ນັ້ນຄືເຫດຜົນ ປະຢັດ - ເຫດຜົນທໍາອິດ. ບໍ່ສໍາຄັນທີ່ສຸດ, ແຕ່ເປັນຫນຶ່ງໃນທີ່ສໍາຄັນ.

ເຄື່ອງ virtual Windows ໃຊ້ຊັບພະຍາກອນຫຼາຍກ່ວາພີ່ນ້ອງ Linux ຂອງພວກເຂົາ - ພວກເຂົາເຈົ້າແມ່ນຫນັກ. ເນື່ອງຈາກຂະຫນາດຂອງບໍລິສັດຂະຫນາດໃຫຍ່, ພວກເຮົາເລືອກ Linux.

ລະບົບໄດ້ຖືກລວມເຂົ້າກັບ CI ທີ່ມີຢູ່ແລ້ວ. ພວກເຮົາພິຈາລະນາຕົວເຮົາເອງກ້າວຫນ້າ DevOps, ພວກເຮົາໃຊ້ໄມ້ໄຜ່, Jenkins ແລະ GitLab CI, ດັ່ງນັ້ນວຽກງານສ່ວນໃຫຍ່ຂອງພວກເຮົາເຮັດວຽກຢູ່ໃນ Linux.

ເຫດຜົນສຸດທ້າຍແມ່ນ ໄປພ້ອມໆກັນທີ່ສະດວກ. ພວກເຮົາຈໍາເປັນຕ້ອງຫຼຸດລົງອຸປະສັກໃນການເຂົ້າສໍາລັບ "escorts" - guys ຜູ້ທີ່ເຂົ້າໃຈພາກສ່ວນດ້ານວິຊາການ, ຮັບປະກັນການບໍລິການທີ່ບໍ່ມີການລົບກວນ, ແລະຮັກສາການບໍລິການຈາກສາຍທີສອງ. ພວກເຂົາຄຸ້ນເຄີຍກັບ Linux stack ແລ້ວ, ສະນັ້ນມັນງ່າຍຫຼາຍສໍາລັບພວກເຂົາທີ່ຈະເຂົ້າໃຈ, ສະຫນັບສະຫນູນແລະຮັກສາຜະລິດຕະພັນໃຫມ່ກ່ວາການໃຊ້ຊັບພະຍາກອນເພີ່ມເຕີມເພື່ອເຂົ້າໃຈຫນ້າທີ່ດຽວກັນຂອງຊອບແວສໍາລັບແພລະຕະຟອມ Windows.

ຄວາມຕ້ອງການ

ທໍາ​ອິດ​ແລະ​ສໍາ​ຄັນ​ທີ່​ສຸດ - ຄວາມສະດວກສະບາຍຂອງການແກ້ໄຂໃຫມ່ສໍາລັບນັກພັດທະນາ. ບໍ່ແມ່ນພວກເຂົາທັງຫມົດແມ່ນກຽມພ້ອມສໍາລັບການປ່ຽນແປງ, ໂດຍສະເພາະຫຼັງຈາກຄໍາເວົ້າ Linux. ນັກພັດທະນາຕ້ອງການ Visual Studio ທີ່ພວກເຂົາມັກ, TFS ທີ່ມີການທົດສອບອັດຕະໂນມັດສໍາລັບການປະກອບແລະ smoothies. ວິທີການຈັດສົ່ງການຜະລິດເກີດຂຶ້ນແມ່ນບໍ່ສໍາຄັນສໍາລັບພວກເຂົາ. ດັ່ງນັ້ນ, ພວກເຮົາຕັດສິນໃຈບໍ່ປ່ຽນແປງຂະບວນການປົກກະຕິແລະປ່ອຍໃຫ້ທຸກສິ່ງທຸກຢ່າງບໍ່ປ່ຽນແປງສໍາລັບການພັດທະນາ Windows.

ຕ້ອງການໂຄງການໃຫມ່ ປະສົມປະສານເຂົ້າໃນ CI ທີ່ມີຢູ່ແລ້ວ. ລາງລົດໄຟມີຢູ່ແລ້ວແລະວຽກງານທັງຫມົດຕ້ອງໄດ້ເຮັດໂດຍຄໍານຶງເຖິງຕົວກໍານົດການຂອງລະບົບການຄຸ້ມຄອງການຕັ້ງຄ່າ, ມາດຕະຖານການຈັດສົ່ງທີ່ຍອມຮັບແລະລະບົບການຕິດຕາມ.

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

ເສັ້ນຕາຍ - ມື້ວານ.

Win Development Group

ທີມງານ Windows ເຮັດວຽກກັບຫຍັງໃນເວລານັ້ນ?

ດຽວນີ້ຂ້ອຍສາມາດເວົ້າໄດ້ຢ່າງໝັ້ນໃຈ IdentityServer4 ເປັນທາງເລືອກທີ່ບໍ່ເສຍຄ່າກັບ ADFS ທີ່ມີຄວາມສາມາດທີ່ຄ້າຍຄືກັນ, ຫຼືແມ່ນຫຍັງ Entity Framework Core - ອຸທິຍານສໍາລັບນັກພັດທະນາ, ບ່ອນທີ່ທ່ານບໍ່ຈໍາເປັນຕ້ອງລົບກວນການຂຽນ SQL, ແຕ່ອະທິບາຍການສອບຖາມໃນຖານຂໍ້ມູນໃນຂໍ້ກໍານົດ OOP. ແຕ່ຫຼັງຈາກນັ້ນ, ໃນລະຫວ່າງການສົນທະນາຂອງແຜນການປະຕິບັດ, ຂ້າພະເຈົ້າໄດ້ເບິ່ງ stack ນີ້ຄືກັບວ່າມັນແມ່ນ Sumerian cuneiform, ຮັບຮູ້ພຽງແຕ່ PostgreSQL ແລະ Git.

ໃນເວລານັ້ນພວກເຮົາໄດ້ໃຊ້ຢ່າງຈິງຈັງ ພ້າ ເປັນລະບົບການຈັດການການຕັ້ງຄ່າ. ໃນໂຄງການສ່ວນໃຫຍ່ຂອງພວກເຮົາພວກເຮົາໄດ້ໃຊ້ GitLab CI, Elastic, ການດຸ່ນດ່ຽງການບໍລິການໂຫຼດສູງໂດຍນໍາໃຊ້ HAProxy ຕິດ​ຕາມ​ກວດ​ກາ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ Zabbix, ligaments ກຣາຟານາ и Prometheus, Jaeger, ແລະທັງຫມົດນີ້ໄດ້ຖືກ spinning ສຸດຕ່ອນຂອງທາດເຫຼັກ HP c ESXi ສຸດ VMware. ບຸກຄົນທຸກຄົນຮູ້ມັນ - ຄລາສສິກຂອງປະເພດ.

ໃຫ້ເບິ່ງແລະພະຍາຍາມເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນກ່ອນທີ່ພວກເຮົາຈະເລີ່ມຕົ້ນການແຊກແຊງທັງຫມົດເຫຼົ່ານີ້.

ເກີດ​ຫຍັງ​ຂຶ້ນ

TFS ເປັນລະບົບທີ່ມີປະສິດທິພາບພໍສົມຄວນທີ່ບໍ່ພຽງແຕ່ສົ່ງລະຫັດຈາກນັກພັດທະນາໄປຫາເຄື່ອງຈັກການຜະລິດສຸດທ້າຍ, ແຕ່ຍັງມີຊຸດສໍາລັບການເຊື່ອມໂຍງທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍກັບການບໍລິການຕ່າງໆ - ເພື່ອສະຫນອງ CI ໃນລະດັບຂ້າມເວທີ.

ກ່ອນຫນ້ານີ້, ເຫຼົ່ານີ້ແມ່ນປ່ອງຢ້ຽມແຂງ. TFS ໄດ້ໃຊ້ຕົວແທນ Build ຫຼາຍ, ເຊິ່ງຖືກນໍາໃຊ້ເພື່ອປະກອບໂຄງການຈໍານວນຫຼາຍ. ແຕ່ລະຕົວແທນມີພະນັກງານ 3-4 ຄົນເພື່ອຂະຫນານວຽກງານ ແລະ ປັບປຸງຂະບວນການ. ຫຼັງຈາກນັ້ນ, ອີງຕາມແຜນການປ່ອຍ, TFS ໄດ້ສົ່ງ Build ທີ່ອົບສົດໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍແອັບພລິເຄຊັນ Windows.

ພວກເຮົາຕ້ອງການບັນລຸຫຍັງ?

ພວກເຮົາໃຊ້ TFS ສໍາລັບການຈັດສົ່ງແລະການພັດທະນາ, ແລະດໍາເນີນການຄໍາຮ້ອງສະຫມັກໃນເຄື່ອງແມ່ຂ່າຍຂອງ Linux Application, ແລະມີບາງປະເພດຂອງ magic ລະຫວ່າງເຂົາເຈົ້າ. ນີ້ ກ່ອງ Magic ແລະມີເກືອຂອງວຽກງານຢູ່ຂ້າງຫນ້າ. ກ່ອນທີ່ຂ້ອຍຈະເອົາມັນອອກຈາກກັນ, ຂ້ອຍຈະເອົາບາດກ້າວຫນຶ່ງແລະເວົ້າສອງສາມຄໍາກ່ຽວກັບຄໍາຮ້ອງສະຫມັກ.

ໂຄງການ

ຄໍາຮ້ອງສະຫມັກສະຫນອງການທໍາງານສໍາລັບການຈັດການບັດເຕີມເງິນ.

ລູກ​ຄ້າ

ມີສອງປະເພດຂອງຜູ້ໃຊ້. ທໍາອິດ ໄດ້ຮັບການເຂົ້າເຖິງໂດຍການເຂົ້າສູ່ລະບົບໂດຍໃຊ້ໃບຢັ້ງຢືນ SSL SHA-2. U ຄັ້ງທີສອງ ມີການເຂົ້າເຖິງໂດຍການເຂົ້າສູ່ລະບົບແລະລະຫັດຜ່ານ.

HAProxy

ຫຼັງຈາກນັ້ນ, ການຮ້ອງຂໍຂອງລູກຄ້າໄດ້ໄປຫາ HAProxy, ເຊິ່ງແກ້ໄຂບັນຫາຕໍ່ໄປນີ້:

• ການອະນຸຍາດຕົ້ນຕໍ;
• ການຢຸດເຊົາ SSL;
• ປັບການຮ້ອງຂໍ HTTP;
• ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ອອກ​ອາ​ກາດ​.

ໃບຢັ້ງຢືນລູກຄ້າໄດ້ຖືກກວດສອບຕາມລະບົບຕ່ອງໂສ້. ພວກເຮົາ - ສິດອໍານາດ ແລະພວກເຮົາສາມາດຈ່າຍໄດ້, ນັບຕັ້ງແຕ່ພວກເຮົາເອງອອກໃບຢັ້ງຢືນໃຫ້ແກ່ລູກຄ້າບໍລິການ.

ເອົາໃຈໃສ່ກັບຈຸດທີສາມ, ພວກເຮົາຈະກັບຄືນໄປຫາມັນເລັກນ້ອຍຕໍ່ມາ.

backend

ພວກເຂົາເຈົ້າວາງແຜນທີ່ຈະເຮັດໃຫ້ backend ໃນ Linux. backend ພົວພັນກັບຖານຂໍ້ມູນ, ໂຫລດລາຍຊື່ສິດທິພິເສດທີ່ຈໍາເປັນແລະຫຼັງຈາກນັ້ນ, ຂຶ້ນກັບສິດທິພິເສດທີ່ຜູ້ໃຊ້ທີ່ໄດ້ຮັບອະນຸຍາດ, ສະຫນອງການເຂົ້າເຖິງການເຊັນເອກະສານທາງດ້ານການເງິນແລະສົ່ງໃຫ້ພວກເຂົາດໍາເນີນການ, ຫຼືສ້າງບົດລາຍງານບາງປະເພດ.

ເງິນຝາກປະຢັດດ້ວຍ HAProxy

ນອກເໜືອໄປຈາກສອງບໍລິບົດທີ່ລູກຄ້າແຕ່ລະຄົນນຳທາງ, ຍັງມີບໍລິບົດຂອງຕົວຕົນ. IdentityServer4 ພຽງແຕ່ອະນຸຍາດໃຫ້ທ່ານເຂົ້າສູ່ລະບົບ, ນີ້ແມ່ນ analogue ຟຣີແລະມີອໍານາດສໍາລັບ ADFS - ການບໍລິການຂອງສະຫະພັນລະບົບສະຫະພັນ.

ການຮ້ອງຂໍຕົວຕົນໄດ້ຖືກດໍາເນີນໃນຫຼາຍຂັ້ນຕອນ. ຂັ້ນ​ຕອນ​ທໍາ​ອິດ - ລູກ​ຄ້າ ໄດ້ເຂົ້າໄປໃນ backend, ເຊິ່ງຕິດຕໍ່ສື່ສານກັບເຄື່ອງແມ່ຂ່າຍນີ້ແລະກວດເບິ່ງການມີ token ສໍາລັບລູກຄ້າ. ຖ້າມັນບໍ່ພົບ, ການຮ້ອງຂໍຖືກສົ່ງຄືນກັບສະພາບການທີ່ມັນມາ, ແຕ່ດ້ວຍການປ່ຽນເສັ້ນທາງ, ແລະດ້ວຍການປ່ຽນເສັ້ນທາງມັນໄປຫາຕົວຕົນ.

ຂັ້ນຕອນທີສອງ - ໄດ້ຮັບການຮ້ອງຂໍ ໄປທີ່ໜ້າການອະນຸຍາດໃນ IdentityServer, ບ່ອນທີ່ລູກຄ້າລົງທະບຽນ, ແລະໂທເຄັນທີ່ລໍຄອຍມາດົນນານນັ້ນປາກົດຢູ່ໃນຖານຂໍ້ມູນ IdentityServer.

ຂັ້ນ​ຕອນ​ທີ​ສາມ - ລູກຄ້າໄດ້ຖືກໂອນກັບຄືນ ກັບສະພາບການທີ່ມັນມາ.

IdentityServer4 ມີ​ຄຸນ​ສົມ​ບັດ​: ມັນສົ່ງຄືນການຕອບສະຫນອງຕໍ່ຄໍາຮ້ອງຂໍຄືນຜ່ານ HTTP. ບໍ່ວ່າພວກເຮົາຕໍ່ສູ້ກັບການຕັ້ງຄ່າເຊີຟເວີຫຼາຍປານໃດ, ບໍ່ວ່າພວກເຮົາມີຄວາມສະຫວ່າງຫຼາຍປານໃດກັບເອກະສານ, ແຕ່ລະຄັ້ງທີ່ພວກເຮົາໄດ້ຮັບການຮ້ອງຂໍລູກຄ້າເບື້ອງຕົ້ນທີ່ມີ URL ທີ່ເຂົ້າມາຜ່ານ HTTPS, ແລະ IdentityServer ກັບຄືນສະພາບການດຽວກັນ, ແຕ່ກັບ HTTP. ພວກເຮົາຕົກໃຈ! ແລະພວກເຮົາໄດ້ໂອນທັງຫມົດນີ້ຜ່ານສະພາບການຕົວຕົນໄປຫາ HAProxy, ແລະໃນສ່ວນຫົວພວກເຮົາຕ້ອງດັດແປງ HTTP protocol ເປັນ HTTPS.

ການປັບປຸງແມ່ນຫຍັງແລະເຈົ້າປະຫຍັດບ່ອນໃດ?

ພວກເຮົາໄດ້ປະຫຍັດເງິນໂດຍການນໍາໃຊ້ການແກ້ໄຂຟຣີສໍາລັບການອະນຸຍາດໃຫ້ກຸ່ມຜູ້ໃຊ້, ຊັບພະຍາກອນ, ເນື່ອງຈາກວ່າພວກເຮົາບໍ່ໄດ້ວາງ IdentityServer4 ເປັນ node ແຍກຕ່າງຫາກຢູ່ໃນພາກສ່ວນແຍກຕ່າງຫາກ, ແຕ່ນໍາໃຊ້ມັນຮ່ວມກັນກັບ backend ໃນເຄື່ອງແມ່ຂ່າຍດຽວກັນທີ່ backend ຂອງຄໍາຮ້ອງສະຫມັກດໍາເນີນການ. .

ມັນຄວນຈະເຮັດວຽກແນວໃດ

ດັ່ງນັ້ນ, ດັ່ງທີ່ຂ້າພະເຈົ້າສັນຍາ - Magic Box. ພວກເຮົາເຂົ້າໃຈແລ້ວວ່າພວກເຮົາໄດ້ຮັບການຮັບປະກັນທີ່ຈະກ້າວໄປສູ່ Linux. ຂໍໃຫ້ສ້າງວຽກງານສະເພາະທີ່ຕ້ອງການວິທີແກ້ໄຂ.

Puppet manifests. ເພື່ອຈັດສົ່ງແລະຈັດການການບໍລິການແລະການຕັ້ງຄ່າຄໍາຮ້ອງສະຫມັກ, ສູດອາຫານເຢັນຕ້ອງໄດ້ຮັບການຂຽນ. ມ້ວນຂອງດິນສໍ eloquently ສະແດງໃຫ້ເຫັນວິທີການຢ່າງວ່ອງໄວແລະປະສິດທິພາບມັນເຮັດໄດ້.

ວິທີການຈັດສົ່ງ. ມາດຕະຖານແມ່ນ RPM. ທຸກຄົນເຂົ້າໃຈວ່າໃນ Linux ເຈົ້າບໍ່ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີມັນ, ແຕ່ໂຄງການຕົວມັນເອງ, ຫຼັງຈາກການປະກອບ, ແມ່ນຊຸດຂອງໄຟລ໌ DLL ທີ່ສາມາດປະຕິບັດໄດ້. ມີປະມານ 150 ຄົນ, ໂຄງການແມ່ນຂ້ອນຂ້າງຫຍຸ້ງຍາກ. ການແກ້ໄຂປະສົມກົມກຽວພຽງແຕ່ແມ່ນການຫຸ້ມຫໍ່ສອງນີ້ເຂົ້າໄປໃນ RPM ແລະນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຈາກມັນ.

ຮຸ່ນ. ພວກເຮົາຕ້ອງປ່ອຍຕົວເລື້ອຍໆ, ແລະພວກເຮົາຕ້ອງຕັດສິນໃຈວ່າຈະສ້າງຊື່ຊຸດແນວໃດ. ນີ້ແມ່ນຄໍາຖາມຂອງລະດັບການເຊື່ອມໂຍງກັບ TFS. ພວກເຮົາມີຕົວແທນສ້າງຢູ່ໃນ Linux. ເມື່ອ TFS ສົ່ງວຽກໄປຫາຕົວຈັດການ - ພະນັກງານ - ໄປຫາຕົວແທນ Build, ມັນຍັງສົ່ງຜ່ານມັນຫຼາຍໆຕົວແປທີ່ສິ້ນສຸດໃນສະພາບແວດລ້ອມຂອງຂະບວນການຕົວຈັດການ. ຕົວແປສະພາບແວດລ້ອມເຫຼົ່ານີ້ມີຊື່ສ້າງ, ຊື່ເວີຊັນ, ແລະຕົວແປອື່ນໆ. ອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນສ່ວນ "ການສ້າງຊຸດ RPM".

ການ​ຕັ້ງ​ຄ່າ TFS​ ລົງມາເພື່ອຕັ້ງທໍ່. ກ່ອນຫນ້ານີ້, ພວກເຮົາໄດ້ລວບລວມໂຄງການ Windows ທັງຫມົດໃນຕົວແທນຂອງ Windows, ແຕ່ໃນປັດຈຸບັນຕົວແທນ Linux ປະກົດຂຶ້ນ - ຕົວແທນ Build, ເຊິ່ງຈໍາເປັນຕ້ອງຖືກລວມເຂົ້າໃນກຸ່ມກໍ່ສ້າງ, ອຸດົມສົມບູນດ້ວຍສິ່ງປະດິດບາງຢ່າງ, ແລະບອກວ່າໂຄງການປະເພດໃດທີ່ຈະສ້າງຂຶ້ນໃນຕົວແທນ Build ນີ້. , ແລະ somehow ດັດແປງທໍ່.

IdentityServer. ADFS ບໍ່ແມ່ນທາງຂອງພວກເຮົາ, ພວກເຮົາກໍາລັງໄປຫາ Open Source.

ໃຫ້ໄປໂດຍຜ່ານອົງປະກອບ.

ກ່ອງ Magic

ປະກອບດ້ວຍສີ່ພາກສ່ວນ.

ຕົວແທນສ້າງ Linux. Linux, ເພາະວ່າພວກເຮົາສ້າງສໍາລັບມັນ - ມັນເປັນເຫດຜົນ. ສ່ວນນີ້ໄດ້ຖືກເຮັດໃນສາມຂັ້ນຕອນ.

• ກຳນົດຄ່າພະນັກງານ ແລະບໍ່ແມ່ນຄົນດຽວ, ນັບຕັ້ງແຕ່ການແຈກຢາຍວຽກງານໃນໂຄງການໄດ້ຖືກຄາດຫວັງ.
• ຕິດຕັ້ງ .NET Core 1.x. ເປັນຫຍັງ 1.x ເມື່ອ 2.0 ມີຢູ່ໃນບ່ອນເກັບມ້ຽນມາດຕະຖານແລ້ວ? ເນື່ອງຈາກວ່າໃນເວລາທີ່ພວກເຮົາເລີ່ມຕົ້ນການພັດທະນາ, ສະບັບທີ່ຫມັ້ນຄົງແມ່ນ 1.09, ແລະມັນໄດ້ຖືກຕັດສິນໃຈເຮັດໂຄງການໂດຍອີງໃສ່ມັນ.
• Git 2.x.

RPM-repository. ແພັກເກັດ RPM ຈໍາເປັນຕ້ອງຖືກເກັບໄວ້ບ່ອນໃດບ່ອນຫນຶ່ງ. ມັນສົມມຸດວ່າພວກເຮົາຈະໃຊ້ບ່ອນເກັບມ້ຽນ RPM ຂອງບໍລິສັດດຽວກັນທີ່ມີໃຫ້ກັບທຸກໂຮດ Linux. ນັ້ນແມ່ນສິ່ງທີ່ພວກເຂົາໄດ້ເຮັດ. ເຄື່ອງແມ່ຂ່າຍຂອງ repository ໄດ້ຖືກຕັ້ງຄ່າ hook ເວັບ ເຊິ່ງໄດ້ດາວໂຫຼດຊຸດ RPM ທີ່ຕ້ອງການຈາກສະຖານທີ່ທີ່ລະບຸໄວ້. ສະບັບຊຸດໄດ້ຖືກລາຍງານໃຫ້ webhook ໂດຍຕົວແທນ Build.

GitLab. ເອົາໃຈໃສ່! GitLab ຢູ່ທີ່ນີ້ບໍ່ໄດ້ຖືກນໍາໃຊ້ໂດຍຜູ້ພັດທະນາ, ແຕ່ໂດຍພະແນກປະຕິບັດງານເພື່ອຄວບຄຸມເວີຊັນຂອງແອັບພລິເຄຊັນ, ຮຸ່ນຊຸດ, ຕິດຕາມສະຖານະຂອງເຄື່ອງ Linux ທັງຫມົດ, ແລະມັນເກັບຮັກສາສູດ - ທັງຫມົດ Puppet manifests.

ພ້າ — ແກ້​ໄຂ​ບັນ​ຫາ​ການ​ໂຕ້​ຖຽງ​ກັນ​ທັງ​ຫມົດ​ແລະ​ສະ​ຫນອງ​ການ​ຕັ້ງ​ຄ່າ​ທີ່​ແນ່​ນອນ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ການ​ຈາກ Gitlab​.

ພວກເຮົາເລີ່ມຕົ້ນທີ່ຈະດໍານ້ໍາ. ການຈັດສົ່ງ DLL ກັບ RPM ເຮັດວຽກແນວໃດ?

ການຈັດສົ່ງ DDL ເຖິງ RPM

ໃຫ້ເວົ້າວ່າພວກເຮົາມີ Rock star ພັດທະນາ .NET. ມັນໃຊ້ Visual Studio ແລະສ້າງສາຂາການປ່ອຍ. ຫຼັງຈາກນັ້ນ, ມັນອັບໂຫລດມັນໄປທີ່ Git, ແລະ Git ນີ້ແມ່ນ TFS entity, ນັ້ນແມ່ນ, ມັນແມ່ນບ່ອນເກັບມ້ຽນຂອງແອັບພລິເຄຊັນທີ່ນັກພັດທະນາເຮັດວຽກ.

ຫຼັງຈາກນັ້ນ TFS ເຫັນວ່າຄໍາຫມັ້ນສັນຍາໃຫມ່ໄດ້ມາຮອດ. ແອັບໃດ? ໃນການຕັ້ງຄ່າ TFS ມີປ້າຍທີ່ຊີ້ບອກເຖິງຊັບພະຍາກອນທີ່ຕົວແທນ Build ໂດຍສະເພາະມີ. ໃນກໍລະນີນີ້, ລາວເຫັນວ່າພວກເຮົາກໍາລັງສ້າງໂຄງການ .NET Core ແລະເລືອກຕົວແທນ Linux Build ຈາກສະນຸກເກີ.

ຕົວແທນ Build ໄດ້ຮັບແຫຼ່ງຂໍ້ມູນແລະດາວໂຫລດທີ່ຈໍາເປັນ dependencies ຈາກ .NET repository, npm, ແລະອື່ນໆ. ແລະຫຼັງຈາກການກໍ່ສ້າງຄໍາຮ້ອງສະຫມັກຂອງມັນເອງແລະການຫຸ້ມຫໍ່ຕໍ່ມາ, ສົ່ງຊຸດ RPM ໄປຫາບ່ອນເກັບມ້ຽນ RPM.

ໃນອີກດ້ານຫນຶ່ງ, ດັ່ງຕໍ່ໄປນີ້ເກີດຂຶ້ນ. ວິສະວະກອນພະແນກປະຕິບັດງານແມ່ນມີສ່ວນຮ່ວມໂດຍກົງໃນການເປີດຕົວຂອງໂຄງການ: ລາວປ່ຽນສະບັບຂອງຊຸດໃນ ເຮຣາ ໃນ repository ທີ່ສູດຄໍາຮ້ອງສະຫມັກໄດ້ຖືກເກັບຮັກສາໄວ້, ຫຼັງຈາກນັ້ນ Puppet ຜົນກະທົບຕໍ່ Yum, ດຶງເອົາແພັກເກັດໃໝ່ຈາກບ່ອນເກັບມ້ຽນ, ແລະແອັບພລິເຄຊັນເວີຊັນໃໝ່ພ້ອມໃຊ້ແລ້ວ.

ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍໃນຄໍາສັບຕ່າງໆ, ແຕ່ສິ່ງທີ່ເກີດຂຶ້ນພາຍໃນຕົວແທນ Build ຕົວຂອງມັນເອງ?

ການຫຸ້ມຫໍ່ DLL RPM

ໄດ້ຮັບແຫຼ່ງໂຄງການແລະການກໍ່ສ້າງວຽກງານຈາກ TFS. ຕົວແທນກໍ່ສ້າງ ເລີ່ມສ້າງໂຄງການເອງຈາກແຫຼ່ງຕ່າງໆ. ໂຄງການປະກອບແມ່ນມີຢູ່ໃນຊຸດ ໄຟລ໌ DLL, ເຊິ່ງຖືກຫຸ້ມຫໍ່ຢູ່ໃນແຟ້ມ zip ເພື່ອຫຼຸດຜ່ອນການໂຫຼດໃນລະບົບໄຟລ໌.

ແຟ້ມ ZIP ຖືກຖິ້ມອອກໄປ ໄປຫາ RPM package build directory. ຕໍ່ໄປ, script Bash ເລີ່ມຕົ້ນຕົວແປສະພາບແວດລ້ອມ, ຊອກຫາເວີຊັນ Build, ຮຸ່ນຂອງໂຄງການ, ເສັ້ນທາງໄປຫາ build directory, ແລະດໍາເນີນການ RPM-build. ເມື່ອການກໍ່ສ້າງສໍາເລັດ, ຊຸດໄດ້ຖືກຈັດພີມມາເຖິງ repository ທ້ອງຖິ່ນ, ເຊິ່ງຕັ້ງຢູ່ໃນຕົວແທນ Build.

ຕໍ່ໄປ, ຈາກຕົວແທນ Build ກັບເຄື່ອງແມ່ຂ່າຍໃນ repository RPM ການຮ້ອງຂໍ JSON ຖືກສົ່ງ ຊີ້ບອກຊື່ຂອງສະບັບແລະການກໍ່ສ້າງ. Webhook, ທີ່ຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບກ່ອນຫນ້ານີ້, ດາວໂຫລດຊຸດນີ້ຈາກ repository ທ້ອງຖິ່ນໃນຕົວແທນ Build ແລະເຮັດໃຫ້ການປະກອບໃຫມ່ສໍາລັບການຕິດຕັ້ງ.

ເປັນຫຍັງລະບົບການຈັດສົ່ງຊຸດສະເພາະນີ້ໄປຫາບ່ອນເກັບມ້ຽນ RPM? ເປັນຫຍັງຂ້ອຍຈຶ່ງບໍ່ສາມາດສົ່ງຊຸດທີ່ປະກອບໄປໃສ່ບ່ອນເກັບມ້ຽນໄດ້ທັນທີ? ຄວາມຈິງແມ່ນວ່ານີ້ແມ່ນເງື່ອນໄຂສໍາລັບການຮັບປະກັນຄວາມປອດໄພ. ສະຖານະການນີ້ຈໍາກັດຄວາມເປັນໄປໄດ້ຂອງຄົນທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດອັບໂຫລດແພັກເກັດ RPM ໄປຫາເຄື່ອງແມ່ຂ່າຍທີ່ສາມາດເຂົ້າເຖິງໄດ້ກັບທຸກເຄື່ອງ Linux.

ຮຸ່ນຖານຂໍ້ມູນ

ໃນການປຶກສາຫາລືກັບທີມງານພັດທະນາ, ມັນໄດ້ຫັນອອກວ່າ guys ໄດ້ໃກ້ຊິດກັບ MS SQL, ແຕ່ໃນໂຄງການທີ່ບໍ່ແມ່ນ Windows ສ່ວນໃຫຍ່ພວກເຮົາໄດ້ໃຊ້ PostgreSQL ດ້ວຍຄວາມສາມາດຂອງເຂົາເຈົ້າ. ເນື່ອງຈາກພວກເຮົາໄດ້ຕັດສິນໃຈແລ້ວທີ່ຈະປະຖິ້ມທຸກສິ່ງທຸກຢ່າງທີ່ຈ່າຍ, ພວກເຮົາໄດ້ເລີ່ມໃຊ້ PostgreSQL ຢູ່ທີ່ນີ້ເຊັ່ນກັນ.

ໃນສ່ວນນີ້ຂ້ອຍຢາກບອກເຈົ້າວ່າພວກເຮົາປັບປຸງຖານຂໍ້ມູນແນວໃດແລະວິທີທີ່ພວກເຮົາເລືອກລະຫວ່າງ Flyway ແລະ Entity Framework Core. ໃຫ້ເບິ່ງຢູ່ໃນ pros ແລະ cons ຂອງເຂົາເຈົ້າ.

Минусы

Flyway ພຽງແຕ່ໄປທາງດຽວ, ພວກເຮົາ ພວກ​ເຮົາ​ບໍ່​ສາ​ມາດ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ - ນີ້ແມ່ນຂໍ້ເສຍທີ່ສໍາຄັນ. ທ່ານສາມາດປຽບທຽບມັນກັບ Entity Framework Core ໃນວິທີອື່ນ - ໃນແງ່ຂອງຄວາມສະດວກສະບາຍຂອງນັກພັດທະນາ. ທ່ານຈື່ໄດ້ວ່າພວກເຮົາວາງອັນນີ້ຢູ່ໃນອັນດັບຕົ້ນໆ, ແລະເງື່ອນໄຂຕົ້ນຕໍແມ່ນບໍ່ປ່ຽນແປງຫຍັງສໍາລັບການພັດທະນາ Windows.

ສໍາລັບ Flyway ພວກເຮົາ ບາງປະເພດຂອງ wrapper ແມ່ນຈໍາເປັນເພື່ອບໍ່ໃຫ້ guys ຂຽນ SQL ສອບຖາມ. ພວກເຂົາເຈົ້າແມ່ນໃກ້ຊິດກັບການດໍາເນີນງານໃນເງື່ອນໄຂ OOP. ພວກເຮົາຂຽນຄໍາແນະນໍາສໍາລັບການເຮັດວຽກກັບວັດຖຸຖານຂໍ້ມູນ, ສ້າງຄໍາຖາມ SQL ແລະປະຕິບັດມັນ. ສະບັບໃຫມ່ຂອງຖານຂໍ້ມູນແມ່ນກຽມພ້ອມ, ທົດສອບ - ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ.

Entity Framework Core ມີລົບ - ພາຍໃຕ້ການໂຫຼດຫນັກ ສ້າງການສອບຖາມ SQL ທີ່ດີທີ່ສຸດ, ແລະ drawdown ໃນຖານຂໍ້ມູນສາມາດມີຄວາມສໍາຄັນ. ແຕ່ເນື່ອງຈາກພວກເຮົາບໍ່ມີບໍລິການໂຫຼດສູງ, ພວກເຮົາບໍ່ໄດ້ຄິດໄລ່ການໂຫຼດໃນຫຼາຍຮ້ອຍ RPS, ພວກເຮົາຍອມຮັບຄວາມສ່ຽງເຫຼົ່ານີ້ແລະມອບຫມາຍບັນຫາໃຫ້ກັບພວກເຮົາໃນອະນາຄົດ.

ຄວາມຄິດເຫັນ

Entity Framework Core ເຮັດວຽກອອກຈາກກ່ອງແລະງ່າຍຕໍ່ການພັດທະນາ, ແລະ Flyway ປະສົມປະສານເຂົ້າໃນ CI ທີ່ມີຢູ່ແລ້ວໄດ້ຢ່າງງ່າຍດາຍ. ແຕ່ພວກເຮົາເຮັດໃຫ້ມັນສະດວກສໍາລັບນັກພັດທະນາ :)

ຂັ້ນຕອນການມ້ວນ

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

ແອັບພລິເຄຊັນໃຊ້ຂໍ້ມູນທີ່ລະອຽດອ່ອນ, ເຊັ່ນ: tokens, ລະຫັດຜ່ານຖານຂໍ້ມູນ, ທັງຫມົດນີ້ຖືກດຶງເຂົ້າໄປໃນ config ຈາກ Puppet master, ບ່ອນທີ່ພວກມັນຖືກເກັບໄວ້ໃນຮູບແບບທີ່ຖືກເຂົ້າລະຫັດ.

ບັນຫາ TFS

ຫຼັງຈາກທີ່ພວກເຮົາຕັດສິນໃຈແລະຮູ້ວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກສໍາລັບພວກເຮົາແທ້ໆ, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນກັບສະພາແຫ່ງໃນ TFS ໂດຍລວມສໍາລັບພະແນກພັດທະນາ Win ໃນໂຄງການອື່ນໆ - ບໍ່ວ່າພວກເຮົາຈະສ້າງ / ປ່ອຍຢ່າງໄວວາຫຼືບໍ່, ແລະ. ຄົ້ນພົບບັນຫາທີ່ສໍາຄັນກັບຄວາມໄວ.

ຫນຶ່ງໃນໂຄງການຕົ້ນຕໍໃຊ້ເວລາ 12-15 ນາທີເພື່ອລວບລວມ - ນັ້ນແມ່ນເວລາດົນນານ, ທ່ານບໍ່ສາມາດດໍາລົງຊີວິດແບບນັ້ນໄດ້. ການວິເຄາະໄວໄດ້ສະແດງໃຫ້ເຫັນເຖິງການຫຼຸດລົງທີ່ຮ້າຍແຮງໃນ I/O, ແລະນີ້ແມ່ນຢູ່ໃນ arrays.

ຫຼັງຈາກການວິເຄາະອົງປະກອບໂດຍອົງປະກອບ, ຂ້າພະເຈົ້າໄດ້ກໍານົດສາມ foci. ຫນ້າທໍາອິດ - "Kaspersky antivirus", ເຊິ່ງສະແກນແຫຼ່ງຕ່າງໆໃນຕົວແທນ Windows Build ທັງຫມົດ. ສອງ - Windows ດັດຊະນີ. ມັນບໍ່ໄດ້ຖືກພິການ, ແລະທຸກສິ່ງທຸກຢ່າງໄດ້ຖືກດັດສະນີໃນເວລາທີ່ແທ້ຈິງໃນ Build agents ໃນລະຫວ່າງຂະບວນການຕິດຕັ້ງ.

ທີສາມ - ຕິດຕັ້ງ Npm. ມັນໄດ້ຫັນອອກວ່າໃນທໍ່ສ່ວນໃຫຍ່ພວກເຮົາໄດ້ໃຊ້ສະຖານະການທີ່ແນ່ນອນນີ້. ເປັນຫຍັງລາວຈຶ່ງບໍ່ດີ? ຂັ້ນ​ຕອນ​ການ​ຕິດ​ຕັ້ງ Npm ແມ່ນ​ດໍາ​ເນີນ​ການ​ໃນ​ເວ​ລາ​ທີ່​ຕົ້ນ​ໄມ້​ການ​ເພິ່ງ​ພາ​ອາ​ໄສ​ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ໃນ package-lock.json, ບ່ອນທີ່ສະບັບຂອງແພັກເກດທີ່ຈະໃຊ້ເພື່ອສ້າງໂຄງການໄດ້ຖືກບັນທຶກໄວ້. ການຫຼຸດລົງແມ່ນວ່າການຕິດຕັ້ງ Npm ດຶງເອົາຊຸດຮຸ່ນຫຼ້າສຸດຈາກອິນເຕີເນັດທຸກໆຄັ້ງ, ແລະນີ້ໃຊ້ເວລາຫຼາຍໃນກໍລະນີຂອງໂຄງການຂະຫນາດໃຫຍ່.

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

ການຕັດສິນໃຈ

• ແຫຼ່ງຂໍ້ມູນໃນຂໍ້ຍົກເວັ້ນ AV.
• ປິດການດັດສະນີ.
• ໄປ​ຫາ npm ci.

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

ການຕັ້ງຄ່າ

ໃນປັດຈຸບັນເລັກນ້ອຍກ່ຽວກັບການຕັ້ງຄ່າ repository. ພວກເຮົາໃຊ້ໃນປະຫວັດສາດ Nexus ສໍາລັບການຄຸ້ມຄອງ repositories, ລວມທັງ REPO ພາຍໃນ. ຄັງເກັບມ້ຽນພາຍໃນນີ້ປະກອບດ້ວຍອົງປະກອບທັງຫມົດທີ່ພວກເຮົາໃຊ້ສໍາລັບຈຸດປະສົງພາຍໃນ, ຕົວຢ່າງ, ການກວດສອບການຂຽນດ້ວຍຕົນເອງ.

ພວກເຮົາຍັງໃຊ້ NuGet, ເນື່ອງຈາກວ່າມັນມີ caching ທີ່ດີກວ່າເມື່ອທຽບກັບຜູ້ຈັດການຊຸດອື່ນໆ.

ຜົນ

ຫຼັງຈາກທີ່ພວກເຮົາປັບຕົວສ້າງຕົວແທນໃຫ້ເໝາະສົມແລ້ວ, ເວລາກໍ່ສ້າງສະເລ່ຍຫຼຸດລົງຈາກ 12 ນາທີມາເປັນ 7 ນາທີ.

ຖ້າພວກເຮົານັບເຄື່ອງທັງຫມົດທີ່ພວກເຮົາສາມາດໃຊ້ສໍາລັບ Windows, ແຕ່ປ່ຽນເປັນ Linux ໃນໂຄງການນີ້, ພວກເຮົາປະຫຍັດໄດ້ປະມານ $ 10. ແລະນັ້ນແມ່ນພຽງແຕ່ຢູ່ໃນໃບອະນຸຍາດ, ແລະຫຼາຍກວ່ານັ້ນຖ້າພວກເຮົາຄໍານຶງເຖິງເນື້ອຫາ.

ແຜນການ

ສໍາລັບໄຕມາດຕໍ່ໄປ, ພວກເຮົາວາງແຜນທີ່ຈະເຮັດວຽກກ່ຽວກັບການເພີ່ມປະສິດທິພາບການຈັດສົ່ງລະຫັດ.

ກຳລັງປ່ຽນເປັນຮູບ Docker ທີ່ສ້າງຂຶ້ນກ່ອນ. TFS ເປັນສິ່ງທີ່ເຢັນທີ່ມີ plugins ຫຼາຍອັນທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດປະສົມປະສານເຂົ້າໄປໃນ Pipeline, ລວມທັງການປະກອບທີ່ອີງໃສ່ຜົນກະທົບຕໍ່, ເວົ້າ, ຮູບພາບ Docker. ພວກເຮົາຕ້ອງການສ້າງຜົນກະທົບຕໍ່ນີ້ສໍາລັບອັນດຽວກັນ package-lock.json. ຖ້າອົງປະກອບຂອງອົງປະກອບທີ່ໃຊ້ໃນການສ້າງໂຄງການມີການປ່ຽນແປງບາງຢ່າງ, ພວກເຮົາສ້າງຮູບພາບ Docker ໃຫມ່. ຕໍ່ມາມັນຖືກນໍາໃຊ້ເພື່ອປັບໃຊ້ຕູ້ຄອນເທນເນີດ້ວຍຄໍາຮ້ອງສະຫມັກທີ່ປະກອບ. ນີ້ບໍ່ແມ່ນກໍລະນີໃນປັດຈຸບັນ, ແຕ່ພວກເຮົາກໍາລັງວາງແຜນທີ່ຈະປ່ຽນໄປສູ່ສະຖາປັດຕະຍະກໍາຈຸລະພາກໃນ Kubernetes, ເຊິ່ງກໍາລັງພັດທະນາຢ່າງຫ້າວຫັນໃນບໍລິສັດຂອງພວກເຮົາແລະໃຫ້ບໍລິການການແກ້ໄຂການຜະລິດເປັນເວລາດົນນານ.

Summary

ຂ້າ​ພະ​ເຈົ້າ​ແນະ​ນໍາ​ໃຫ້​ທຸກ​ຄົນ​ຖິ້ມ Windows​, ແຕ່​ວ່າ​ມັນ​ບໍ່​ແມ່ນ​ຍ້ອນ​ວ່າ​ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ຮູ້​ວິ​ທີ​ການ​ແຕ່ງ​ກິນ​ມັນ​. ເຫດຜົນແມ່ນວ່າການແກ້ໄຂ Opensource ສ່ວນໃຫຍ່ແມ່ນ Linux stack. ເຈົ້າບໍ່ເປັນຫຍັງ ປະຫຍັດຊັບພະຍາກອນ. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ອະນາຄົດເປັນຂອງ Open Source solutions ໃນ Linux ກັບຊຸມຊົນທີ່ມີປະສິດທິພາບ.

ປະຫວັດຂອງລໍາໂພງຂອງ Alexander Sinchinov ໃນ GitHub.

DevOps Conf ແມ່ນກອງປະຊຸມກ່ຽວກັບການເຊື່ອມໂຍງການພັດທະນາ, ການທົດສອບແລະຂະບວນການປະຕິບັດງານສໍາລັບຜູ້ຊ່ຽວຊານໂດຍຜູ້ຊ່ຽວຊານ. ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າໂຄງການທີ່ Alexander ເວົ້າກ່ຽວກັບ? ປະຕິບັດແລະເຮັດວຽກ, ແລະໃນມື້ຂອງການປະຕິບັດໄດ້ມີສອງການປ່ອຍສົບຜົນສໍາເລັດ. ສຸດ DevOps Conf ຢູ່ RIT++ ໃນວັນທີ 27 ແລະ 28 ເດືອນພຶດສະພາຈະມີກໍລະນີທີ່ຄ້າຍຄືກັນຫຼາຍຈາກຜູ້ປະຕິບັດ. ທ່ານຍັງສາມາດໂດດເຂົ້າໄປໃນລົດບັນທຸກສຸດທ້າຍແລະ ສົ່ງບົດລາຍງານ ຫຼືໃຊ້ເວລາຂອງເຈົ້າ ຈອງ ປີ້. ພົບກັບພວກເຮົາໃນ Skolkovo!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com