ເຄື່ອງມື DevOps ທຸກຄົນຄວນຮຽນຮູ້ໃນປີ 2020

ເລີ່ມໃຊ້ເຄື່ອງມື DevOps ທີ່ດີທີ່ສຸດໃນມື້ນີ້!

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

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

ໃຫ້ພວກເຮົາແບ່ງເຄື່ອງມື DevOps ເຂົ້າໄປໃນປະເພດຕ່າງໆແລະປຽບທຽບພວກມັນກັບ analogues:

• ການ​ພັດ​ທະ​ນາ​ແລະ​ການ​ກໍ່​ສ້າງ​ເຄື່ອງ​ມື​
• ເຄື່ອງ​ມື​ການ​ທົດ​ສອບ​ອັດ​ຕະ​ໂນ​ມັດ​
• ເຄື່ອງ​ມື​ໃນ​ການ​ຈັດ​ຕັ້ງ​ການ​ນໍາ​ໃຊ້​
• ເຄື່ອງ​ມື Runtime
• ເຄື່ອງ​ມື​ການ​ຮ່ວມ​ມື​.

ການປະຕິບັດທີ່ປະສົບຜົນສໍາເລັດແລະມີຄວາມຄິດ ຜູ້ປະຕິບັດ DevOps ປະກອບມີເຄື່ອງມືຈາກທັງຫ້າກຸ່ມທີ່ລະບຸໄວ້ຂ້າງເທິງ. ວິເຄາະຊຸດເຄື່ອງມືປະຈຸບັນໃນໂຄງການຂອງທ່ານເພື່ອບໍ່ໃຫ້ພາດອົງປະກອບທີ່ສໍາຄັນຂອງທໍ່ CI/CD.

ເຄື່ອງມືພັດທະນາແລະການກໍ່ສ້າງ

ນີ້ແມ່ນພື້ນຖານຂອງທໍ່ CI/CD. ມັນທັງຫມົດເລີ່ມຕົ້ນຢູ່ທີ່ນີ້! ເຄື່ອງມືທີ່ດີທີ່ສຸດໃນປະເພດນີ້ສາມາດຈັດການການຖ່າຍທອດເຫດການຫຼາຍຢ່າງແລະປະສົມປະສານໄດ້ງ່າຍກັບຜະລິດຕະພັນອື່ນໆ.

ໃນຂັ້ນຕອນຂອງວົງຈອນຊີວິດການພັດທະນານີ້, ມີສາມກຸ່ມຂອງເຄື່ອງມື:

• ລະບົບຄວບຄຸມເວີຊັນ (SCM)
• ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ (CI)
• ການຈັດການຂໍ້ມູນ

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

SCM + CI ເຄື່ອງມື #1

ຜູ້ຊະນະ: GitLab ແລະ GitLab-CI

ເຄື່ອງມືທີ່ດີທີ່ສຸດຂອງຮອບວຽນ DevOps ປີ 2020 ແມ່ນ GitLab ໂດຍບໍ່ຕ້ອງສົງໃສ, ແລະແນ່ນອນມັນຈະສືບຕໍ່ນໍາພາການປະດິດສ້າງໃນອະນາຄົດອັນໃກ້ນີ້.

ຫນ້າທີ່ຕົ້ນຕໍຂອງ GitLab ແມ່ນເພື່ອສະຫນອງການຄຸ້ມຄອງທີ່ສະດວກສະບາຍຂອງ Git repository. ການໂຕ້ຕອບຂອງເວັບໄຊຕ໌ແມ່ນ intuitive ແລະງ່າຍທີ່ຈະນໍາໃຊ້. GitLab ສະຫນອງທຸກສິ່ງທຸກຢ່າງທີ່ທ່ານຕ້ອງການໃນສະບັບຟຣີແລະມາເປັນ SaaS ແລະ on-prem (ການນໍາໃຊ້ຊັບພະຍາກອນຂອງທ່ານເອງເພື່ອເປັນເຈົ້າພາບຊອບແວ).

ບໍ່ມີເຄື່ອງມື SCM ອື່ນໃດທີ່ໃຊ້ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ (CI) ໂດຍກົງຢູ່ໃນບ່ອນເກັບມ້ຽນຂອງເຈົ້າ, ແລະ GitLab ໄດ້ເຮັດແບບນີ້ມາດົນແລ້ວ. ເພື່ອໃຊ້ GitLab-CI, ທ່ານຕ້ອງເພີ່ມໄຟລ໌ .gitlab-ci.yml ໃສ່ຮາກລະຫັດແຫຼ່ງຂອງທ່ານ, ແລະການປ່ຽນແປງໃດໆຕໍ່ກັບໂຄງການຈະສົ່ງຜົນກະທົບຕໍ່ການດໍາເນີນການໂດຍອີງໃສ່ສິ່ງທີ່ທ່ານໄດ້ລະບຸໄວ້. GitLab ແລະ GitLab-CI ໄດ້ຮັບການຍອມຮັບຢ່າງສົມຄວນເປັນຜູ້ນໍາໃນດ້ານການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ (CI-as-code).

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• ຄວາມຫນ້າເຊື່ອຖື - ຜະລິດຕະພັນໄດ້ອອກສູ່ຕະຫຼາດຕັ້ງແຕ່ປີ 2013; ໝັ້ນຄົງ; ສະ​ຫນັບ​ສະ​ຫນູນ​ທີ່​ດີ​.
• Open Source - ສະບັບຟຣີຂອງ GitLab ບໍ່ຈໍາກັດການທໍາງານຫຼັກທີ່ທີມງານພັດທະນາຕ້ອງການ. ຊຸດບໍລິການທີ່ຈ່າຍເງິນໃຫ້ຄຸນສົມບັດທີ່ເປັນປະໂຫຍດເພີ່ມເຕີມສໍາລັບບໍລິສັດທີ່ມີຂະຫນາດແລະຄວາມຕ້ອງການທີ່ແຕກຕ່າງກັນ.
• Engrained CI - ບໍ່ມີເຄື່ອງມືອື່ນໃດໃນຕະຫຼາດໄດ້ສ້າງການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງໂດຍກົງໃນ SCM ເຊັ່ນ GitLab-CI. ການໃຊ້ Docker ຮັບປະກັນການສ້າງແບບໂດດດ່ຽວທີ່ບໍ່ຫຍຸ້ງຍາກ, ແລະບົດລາຍງານທີ່ສ້າງຂຶ້ນມາເຮັດໃຫ້ການດີບັກງ່າຍ. ພວກ​ເຮົາ​ບໍ່​ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ການ​ເຊື່ອມ​ໂຍງ​ສະ​ລັບ​ສັບ​ຊ້ອນ​ແລະ​ການ​ຄຸ້ມ​ຄອງ​ຂອງ​ຫຼາຍ​ເຄື່ອງ​ມື​ໃນ​ເວ​ລາ​ດຽວ​ກັນ​.
• ການເຊື່ອມໂຍງແບບບໍ່ຈໍາກັດ - GitLab ສະຫນອງການເຊື່ອມໂຍງງ່າຍຂອງເຄື່ອງມື DevOps ທັງຫມົດທີ່ທ່ານຕ້ອງການ. ນີ້ຮັບປະກັນວ່າທີມງານພັດທະນາແລະບໍາລຸງຮັກສາມີແຫຼ່ງດຽວຂອງຂໍ້ມູນກ່ຽວກັບຄໍາຮ້ອງສະຫມັກຂອງເຂົາເຈົ້າໃນສະພາບແວດລ້ອມໃດ.

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

ມີເຄື່ອງມືທີ່ນິຍົມອື່ນໆໃນປະເພດນີ້, ແຕ່ພວກມັນບໍ່ດີເທົ່າກັບ GitLab. ແລະນັ້ນແມ່ນເຫດຜົນ:

GitHub — ນີ້​ແມ່ນ​ລະ​ບົບ​ການ​ຄວບ​ຄຸມ​ສະ​ບັບ SaaS ທີ່​ດີ​ເລີດ​ສໍາ​ລັບ​ບໍ​ລິ​ສັດ​ຂະ​ຫນາດ​ນ້ອຍ​ແລະ​ຂັ້ນ​ຕອນ​ຕົ້ນ​ຂອງ​ການ​ພັດ​ທະ​ນາ​. ສໍາລັບບໍລິສັດຂະຫນາດໃຫຍ່ທີ່ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຮັກສາທີ່ຢູ່ IP ຢູ່ໃນເຄືອຂ່າຍຂອງຕົນເອງ, ການແກ້ໄຂພຽງແຕ່ຈາກ GitHub ແມ່ນເຄື່ອງ virtual .OVA ໂດຍບໍ່ມີການສະຫນັບສະຫນູນສໍາລັບລະບົບທີ່ມີໃຫ້ສູງ. ອັນນີ້ເຮັດໃຫ້ການບໍາລຸງຮັກສາເທິງ prem ມີຄວາມຫຍຸ້ງຍາກ, ນອກຈາກນັ້ນ, .OVA ແມ່ນເຫມາະສົມສໍາລັບທຸລະກິດຂະຫນາດກາງ, ຖ້າບໍ່ດັ່ງນັ້ນເຄື່ອງແມ່ຂ່າຍຈະ crash ພາຍໃຕ້ການໂຫຼດຫຼາຍກວ່າເກົ່າ. ການຂາດການປະຕິບັດ GitHub (ຈົນກ່ວາບໍ່ດົນມານີ້ແລະຍັງບໍ່ທັນຢູ່ໃນສະບັບ prem) ຫຼື CI-as-code ຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງເລືອກເຄື່ອງມື CI ແຍກຕ່າງຫາກແລະຫຼັງຈາກນັ້ນຈັດການການເຊື່ອມໂຍງນັ້ນ. ສຸດທ້າຍ, GitHub ແມ່ນລາຄາແພງກວ່າ GitLab ລຸ້ນໃດກໍ່ຕາມ.

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

BitBucket/ໄມ້ໄຜ່ — ຂ້າ​ພະ​ເຈົ້າ​ຕ້ອງ​ຮັບ​ຮູ້​ເຂົາ​ເປັນ​ຜູ້​ສູນ​ເສຍ​ອັດ​ຕະ​ໂນ​ມັດ​: ເປັນ​ຫຍັງ​ສອງ​ເຄື່ອງ​ມື​ໃນ​ເວ​ລາ​ທີ່ GitLab ເຮັດ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ເປັນ​ອິດ​ສະ​ຫຼະ​. BitBucket Cloud ສະຫນັບສະຫນູນການທໍາງານຂອງ GitLab-CI / GitHub, ແຕ່ບໍ່ມີບໍລິສັດໃດໃຫຍ່ກວ່າການເລີ່ມຕົ້ນສາມາດປະຕິບັດມັນໄດ້ງ່າຍໆ. ເຊີບເວີ BitBucket ຢູ່ເບື້ອງຕົ້ນບໍ່ຮອງຮັບທໍ່ BitBucket!

#1 ເຄື່ອງມືຄຸ້ມຄອງຂໍ້ມູນ

ຜູ້ຊະນະ: FlywayDB

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• ການສ້າງສະບັບຖານຂໍ້ມູນ - Flyway ອະນຸຍາດໃຫ້ທ່ານສ້າງສະບັບຖານຂໍ້ມູນ, ຕິດຕາມການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ, ແລະໄດ້ຢ່າງງ່າຍດາຍໂອນຫຼືກັບຄືນການປ່ຽນແປງ schema ໂດຍບໍ່ມີເຄື່ອງມືເພີ່ມເຕີມສໍາລັບການນີ້.
• Binary ຫຼື Embedded - ພວກເຮົາສາມາດເລືອກທີ່ຈະດໍາເນີນການ Flyway ເປັນສ່ວນຫນຶ່ງຂອງຄໍາຮ້ອງສະຫມັກຫຼືເປັນ binary executable. Flyway ກວດສອບຄວາມເຂົ້າກັນໄດ້ຂອງເວີຊັນໃນຕອນເລີ່ມຕົ້ນ ແລະເລີ່ມການເຄື່ອນຍ້າຍທີ່ເໝາະສົມ, ຮັກສາຖານຂໍ້ມູນ ແລະເວີຊັນແອັບພລິເຄຊັນໃຫ້ເຂົ້າກັນໄດ້. ໂດຍການດໍາເນີນການຄໍາສັ່ງ cmd line ad-hoc, ພວກເຮົາສະຫນອງຄວາມຍືດຫຍຸ່ນໃຫ້ກັບຖານຂໍ້ມູນທີ່ມີຢູ່ແລ້ວໂດຍບໍ່ມີການສ້າງໃຫມ່ຄໍາຮ້ອງສະຫມັກທັງຫມົດ.

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

ບໍ່ມີເຄື່ອງມືຫຼາຍໃນພື້ນທີ່ນີ້. ຂໍ​ໃຫ້​ເບິ່ງ​ບາງ​ສ່ວນ​ຂອງ​ເຂົາ​ເຈົ້າ​:

LiquiBase - Liquibase ຄ້າຍຄືກັບ FlywayDB. ຂ້ອຍຢາກຕັ້ງມັນຢູ່ເທິງ Flyway ຖ້າຂ້ອຍມີຄົນຢູ່ໃນທີມຂອງຂ້ອຍທີ່ມີປະສົບການຫຼາຍກວ່າກັບ Liquibase.

Flocker - ພຽງແຕ່ສາມາດເຮັດວຽກສໍາລັບຄໍາຮ້ອງສະຫມັກບັນຈຸ. ເພື່ອດໍາເນີນການຖານຂໍ້ມູນບັນຈຸບັນຈຸສົບຜົນສໍາເລັດ, ທຸກສິ່ງທຸກຢ່າງຕ້ອງໄດ້ຮັບການວາງແຜນຢ່າງສົມບູນ. ຂ້ອຍແນະນໍາໃຫ້ໃຊ້ RDS (Relational Database Service) ສໍາລັບຖານຂໍ້ມູນແລະບໍ່ແນະນໍາໃຫ້ເກັບຮັກສາຂໍ້ມູນທີ່ສໍາຄັນໃນຖັງ.

ທົດສອບເຄື່ອງມືອັດຕະໂນມັດ

ໃຫ້ເລີ່ມຕົ້ນການສົນທະນາຂອງພວກເຮົາກ່ຽວກັບເຄື່ອງມືອັດຕະໂນມັດການທົດສອບໂດຍການຈັດປະເພດໃຫ້ເຂົາເຈົ້າໂດຍອີງໃສ່ pyramid ການທົດສອບ.

pyramid ການ​ທົດ​ສອບ (ການ​ທົດ​ສອບ​) ມີ 4 ລະ​ດັບ​:

• ການທົດສອບຫນ່ວຍງານ - ນີ້ແມ່ນພື້ນຖານຂອງຂະບວນການທົດສອບອັດຕະໂນມັດທັງຫມົດ. ຄວນ​ມີ​ການ​ທົດ​ສອບ​ຫົວ​ຫນ່ວຍ​ຫຼາຍ​ກວ່າ​ເມື່ອ​ທຽບ​ໃສ່​ກັບ​ການ​ທົດ​ສອບ​ປະ​ເພດ​ອື່ນໆ​. ນັກພັດທະນາຂຽນແລະດໍາເນີນການທົດສອບຫນ່ວຍງານເພື່ອຮັບປະກັນວ່າສ່ວນຫນຶ່ງຂອງແອັບພລິເຄຊັນ (ທີ່ເອີ້ນວ່າ "ຫນ່ວຍ") ສອດຄ່ອງກັບການອອກແບບຂອງມັນແລະປະຕິບັດຕົວຕາມທີ່ຄາດໄວ້.
• ການທົດສອບອົງປະກອບ - ຈຸດປະສົງຕົ້ນຕໍຂອງການທົດສອບອົງປະກອບແມ່ນເພື່ອກວດສອບພຶດຕິກໍາການປ້ອນຂໍ້ມູນ / ຜົນຜະລິດຂອງວັດຖຸທົດສອບ. ພວກເຮົາຕ້ອງຮັບປະກັນວ່າການທໍາງານຂອງວັດຖຸທົດສອບໄດ້ຖືກປະຕິບັດຢ່າງຖືກຕ້ອງຕາມຂໍ້ກໍາຫນົດ.
• ການທົດສອບການປະສົມປະສານ - ປະເພດຂອງການທົດສອບທີ່ແຕ່ລະໂມດູນຊອບແວໄດ້ຖືກລວມເຂົ້າກັນແລະທົດສອບເປັນກຸ່ມ.
• End-to-End Tests - ຂັ້ນຕອນນີ້ແມ່ນການອະທິບາຍດ້ວຍຕົນເອງ. ພວກເຮົາຕິດຕາມກວດກາຄໍາຮ້ອງສະຫມັກທັງຫມົດແລະໃຫ້ແນ່ໃຈວ່າມັນເຮັດວຽກຕາມແຜນການ.

ເນື່ອງຈາກການທົດສອບຫນ່ວຍງານແລະການທົດສອບອົງປະກອບແມ່ນດໍາເນີນໂດຍນັກພັດທະນາເທົ່ານັ້ນແລະມັກຈະເປັນພາສາການຂຽນໂປຼແກຼມສະເພາະ, ພວກເຮົາຈະບໍ່ປະເມີນເຄື່ອງມືເຫຼົ່ານີ້ສໍາລັບໂດເມນ DevOps.

#1 ເຄື່ອງມືການທົດສອບການປະສົມປະສານ

ຜູ້ຊະນະ: ໝາກແຕງກວາ

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

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

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

ໃນບັນດາກອບອື່ນໆແລະເຄື່ອງມືສະເພາະດ້ານເຕັກໂນໂລຢີ, ພຽງແຕ່ແຕງສາມາດຖືວ່າເປັນການແກ້ໄຂທົ່ວໄປ.

ເຄື່ອງ​ມື​ການ​ທົດ​ສອບ End-to-End

ໃນ​ເວ​ລາ​ທີ່​ການ​ດໍາ​ເນີນ​ການ​ທົດ​ສອບ end-to-end, ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ສຸມ​ໃສ່​ສອງ​ຈຸດ​ສໍາ​ຄັນ​:

• ການທົດສອບທີ່ເປັນປະໂຫຍດ
• ການທົດສອບຄວາມກົດດັນ.

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

ມັນຍັງມີຄວາມສໍາຄັນສໍາລັບພວກເຮົາທີ່ຈະກວດເບິ່ງວ່າຈໍານວນຜູ້ໃຊ້ທີ່ແນ່ນອນທີ່ດໍາເນີນສະຖານະການດຽວກັນສາມາດດໍາເນີນການໄດ້ໂດຍບໍ່ມີຂໍ້ຜິດພາດ.

ການຂາດການທົດສອບ 2 ປະເພດນີ້ຈະເປັນຂໍ້ບົກຜ່ອງທີ່ສໍາຄັນໃນທໍ່ CI / CD ຂອງທ່ານ.

#1 ເຄື່ອງ​ມື​ການ​ທົດ​ສອບ end-to-end. ການທົດສອບການທໍາງານ

ຜູ້ຊະນະ: SoapUI Pro

SoapUI ໄດ້ຢູ່ໃນພື້ນທີ່ທົດສອບ API ເປັນເວລາດົນນານນັບຕັ້ງແຕ່ການບໍລິການເວັບທີ່ອີງໃສ່ SOAP ເປັນມາດຕະຖານ. ໃນຂະນະທີ່ພວກເຮົາບໍ່ໄດ້ສ້າງບໍລິການ SOAP ໃໝ່ ແລະຊື່ຂອງເຄື່ອງມືບໍ່ໄດ້ມີການປ່ຽນແປງ, ນັ້ນບໍ່ໄດ້ຫມາຍຄວາມວ່າມັນບໍ່ມີການພັດທະນາ. SoapUI ສະຫນອງກອບທີ່ດີເລີດສໍາລັບການສ້າງການທົດສອບການເຮັດວຽກຂອງ backend ອັດຕະໂນມັດ. ການທົດສອບສາມາດຖືກລວມເຂົ້າກັນໄດ້ງ່າຍດ້ວຍເຄື່ອງມືປະສົມປະສານຢ່າງຕໍ່ເນື່ອງ ແລະໃຊ້ເປັນສ່ວນໜຶ່ງຂອງທໍ່ CI/CD.

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

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

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

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

#1 ເຄື່ອງ​ມື​ການ​ທົດ​ສອບ end-to-end. ການທົດສອບຄວາມກົດດັນ

ຜູ້ຊະນະ: LoadRunner

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

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

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

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

ເຄື່ອງມືນຳໃຊ້

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

ກ່ອນອື່ນໝົດ, ໃຫ້ແບ່ງເຄື່ອງມືນຳໃຊ້ທັງໝົດອອກເປັນສາມໝວດຍ່ອຍ:

• ການ​ຄຸ້ມ​ຄອງ​ວັດ​ຖຸ​ບູ​ຮານ​
• ການ​ຄຸ້ມ​ຄອງ​ການ​ຕັ້ງ​ຄ່າ​
• ປະຕິບັດ.

#1 ເຄື່ອງ​ມື​ການ​ຄຸ້ມ​ຄອງ Artifact

ຜູ້ຊະນະ: Nexus

ຄັງເກັບມ້ຽນປອມ Nexus ຮອງຮັບເກືອບທຸກເທັກໂນໂລຍີຫຼັກ, ຈາກ Java ຫາ NPM ຫາ Docker. ພວກເຮົາສາມາດໃຊ້ເຄື່ອງມືນີ້ເພື່ອເກັບຮັກສາສິ່ງປະດິດທັງຫມົດທີ່ພວກເຮົາໃຊ້. ການມອບຕົວຜູ້ຈັດການແພັກເກັດຫ່າງໄກສອກຫຼີກຍັງເລັ່ງຂະບວນການສ້າງ CI ຢ່າງຫຼວງຫຼາຍ, ເຮັດໃຫ້ແພັກເກັດສາມາດເຂົ້າເຖິງໄດ້ຫຼາຍຂຶ້ນສໍາລັບການກໍ່ສ້າງ. ປະໂຫຍດອີກອັນຫນຶ່ງແມ່ນຄວາມສາມາດໃນການໄດ້ຮັບມຸມເບິ່ງທີ່ສົມບູນຂອງແພັກເກັດທັງຫມົດທີ່ໃຊ້ໃນໂຄງການຊອບແວຫຼາຍໆຢ່າງ, ສະກັດກັ້ນການຫຸ້ມຫໍ່ແຫຼ່ງເປີດທີ່ບໍ່ປອດໄພ (ພວກເຂົາສາມາດປະຕິບັດເປັນ vector ການໂຈມຕີ).

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• ສະຫນັບສະຫນູນດ້ານວິຊາການ - ຜະລິດຕະພັນທີ່ເຊື່ອຖືໄດ້; ສະ​ຫນັບ​ສະ​ຫນູນ​ທີ່​ດີ​.
• Open Source - ສະບັບຟຣີບໍ່ຈໍາກັດການທໍາງານຫຼັກທີ່ທີມງານພັດທະນາຕ້ອງການ.

#1 ເຄື່ອງມືການຈັດການການຕັ້ງຄ່າ

ຜູ້ຊະນະ: ຄວາມເຂົ້າໃຈ

Ansible ເປັນຜູ້ນໍາສໍາລັບເຫດຜົນງ່າຍໆຫນຶ່ງ: ບໍ່ມີລັດ. ກ່ອນຫນ້ານີ້, ເຄື່ອງມືທີ່ຄ້າຍຄືກັນໄດ້ສຸມໃສ່ການຄຸ້ມຄອງລັດການຕັ້ງຄ່າ. ເມື່ອເປີດຕົວ, ເຄື່ອງມືດັ່ງກ່າວ, ໄດ້ຮັບການຕັ້ງຄ່າທີ່ຕ້ອງການ, ຈະພະຍາຍາມແກ້ໄຂການຕັ້ງຄ່າຄໍາຮ້ອງສະຫມັກໃນປະຈຸບັນ. ແລະດ້ວຍວິທີການໃຫມ່, ມີພຽງແຕ່ອົງປະກອບທີ່ບໍ່ມີລັດ. ລຸ້ນໃໝ່ຂອງລະຫັດແມ່ນສິ່ງປອມທີ່ນຳໃຊ້ເພື່ອທົດແທນລະຫັດທີ່ມີຢູ່ແລ້ວ. ນີ້ສາມາດໄດ້ຮັບການພິຈາລະນາປະເພດຂອງ ephemeral, ສະພາບແວດລ້ອມໄລຍະສັ້ນ.

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• Stateless - Playbook ໄດ້ຖືກເປີດຕົວຈາກເຄື່ອງ deployment ແລະປະຕິບັດໃນເຄື່ອງແມ່ຂ່າຍເປົ້າຫມາຍ. ຂ້ອຍບໍ່ຕ້ອງກັງວົນກ່ຽວກັບສະຖານະຂອງວັດຖຸຫ່າງໄກສອກຫຼີກໂດຍໃຊ້ເຄື່ອງມືເຊັ່ນ Packer ເພື່ອສ້າງວັດຖຸທີ່ສາມາດປະຕິບັດໄດ້.
• Open Source - ເຊັ່ນດຽວກັນກັບ CentOS, Ansible ຍັງໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍ RedHat. ມັນຊ່ວຍຮັກສາຊຸມຊົນແລະສະຫນອງໂມດູນທີ່ມີຄຸນນະພາບສູງ, ງ່າຍຕໍ່ການນໍາໃຊ້.
• ການທົດສອບກັບໂມເລກຸນ (ໂຄງຮ່າງການ Ansible) - ເນື່ອງຈາກການຈັດການການຕັ້ງຄ່າແມ່ນລະຫັດ, ເຊັ່ນດຽວກັບສິ່ງອື່ນ, ການທົດສອບເປັນສິ່ງຈໍາເປັນ. ກອບການທົດສອບບົດບາດຂອງ Ansible ຂອງໂມເລກຸນເຮັດວຽກຢ່າງບໍ່ມີຂໍ້ບົກພ່ອງ, ຮັບປະກັນວ່າການຕັ້ງຄ່າມີຄຸນນະພາບດຽວກັນ ແລະປະຕິບັດຕາມທໍ່ CI/CD ດຽວກັນກັບລະຫັດແອັບພລິເຄຊັນ.
• YAML - ເມື່ອປຽບທຽບກັບເຄື່ອງມືອື່ນໆ, YAML ແມ່ນເຂົ້າໃຈງ່າຍກວ່າ. ເນື່ອງຈາກການຈັດການການຕັ້ງຄ່າໂດຍທົ່ວໄປແມ່ນເປັນສິ່ງທ້າທາຍໃຫມ່ສໍາລັບຜູ້ທີ່ປະຕິບັດການປະຕິບັດ DevOps, ຄວາມງ່າຍດາຍແມ່ນບັດ trump ຂອງມັນ.

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

OpsCode Chef — ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ເຮັດ​ວຽກ DevOps ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ເປັນ​ຜູ້​ພັດ​ທະ​ນາ cookbook​. Ruby ແລະ Chef ແມ່ນແນ່ນອນທີ່ຮັກແພງກັບຫົວໃຈຂອງຂ້ອຍ, ແຕ່ພວກເຂົາພຽງແຕ່ບໍ່ໄດ້ແກ້ໄຂບັນຫາຂອງຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ມີລັດທີ່ທັນສະໄຫມ, cloud-native. OpsCode Chef ເປັນເຄື່ອງມືທີ່ດີສໍາລັບຄໍາຮ້ອງສະຫມັກແບບດັ້ງເດີມຫຼາຍ, ແຕ່ໃນບົດຄວາມນີ້ພວກເຮົາກໍາລັງສຸມໃສ່ອະນາຄົດ.

ພ້າ — Puppet ບໍ່ເຄີຍມີແຟນຫຼາຍ, ໂດຍສະເພາະເມື່ອປຽບທຽບກັບ Chef ແລະ Ansible. ມັນດີເລີດສໍາລັບການສະຫນອງແລະເຮັດວຽກກັບຮາດແວ, ແຕ່ມັນຂາດການສະຫນັບສະຫນູນການຈັດການການຕັ້ງຄ່າທີ່ທັນສະໄຫມສໍາລັບຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌.

ເຄື່ອງມືການນຳໃຊ້ #1

ຜູ້ຊະນະ: Terraform

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• Environment agnostic - Terraform ໃຊ້ຫນ້າທີ່ເຮັດຫນ້າທີ່ເປັນການໂຕ້ຕອບລະຫວ່າງລະຫັດ Terraform ຂອງທ່ານ, APIs ທັງຫມົດ, ແລະເຫດຜົນພາຍໃນເພື່ອຕິດຕໍ່ສື່ສານກັບຜູ້ໃຫ້ບໍລິການໂຄງສ້າງພື້ນຖານ. ນີ້ຫມາຍຄວາມວ່າຂ້ອຍຈະຊໍານິຊໍານານພຽງແຕ່ຫນຶ່ງເຄື່ອງມືແລະຫຼັງຈາກນັ້ນສາມາດເຮັດວຽກໄດ້ທຸກບ່ອນ.
• Open Source - ມັນຍາກທີ່ຈະຕີເຄື່ອງມືຟຣີ! ສະຫນັບສະຫນູນຊຸມຊົນໃນລະດັບສູງສຸດ.

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

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

ເຄື່ອງ​ມື Runtime

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

ປະ​ເພດ​ຍ່ອຍ​ຂອງ​ເຄື່ອງ​ມື runtime​:

• X-as-a-service (XaaS)
• ວົງດົນຕີ
• ການຕິດຕາມ
• ການຕັດໄມ້.

X-tool-as-a-service #1

ຜູ້ຊະນະ: Amazon Web Services

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

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

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

ສີຟ້າສົດ "Azure ໄດ້ມາເປັນເວລາດົນນານນັບຕັ້ງແຕ່ການເປີດຕົວຄັ້ງທໍາອິດ, ແລະນັ້ນແມ່ນຫນ້າຊົມເຊີຍ. ຢ່າງໃດກໍ່ຕາມ, ຄວາມປາຖະຫນາທີ່ຈະແຕກຕ່າງກັນໄດ້ເຮັດໃຫ້ຊື່ແປກສໍາລັບການບໍລິການ, ເຊິ່ງມັກຈະເຮັດໃຫ້ການເຮັດວຽກສັບສົນ. "blob storage" ຫມາຍຄວາມວ່າແນວໃດ? ແລະໃນຂະນະທີ່ລະຫັດ .NET ເຮັດວຽກດີຂຶ້ນໃນລະບົບນິເວດຂອງ Microsoft, ມັນຄົງຈະບໍ່ເປັນທີ່ເຈົ້າຈະໃຊ້ພຽງແຕ່ .NET ສໍາລັບທຸກອົງປະກອບຂອງແອັບພລິເຄຊັນຂອງເຈົ້າ.

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

#1 ເຄື່ອງ​ມື Orchestration

ຜູ້ຊະນະ: openshift

ທ່ານອາດຈະໃຊ້ Docker ຫຼືບັນຈຸອື່ນໆໃນ stack ຄໍາຮ້ອງສະຫມັກຂອງທ່ານ. ແອັບພລິເຄຊັນທີ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍແມ່ນດີຫຼາຍ, ແຕ່ພວກມັນອາດຈະບໍ່ເຫມາະສົມກັບທຸກໆສະຖາປັດຕະຍະກໍາ. ການແລ່ນຕູ້ຄອນເທນເນີໂດຍບໍ່ມີເວທີ orchestration ພຽງແຕ່ຈະບໍ່ເຮັດວຽກ. Kubernetes Core (K8s) ແມ່ນບໍ່ມີໃຜທຽບເທົ່າໃນດ້ານຄວາມປອດໄພ ແລະເຄື່ອງມື. OpenShift ເປັນແພລະຕະຟອມທີ່ອີງໃສ່ Kubernetes ເທົ່ານັ້ນທີ່ສາມາດເກັບກໍາ Source2Image, ສະຫນັບສະຫນູນການນໍາໄປໃຊ້ອັດຕະໂນມັດກັບ pods, ແລະສະຫນັບສະຫນູນການຕິດຕາມແລະການຕິດຕາມ. OpenShift ສາມາດຖືກເປີດໃຊ້ໃນ prem, ໃນຄລາວ, ຫຼືໃນ prem ແລະໃນຄລາວໃນເວລາດຽວກັນ.

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• ຄວາມປອດໄພໃນຕົວ - ການຄຸ້ມຄອງຄວາມປອດໄພ K8s ອາດຈະຕ້ອງການລະດັບຂັ້ນສູງ. ທຸກ​ລາຍ​ລະ​ອຽດ​ຕ້ອງ​ໄດ້​ຄິດ​ອອກ​ຢ່າງ​ລະ​ມັດ​ລະ​ວັງ​ແລະ​ຄໍາ​ຄິດ​ເຫັນ​! ກົນໄກຄວາມປອດໄພທີ່ສ້າງຂຶ້ນໃນຄ່າເລີ່ມຕົ້ນດ້ວຍ OpenShift ເອົາພາລະຂອງນັກພັດທະນາແລະໃຫ້ແພລະຕະຟອມທີ່ປອດໄພກວ່າສໍາລັບແອັບພລິເຄຊັນ.
• All-in-one solution - ບໍ່ເຫມືອນກັບ K8s ພື້ນຖານ, ເຊິ່ງບໍ່ລວມເອົາເຄື່ອງມືການດຸ່ນດ່ຽງການໂຫຼດໂດຍຄ່າເລີ່ມຕົ້ນ, OpenShift ມີມັນທັງຫມົດ. ຂ້ອຍສາມາດໃຊ້ມັນເພື່ອສ້າງແລະໂຮດພາຊະນະ, ແລ່ນເຄື່ອງມື CI / CD, ຈັດການຂະບວນການພາຍນອກ, ຈັດການກະແຈ, ແລະອື່ນໆອີກ. ເຖິງແມ່ນວ່າການໂຕ້ຕອບຜູ້ໃຊ້ແບບກາຟິກຍັງຢູ່ໄກຈາກທີ່ສົມບູນແບບ, ວິທີການທີ່ອີງໃສ່ API ຫມາຍຄວາມວ່າທຸກສິ່ງທຸກຢ່າງສາມາດຖືກອະທິບາຍຢູ່ໃນສະຄິບ. ບໍ່ເຫມືອນກັບ GUIs ອື່ນໆສໍາລັບ K8s, OpenShift ເຮັດໃຫ້ການຮຽນຮູ້ພື້ນຖານຂອງ Kubernetes ງ່າຍຂຶ້ນຫຼາຍ. ເຈົ້າບໍ່ ຈຳ ເປັນຕ້ອງໄດ້ປະລິນຍາ!

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

ckerູງ Docker — Docker Swarm ພະຍາຍາມເຮັດໃຫ້ K8s ງ່າຍຂຶ້ນໂດຍການກໍາຈັດຫຼາຍຢ່າງ. ມັນດີສໍາລັບຄໍາຮ້ອງສະຫມັກຂະຫນາດນ້ອຍ, ແຕ່ສໍາລັບຄໍາຮ້ອງສະຫມັກວິສາຫະກິດມັນບໍ່ເຮັດວຽກ. ນອກຈາກນັ້ນ, ວິທີແກ້ໄຂເຊັ່ນ AWS ECS ໃຊ້ວິທີການທີ່ຄ້າຍຄືກັນແຕ່ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການເຮັດວຽກກັບບໍລິການອື່ນໆທີ່ຂ້ອຍສາມາດພົວພັນກັບ (Lambda, IAM, ແລະອື່ນໆ).

ເຄື່ອງ​ມື​ຕິດ​ຕາມ​ກວດ​ກາ #1​

ຜູ້ຊະນະ: Relic ໃຫມ່

ການອອກໃຫມ່ຂອງ New Relic ໄດ້ເຮັດສິ່ງຫນຶ່ງໄດ້ດີ - APM (Application Performance Monitoring) ການຕິດຕາມ. ໃນປັດຈຸບັນມັນເປັນເຄື່ອງມືຕິດຕາມກວດກາທີ່ສົມບູນແບບທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດກວດສອບເຄື່ອງແມ່ຂ່າຍ, ບັນຈຸ, ການປະຕິບັດຖານຂໍ້ມູນ, ການກວດສອບປະສົບການຂອງຜູ້ໃຊ້ສຸດທ້າຍ, ແລະແນ່ນອນ, ການກວດສອບການປະຕິບັດຂອງແອັບພລິເຄຊັນ.

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

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

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

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

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

ເຄື່ອງມືບັນທຶກ #1

ຜູ້ຊະນະ: ແຕກອອກ

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

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

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

ELK Stack (ElasticSearch, LogStash ແລະ Kibana) "ເຄື່ອງມືເຫຼົ່ານີ້ເບິ່ງຄືວ່າເປັນທີ່ນິຍົມເພາະວ່າທ່ານບໍ່ຈໍາເປັນຕ້ອງຂາຍຕັບຂອງທ່ານເພື່ອໃຊ້ພວກມັນ." ຢ່າງໃດກໍຕາມ, ເມື່ອຊຸດຂອງໄມ້ທ່ອນເຕີບໂຕແລະຈໍານວນຂອງຄໍາຮ້ອງສະຫມັກເທິງເຮືອເພີ່ມຂຶ້ນ, ການເຮັດວຽກກໍ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍ. ເມື່ອປຽບທຽບກັບ Splunk, ດ້ວຍ ELK Stack ຂ້າພະເຈົ້າໄດ້ໃຊ້ເວລາຫຼາຍຂື້ນໃນການຕັ້ງຄ່າເຄື່ອງມືກ່ອນທີ່ຈະສ້າງ dashboards ຫຼາຍກວ່າທີ່ຂ້ອຍເຄີຍມີມາກ່ອນ.

ເຄື່ອງມືຮ່ວມມື

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

ໝວດຍ່ອຍຂອງເຄື່ອງມືຮ່ວມມື:

• ການ​ຕິດ​ຕາມ​ວຽກ​ງານ​
• ChatOps
• ເອກະສານ.

#1 ເຄື່ອງມືຕິດຕາມບັນຫາ

ຜູ້ຊະນະ: Jira

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

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

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

Trello — Trello ໄດ້ຮັບຄວາມນິຍົມຢ່າງໄວວາຍ້ອນເຄື່ອງມື Kanban ຟຣີ. ຢ່າງໃດກໍຕາມ, ເມື່ອຂະບວນການຂະຫຍາຍໃຫຍ່ຂື້ນແລະທ່ານຈະໄປຈາກຫລາຍສິບວຽກໄປຫາຫລາຍພັນຄົນ, Trello ກາຍເປັນເລື່ອງຍາກທີ່ຈະນໍາທາງ, ຄົ້ນຫາແລະລາຍງານ.

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

ເຄື່ອງມື ChatOps #1

ຜູ້ຊະນະ: MatterMost

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• Open Source - ສະບັບ open source ຂອງ MatterMost ເຮັດວຽກໄດ້ດີສໍາລັບທັງທີມງານຂະຫນາດກາງແລະຂະຫນາດໃຫຍ່. ບໍ່ເຫມືອນກັບແຜນການຟຣີຂອງ Slack, ເຊິ່ງລຶບປະຫວັດຂໍ້ຄວາມຂອງທ່ານ, ການແລ່ນເຄື່ອງແມ່ຂ່າຍຂອງທ່ານເອງຫມາຍຄວາມວ່າທ່ານຮັກສາຂໍ້ມູນຂອງທ່ານທັງຫມົດ.
• ການປະສົມປະສານ - ນັບຕັ້ງແຕ່ API ເກືອບ 100% ອີງໃສ່ Slack API, ເກືອບທັງຫມົດການເຊື່ອມໂຍງ Slack ສາມາດຖືກນໍາໃຊ້ໂດຍກົງກັບ MatterMost.

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

slack — Slack ແມ່ນເຢັນ, ແຕ່ຄົນເຫຼົ່ານີ້ໄດ້ເຕີບໃຫຍ່ຂຶ້ນຫຼາຍຈົນພວກເຂົາເລີ່ມຊອກຫາກໍາໄລ. ໄລຍະການຈ່າຍຄືນຂອງທຸລະກິດກໍາລັງໃກ້ເຂົ້າມາ, ເຊິ່ງເອົາມູນຄ່າຕົ້ນຕໍຂອງພວກເຂົາໄປ: Slack ໃຫ້ບໍລິການຟຣີ; ຂໍ້ເສຍທີ່ສໍາຄັນທີ່ສຸດຂອງສະບັບຟຣີແມ່ນການລຶບປະຫວັດການສົນທະນາ.

ທີມງານຂອງ Microsoft — ພະ​ຍາ​ຍາມ​ລວມ​ຜະ​ລິດ​ຕະ​ພັນ Microsoft ກັບ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ບໍ່​ໄດ້​ເປັນ​ຂອງ Microsoft ... ໂຊກ​ດີ​! ນັ້ນແມ່ນສິ່ງທີ່ຂ້ອຍຕ້ອງເວົ້າກ່ຽວກັບເຄື່ອງມືນີ້!

ເຄື່ອງມືເອກະສານ #1

ຜູ້ຊະນະ: Confluence

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

ຜົນປະໂຫຍດທີ່ສໍາຄັນ

• ງ່າຍຕໍ່ການປະຕິບັດງານ - ເຄື່ອງມືຢືນຢູ່ຄົນດຽວສ່ວນໃຫຍ່ສາມາດສັບສົນເລັກນ້ອຍໃນການຕັ້ງຄ່າແລະປະຕິບັດງານແລະຕ້ອງການຄວາມຮູ້ບາງຢ່າງໃນການຮັກສາ. Confluence Server ເຮັດວຽກທີ່ດີເລີດອອກຈາກກ່ອງສໍາລັບຜູ້ໃຊ້ 10 ຫຼື 10,000 ຄົນ.
• Plugins - Kudos ກັບ Confluence ສໍາລັບມີການນໍາທາງທີ່ສວຍງາມ, ງ່າຍຕໍ່ການນໍາໃຊ້ອອກຈາກກ່ອງ, ແລະຄວາມສາມາດໃນການເພີ່ມ plugin ສໍາລັບເກືອບທຸກສິ່ງທຸກຢ່າງຈະປົດລັອກທ່າແຮງທີ່ຄ້າຍຄືກັບ Wiki.

ຄູ່ແຂ່ງ

ໄດ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ສູ້​ຮົບ​, ແຕ່​ບໍ່​ໄດ້​ຊະ​ນະ​

ອ່ານເອກະສານ — ເຢັນສໍາລັບແຫຼ່ງເປີດ, ແຕ່ຢ່າຄິດກ່ຽວກັບການເກັບຮັກສາຄວາມຮູ້ທີ່ສໍາຄັນຢູ່ທີ່ນີ້.

ເຄື່ອງ ໝາຍ - ດີເລີດສໍາລັບການຂຽນລະຫັດ, ແຕ່ຍາກທີ່ຈະປະກາດສະຖາປັດຕະຍະກໍາ, ຂະບວນການ, ຫຼືເອກະສານປະເພດອື່ນໆເນື່ອງຈາກການຈັດຮູບແບບສະເພາະຂອງ MarkDown.

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

ໃຫ້ສະຫຼຸບຜົນໄດ້ຮັບ

ມີຫຼາຍຮ້ອຍເຄື່ອງມື DevOps ຢູ່ໃນຕະຫຼາດ, ເຮັດໃຫ້ມັນຍາກທີ່ຈະຮູ້ວ່າອັນໃດທີ່ຈະໃຊ້ແລະເວລາທີ່ພວກເຂົາຄວນຈະຖືກປະຕິບັດ. ປະຕິບັດຕາມຄໍາແນະນໍາງ່າຍໆນີ້ເພື່ອເລືອກເຄື່ອງມື DevOps ສໍາລັບທໍ່ CI/CD ທີ່ສົມບູນ.

ໃຫ້ແນ່ໃຈວ່າເລືອກເຄື່ອງມືຈາກທັງຫ້າປະເພດ:

• ການ​ພັດ​ທະ​ນາ​ແລະ​ການ​ກໍ່​ສ້າງ​ເຄື່ອງ​ມື​
• ເຄື່ອງ​ມື​ການ​ທົດ​ສອບ​ອັດ​ຕະ​ໂນ​ມັດ​
• ເຄື່ອງ​ມື​ການ​ນໍາ​ໃຊ້​
• ເຄື່ອງ​ມື Runtime
• ເຄື່ອງ​ມື​ການ​ຮ່ວມ​ມື​.

ຄໍາແນະນໍາຕົ້ນຕໍ: ອັດຕະໂນມັດທຸກຢ່າງ!

ຂອບໃຈ Zach Shapiro!

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