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

ເມື່ອທ່ານຂຽນລະຫັດຂອງທ່ານ, ທ່ານຈໍາເປັນຕ້ອງໃຫ້ແນ່ໃຈວ່າມັນ:

1. аботает.
2. ມັນບໍ່ໄດ້ທໍາລາຍຫຍັງ, ລວມທັງລະຫັດທີ່ເພື່ອນຮ່ວມງານຂອງເຈົ້າຂຽນ.

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

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

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

ວິທີການປະສົມປະສານຢ່າງຕໍ່ເນື່ອງໄດ້ຖືກປະຕິບັດແລະພັດທະນາໃນທີມງານພັດທະນາມືຖື Avito, ເຮັດແນວໃດພວກເຂົາໄປຈາກ 0 ຫາ 450 ການກໍ່ສ້າງຕໍ່ມື້, ແລະການກໍ່ສ້າງເຄື່ອງຈັກປະກອບ 200 ຊົ່ວໂມງຕໍ່ມື້, Nikolai Nesterov (ເນສະເຕີຣອຟ) ເປັນ​ຜູ້​ເຂົ້າ​ຮ່ວມ​ໃນ​ການ​ປ່ຽນ​ແປງ​ວິ​ວັດ​ການ​ທັງ​ຫມົດ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ CI/CD Android​.

ເລື່ອງແມ່ນອີງໃສ່ຕົວຢ່າງຂອງຄໍາສັ່ງ Android, ແຕ່ວິທີການສ່ວນໃຫຍ່ໃຊ້ໃນ iOS ຄືກັນ.

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

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

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

ກວດກາ

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

• ກ່ອນອື່ນ ໝົດ, ພວກເຮົາກວດເບິ່ງ ການປະກອບ ARK.
• ຫຼາຍ ການທົດສອບ Junit.
• ພວກເຮົາພິຈາລະນາການຄຸ້ມຄອງລະຫັດ, ເນື່ອງຈາກວ່າພວກເຮົາກໍາລັງດໍາເນີນການທົດສອບ.

ເພື່ອເຂົ້າໃຈວ່າການກວດສອບເຫຼົ່ານີ້ຄວນຈະດໍາເນີນການແນວໃດ, ໃຫ້ເບິ່ງຂະບວນການພັດທະນາໃນ Avito.

ມັນສາມາດຖືກສະແດງໂດຍ schematically ເຊັ່ນ:

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

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

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

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

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

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

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

ຫຼັງ​ຈາກ​ນັ້ນ​, ພວກ​ເຮົາ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ທີ່​ຈະ​ຄິດ​ຕື່ມ​ອີກ - ພວກ​ເຮົາ​ແມ່ນ​ແຕ່​ການ​ກວດ​ສອບ​ໄດ້​ຖືກ​ຕ້ອງ​? ພວກເຮົາກໍາລັງດໍາເນີນການສ້າງຕາມຄໍາຮ້ອງຂໍການດຶງຢ່າງຖືກຕ້ອງບໍ?

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

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຂຽນ script bash ງ່າຍດາຍ premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

ມັນໃຊ້ເວລາສາມມື້ເພື່ອແກ້ໄຂບັນຫາ, ຊອກຫາທາງອອກ, ແລະຂຽນ script ນີ້.

ແອັບພລິເຄຊັນທີ່ພັດທະນາ, ວຽກງານຫຼາຍກວ່າແລະຫຼາຍປາກົດ, ທີມງານຂະຫຍາຍຕົວ, ແລະ premerge.sh ບາງຄັ້ງກໍ່ເລີ່ມປ່ອຍໃຫ້ພວກເຮົາລົງ. ນັກພັດທະນາມີການປ່ຽນແປງທີ່ຂັດແຍ້ງກັນທີ່ທໍາລາຍການກໍ່ສ້າງ.

ຕົວຢ່າງຂອງວິທີການນີ້ເກີດຂຶ້ນ:

ຜູ້ພັດທະນາສອງຄົນພ້ອມກັນເລີ່ມເຮັດວຽກກ່ຽວກັບຄຸນສົມບັດ A ແລະ B. ຜູ້ພັດທະນາຄຸນສົມບັດ A ຄົ້ນພົບຄຸນສົມບັດທີ່ບໍ່ໄດ້ໃຊ້ໃນໂຄງການ. answer() ແລະ, ຄືກັບເດັກຊາຍທີ່ດີ, ເອົາມັນອອກ. ໃນຂະນະດຽວກັນ, ຜູ້ພັດທະນາຄຸນສົມບັດ B ໄດ້ເພີ່ມການໂທໃຫມ່ໃຫ້ກັບຫນ້າທີ່ນີ້ຢູ່ໃນສາຂາຂອງລາວ.

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

ໃນເວລາທີ່ມັນຈະບໍ່ພັດທະນາ, ມັນແມ່ນ ໄພພິບັດທ້ອງຖິ່ນ. ທີມງານທັງຫມົດບໍ່ສາມາດເກັບກໍາຂໍ້ມູນແລະສົ່ງເພື່ອທົດສອບ.

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

ເນື່ອງຈາກວ່ານີ້ບໍ່ເຫມາະສົມກັບພວກເຮົາ, ພວກເຮົາເລີ່ມຄົ້ນຫາທາງເລືອກກ່ຽວກັບວິທີການປ້ອງກັນນີ້.

ວິທີການບໍ່ທໍາລາຍການພັດທະນາ

ຕົວເລືອກທໍາອິດ: ກໍ່ສ້າງຄືນໃຫມ່ທຸກຄໍາຮ້ອງຂໍການດຶງໃນເວລາທີ່ການປັບປຸງການພັດທະນາ. ຖ້າໃນຕົວຢ່າງຂອງພວກເຮົາ, ການຮ້ອງຂໍດຶງກັບຄຸນສົມບັດ A ແມ່ນຄັ້ງທໍາອິດທີ່ຈະຖືກລວມເຂົ້າໃນການພັດທະນາ, ການຮ້ອງຂໍດຶງຂອງຄຸນນະສົມບັດ B ຈະຖືກສ້າງໃຫມ່, ແລະ, ຕາມນັ້ນ, ການກວດສອບຈະລົ້ມເຫລວເນື່ອງຈາກຄວາມຜິດພາດການລວບລວມ.

ເພື່ອເຂົ້າໃຈວ່ານີ້ຈະໃຊ້ເວລາດົນປານໃດ, ພິຈາລະນາຕົວຢ່າງທີ່ມີສອງ PRs. ພວກເຮົາເປີດສອງ PR: ສອງການກໍ່ສ້າງ, ສອງແລ່ນຂອງການກວດສອບ. ຫຼັງຈາກ PR ທໍາອິດຖືກລວມເຂົ້າໃນການພັດທະນາ, ອັນທີສອງຕ້ອງໄດ້ຮັບການກໍ່ສ້າງໃຫມ່. ໃນຈໍານວນທັງຫມົດ, ສອງ PR ຕ້ອງການສາມແລ່ນຂອງການກວດສອບ: 2 + 1 = 3.

ໃນຫຼັກການ, ມັນດີ. ແຕ່ພວກເຮົາໄດ້ເບິ່ງສະຖິຕິ, ແລະສະຖານະການປົກກະຕິໃນທີມງານຂອງພວກເຮົາແມ່ນ 10 ເປີດ PRs, ແລະຫຼັງຈາກນັ້ນຈໍານວນການກວດສອບແມ່ນຜົນລວມຂອງຄວາມຄືບຫນ້າ: 10 + 9 + ... + 1 = 55. ນັ້ນແມ່ນ, ຍອມຮັບ 10. PRs, ທ່ານຈໍາເປັນຕ້ອງສ້າງໃຫມ່ 55 ເທື່ອ. ແລະນີ້ແມ່ນຢູ່ໃນສະຖານະການທີ່ເຫມາະສົມ, ເມື່ອການກວດສອບທັງຫມົດຜ່ານຄັ້ງທໍາອິດ, ເມື່ອບໍ່ມີໃຜເປີດຄໍາຮ້ອງຂໍດຶງເພີ່ມເຕີມໃນຂະນະທີ່ອາຍແກັສເຫຼົ່ານີ້ກໍາລັງດໍາເນີນການ.

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

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

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

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

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

ກ່ອນທີ່ຈະປະຕິບັດ plugin ນີ້, ພວກເຮົາສະເລ່ຍ 2,7 ການທົບທວນຄືນດໍາເນີນການຕໍ່ຄໍາຮ້ອງຂໍດຶງ. ດ້ວຍ plugin ມີການເປີດຕົວ 3,6. ນີ້ເຫມາະສົມກັບພວກເຮົາ.

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

ມັນໃຊ້ເວລາສອງອາທິດເພື່ອຂຽນສະບັບທໍາອິດຂອງ plugin Bitbucket.

ການກວດສອບໃຫມ່

ໃນຂະນະດຽວກັນ, ທີມງານຂອງພວກເຮົາຍັງສືບຕໍ່ຂະຫຍາຍຕົວ. ເພີ່ມການກວດສອບໃໝ່ແລ້ວ.

ພວກເຮົາຄິດວ່າ: ເປັນຫຍັງຈຶ່ງເຮັດຜິດພາດຖ້າພວກເຂົາສາມາດປ້ອງກັນໄດ້? ແລະນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຂົາປະຕິບັດ ການວິເຄາະລະຫັດສະຖິດ. ພວກເຮົາເລີ່ມຕົ້ນດ້ວຍ lint, ເຊິ່ງລວມຢູ່ໃນ Android SDK. ແຕ່ໃນເວລານັ້ນລາວບໍ່ຮູ້ວິທີການເຮັດວຽກກັບລະຫັດ Kotlin ທັງຫມົດ, ແລະພວກເຮົາມີ 75% ຂອງຄໍາຮ້ອງສະຫມັກທີ່ຂຽນໃນ Kotlin ແລ້ວ. ເພາະສະນັ້ນ, ການກໍ່ສ້າງໃນໄດ້ຖືກເພີ່ມໃສ່ lint Android Studio ກວດສອບ.

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາຕ້ອງເຮັດການບິດເບືອນຫຼາຍຢ່າງ: ເອົາ Android Studio, ຫຸ້ມຫໍ່ມັນຢູ່ໃນ Docker ແລະແລ່ນມັນຢູ່ໃນ CI ດ້ວຍຈໍ virtual, ດັ່ງນັ້ນມັນຄິດວ່າມັນກໍາລັງແລ່ນຢູ່ໃນຄອມພິວເຕີ້ທີ່ແທ້ຈິງ. ແຕ່ມັນເຮັດວຽກ.

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

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

ຫ້ອງທົດລອງ Firebase

ມັນໄດ້ຖືກເລືອກເພາະວ່າ Firebase ເປັນຜະລິດຕະພັນຂອງ Google, ຊຶ່ງຫມາຍຄວາມວ່າມັນຄວນຈະມີຄວາມຫນ້າເຊື່ອຖືແລະບໍ່ຫນ້າຈະຕາຍ. ລາຄາແມ່ນສົມເຫດສົມຜົນ: $5 ຕໍ່ຊົ່ວໂມງຂອງການດໍາເນີນງານຂອງອຸປະກອນທີ່ແທ້ຈິງ, 1 $ ຕໍ່ຊົ່ວໂມງຂອງການດໍາເນີນງານຂອງ emulator.

ມັນໃຊ້ເວລາປະມານສາມອາທິດເພື່ອປະຕິບັດ Firebase Test Lab ເຂົ້າໄປໃນ CI ຂອງພວກເຮົາ.

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

Docker + Python + bash

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

ມັນໃຊ້ເວລາຫ້າອາທິດເພື່ອສ້າງສະພາບແວດລ້ອມການທົດສອບຂອງພວກເຮົາເອງ.

ດັ່ງນັ້ນ, ສໍາລັບທຸກໆຄໍາຮ້ອງຂໍດຶງ, ມີບັນຊີລາຍຊື່ການສະກັດການລວມກັນຢ່າງກວ້າງຂວາງ:

• ARK ປະກອບ;
• ການທົດສອບ Junit;
• ລີ້ນ;
• Android Studio ກວດສອບ;
• ການທົດສອບເຄື່ອງມື;
• ການທົດສອບພາບຫນ້າຈໍ.

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

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

ແນ່ນອນ, ພວກເຮົາຕັດສິນໃຈເລັ່ງການກໍ່ສ້າງທັງຫມົດຂອງພວກເຮົາ.

ໃຫ້ເລັ່ງ

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

ການຖອນການກວດສອບທີ່ໃຊ້ເວລາດົນເກີນໄປ

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

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

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

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

ດັ່ງນັ້ນ, ພວກເຮົາຖືກປະໄວ້ກັບ:

• ARK ປະກອບ;
• ການທົດສອບ Junit;
• ການທົດສອບເຄື່ອງມື.

Gradle remote cache

ໂດຍບໍ່ມີການກວດກາຢ່າງຫນັກ, ທຸກສິ່ງທຸກຢ່າງໄດ້ກາຍເປັນທີ່ດີກວ່າ. ແຕ່ບໍ່ມີຂອບເຂດຈໍາກັດກັບຄວາມສົມບູນແບບ!

ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໄດ້ຖືກແບ່ງອອກເປັນປະມານ 150 ໂມດູນ gradle. Gradle remote cache ປົກກະຕິແລ້ວເຮັດວຽກໄດ້ດີໃນກໍລະນີນີ້, ດັ່ງນັ້ນພວກເຮົາໄດ້ຕັດສິນໃຈທົດລອງໃຊ້ມັນ.

Gradle remote cache ເປັນບໍລິການທີ່ສາມາດສ້າງ cache ສ້າງ artifacts ສໍາລັບແຕ່ລະວຽກໃນແຕ່ລະໂມດູນ. Gradle, ແທນທີ່ຈະລວບລວມລະຫັດຕົວຈິງ, ໃຊ້ HTTP ເພື່ອລົບ cache ຫ່າງໄກສອກຫຼີກແລະຖາມວ່າຜູ້ໃດຜູ້ຫນຶ່ງໄດ້ປະຕິບັດວຽກງານນີ້ແລ້ວ. ຖ້າແມ່ນ, ມັນພຽງແຕ່ດາວໂຫລດຜົນໄດ້ຮັບ.

ການແລ່ນ Gradle remote cache ແມ່ນງ່າຍເພາະວ່າ Gradle ໃຫ້ຮູບພາບ Docker. ພວກເຮົາຈັດການນີ້ໃນສາມຊົ່ວໂມງ.

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

ຂ້າງລຸ່ມນີ້ແມ່ນ cache misses graph.

ໃນຕອນເລີ່ມຕົ້ນ, ອັດຕາສ່ວນຂອງ cache misses ແມ່ນປະມານ 65. ຫຼັງຈາກສາມອາທິດ, ພວກເຮົາຄຸ້ມຄອງການເພີ່ມມູນຄ່ານີ້ເຖິງ 20%. ມັນ​ໄດ້​ຫັນ​ອອກ​ວ່າ​ວຽກ​ງານ​ທີ່​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ Android ເກັບ​ກໍາ​ມີ​ການ​ຂຶ້ນ​ກັບ transitive strange​, ເນື່ອງ​ຈາກ​ວ່າ Gradle ພາດ​ຖານ​ຄວາມ​ຈໍາ​.

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

ການວິເຄາະຜົນກະທົບ

ໃນການຮ້ອງຂໍການດຶງ, ພວກເຮົາເກັບກໍາ git diff ແລະຊອກຫາໂມດູນ Gradle ດັດແກ້.

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

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

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

ມາດ​ຕະ​ການ​ເລັ່ງ​ລັດ​ການ​ກວດ​ກາ​ໄດ້​ຮັບ​ຜົນ​ສຳ​ເລັດ. ຈາກ 45 ນາທີພວກເຮົາຂຶ້ນໄປປະມານ 15. ມັນເປັນເລື່ອງປົກກະຕິທີ່ຈະລໍຖ້າຫນຶ່ງສ່ວນສີ່ຂອງຊົ່ວໂມງສໍາລັບການກໍ່ສ້າງ.

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

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

ຫົກອາທິດໄດ້ໃຊ້ເວລາໃນການຕິຊົມລະອຽດ.

ແຜນການ

ໃຫ້ກ້າວໄປສູ່ປະຫວັດສາດທີ່ຜ່ານມາ. ໂດຍໄດ້ແກ້ໄຂບັນຫາການຕິຊົມ, ພວກເຮົາໄດ້ບັນລຸລະດັບໃຫມ່ - ພວກເຮົາຕັດສິນໃຈສ້າງຟາມ emulator ຂອງພວກເຮົາເອງ. ໃນເວລາທີ່ມີການທົດສອບແລະ emulators ຫຼາຍ, ພວກເຂົາເຈົ້າມີຄວາມຫຍຸ້ງຍາກໃນການຄຸ້ມຄອງ. ດັ່ງນັ້ນ, emulators ຂອງພວກເຮົາທັງຫມົດໄດ້ຍ້າຍໄປ cluster k8s ດ້ວຍການຈັດການຊັບພະຍາກອນທີ່ມີຄວາມຍືດຫຍຸ່ນ.

ນອກຈາກນັ້ນ, ຍັງມີແຜນການອື່ນໆ.

• ກັບຄືນ Lint (ແລະການວິເຄາະສະຖິດອື່ນໆ). ພວກເຮົາເຮັດວຽກຢູ່ໃນທິດທາງນີ້ແລ້ວ.
• ດໍາເນີນການທຸກຢ່າງໃນຕົວບລັອກ PR ການທົດສອບ end-to-end ໃນທຸກລຸ້ນ SDK.

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

ຄໍາແນະນໍາ

ຖ້າຂ້ອຍສາມາດໃຫ້ຄໍາແນະນໍາພຽງແຕ່ຫນຶ່ງອັນ, ມັນຈະເປັນນີ້:

ກະລຸນາລະວັງຕົວຂຽນ shell!

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

ມັນທັງຫມົດເລີ່ມຕົ້ນດ້ວຍ scripts ງ່າຍໆທີ່ແລ່ນຢູ່ໃນເຄື່ອງກໍ່ສ້າງຂອງພວກເຮົາ:

#!/usr/bin/env bash
./gradlew assembleDebug

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

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

ສິ່ງທີ່ສາມາດທົດແທນໄດ້?

• ພາສາສະຄຣິບໃດນຶ່ງ. ຂຽນຫາ Python ຫຼື Kotlin Script ສະດວກກວ່າເພາະວ່າມັນເປັນການຂຽນໂປລແກລມ, ບໍ່ແມ່ນສະຄິບ.
• ຫຼືອະທິບາຍເຫດຜົນການກໍ່ສ້າງທັງຫມົດໃນຮູບແບບ ໜ້າວຽກ gradle ແບບກຳນົດເອງ ສໍາ​ລັບ​ໂຄງ​ການ​ຂອງ​ທ່ານ​.

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

ຄໍາແນະນໍາ #2: ເກັບຮັກສາໂຄງສ້າງພື້ນຖານໃນລະຫັດ.

ມັນສະດວກເມື່ອການຕັ້ງຄ່າການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງບໍ່ໄດ້ຖືກເກັບໄວ້ໃນການໂຕ້ຕອບ UI ຂອງ Jenkins ຫຼື TeamCity, ແລະອື່ນໆ, ແຕ່ໃນຮູບແບບຂອງໄຟລ໌ຂໍ້ຄວາມໂດຍກົງໃນ repository ໂຄງການ. ນີ້ເຮັດໃຫ້ສະບັບພາສາ. ມັນຈະບໍ່ເປັນການຍາກທີ່ຈະ rollback ຫຼືສ້າງລະຫັດໃນສາຂາອື່ນ.

ສະຄຣິບສາມາດຖືກເກັບໄວ້ໃນໂຄງການ. ຈະເຮັດແນວໃດກັບສິ່ງແວດລ້ອມ?

ເຄັດລັບ #3: Docker ສາມາດຊ່ວຍສະພາບແວດລ້ອມໄດ້.

ມັນຈະຊ່ວຍໃຫ້ນັກພັດທະນາ Android ແນ່ນອນ, ແຕ່ຫນ້າເສຍດາຍ, iOS ຍັງບໍ່ທັນມີເທື່ອ.

ນີ້ແມ່ນຕົວຢ່າງຂອງໄຟລ໌ docker ງ່າຍໆທີ່ມີ jdk ແລະ android-sdk:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

ໂດຍໄດ້ຂຽນໄຟລ໌ Docker ນີ້ (ຂ້ອຍຈະບອກຄວາມລັບຂອງເຈົ້າ, ເຈົ້າບໍ່ຈໍາເປັນຕ້ອງຂຽນມັນ, ແຕ່ພຽງແຕ່ດຶງມັນພ້ອມທີ່ຈະເຮັດຈາກ GitHub) ແລະປະກອບຮູບພາບ, ທ່ານຈະໄດ້ຮັບເຄື່ອງ virtual ທີ່ທ່ານສາມາດສ້າງຄໍາຮ້ອງສະຫມັກໄດ້. ແລະດໍາເນີນການທົດສອບ Junit.

ສອງເຫດຜົນຫຼັກທີ່ເຮັດໃຫ້ຄວາມຮູ້ສຶກນີ້ມີຄວາມສາມາດຂະຫຍາຍໄດ້ແລະສາມາດເຮັດຊ້ໍາໄດ້. ການນໍາໃຊ້ docker, ທ່ານສາມາດຍົກສູງເປັນອາຍແກັສຕົວແທນການກໍ່ສ້າງຢ່າງໄວວາທີ່ຈະມີສະພາບແວດລ້ອມຄືກັນກັບທີ່ຜ່ານມາ. ນີ້ເຮັດໃຫ້ຊີວິດຂອງວິສະວະກອນ CI ງ່າຍຂຶ້ນຫຼາຍ. ມັນຂ້ອນຂ້າງງ່າຍທີ່ຈະຍູ້ android-sdk ເຂົ້າໄປໃນ docker, ແຕ່ກັບ emulators ມັນມີຄວາມຫຍຸ້ງຍາກເລັກນ້ອຍ: ທ່ານຈະຕ້ອງເຮັດວຽກຫນັກກວ່າເລັກນ້ອຍ (ຫຼືດາວໂຫລດອັນສໍາເລັດຮູບຈາກ GitHub ອີກເທື່ອຫນຶ່ງ).

ຂໍ້ທີ 4: ຢ່າລືມວ່າການກວດກາບໍ່ໄດ້ເຮັດເພື່ອຜົນປະໂຫຍດຂອງການກວດກາ, ແຕ່ເພື່ອປະຊາຊົນ.

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

ເຄັດ​ລັບ #5​: ຈະ pragmatic ໃນ​ເວ​ລາ​ທີ່​ພັດ​ທະ​ນາ​ການ​ເຊື່ອມ​ໂຍງ​ຢ່າງ​ຕໍ່​ເນື່ອງ​.

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

ຄໍາແນະນໍາ #6: ໃຊ້ເຄື່ອງມືທີ່ເຮັດແລ້ວ.

ມີຫຼາຍບໍລິສັດໃນປັດຈຸບັນທີ່ໃຫ້ບໍລິການ cloud CI.

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

ຄໍາແນະນໍາ #7: ໃນທີມງານຂະຫນາດໃຫຍ່, ການແກ້ໄຂພາຍໃນເຮືອນແມ່ນມີກໍາໄລຫຼາຍກວ່າ.

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

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

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

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

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

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

ປະຕິບັດການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ. ແຕ່ຢູ່ໃນປານກາງ.

ໂດຍວິທີທາງການ, Nikolai Nesterov ບໍ່ພຽງແຕ່ໃຫ້ບົດລາຍງານທີ່ຍິ່ງໃຫຍ່ຂອງຕົນເອງ, ແຕ່ຍັງເປັນສະມາຊິກຂອງຄະນະກໍາມະການໂຄງການ. AppsConf ແລະຊ່ວຍຄົນອື່ນກະກຽມຄໍາເວົ້າທີ່ມີຄວາມຫມາຍສໍາລັບທ່ານ. ຄວາມສົມບູນແລະເປັນປະໂຫຍດຂອງໂຄງການກອງປະຊຸມຕໍ່ໄປສາມາດຖືກປະເມີນໂດຍຫົວຂໍ້ໃນ ຕາຕະລາງ. ແລະສໍາລັບລາຍລະອຽດ, ມາ Infospace ໃນວັນທີ 22-23 ເດືອນເມສາ.

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