ສິດທິພິເສດ, ທີ່ລະບຸໄວ້ລ່ວງໜ້າ
ກ່ອນທີ່ທ່ານຈະສ້າງໂທເຄັນ ພວກເຮົາຈະບອກທ່ານວ່າສິ່ງທີ່ມັນຕ້ອງສາມາດເຮັດໄດ້ ແລະ ຍ້ອນຫຍັງ. ບໍ່ມີຂອບເຂດແບບກວມລວມພຽງຍ້ອນວ່າມັນຂໍໄດ້ງ່າຍກວ່າ, ແລະ ບໍ່ມີການມາພົບເຫັນພາຍຫຼັງວ່າພວກເຮົາຕ້ອງການຫຼາຍກວ່າສິ່ງທີ່ວຽກຕ້ອງການ.
ການຄວບຄຸມແຫຼ່ງຂໍ້ມູນ
ນຳໃຊ້ອອກຈາກບ່ອນເກັບຂໍ້ມູນທີ່ທ່ານໃຊ້ຢູ່ແລ້ວ — ເກົ້າບ່ອນທີ່ຈະວາງມັນ
ເຊື່ອມຕໍ່ບັນຊີ GitHub ຫຼື GitLab ທີ່ທ່ານເຮັດວຽກຢູ່ ແລະ ປັບໃຊ້ໂດຍກົງຈາກ branch: ໄປຍັງ Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ຫຼື AWS Amplify — ຫຼື ໄປຍັງໂຮສຕິ້ງທີ່ມີການຈັດການຂອງພວກເຮົາເອງ, ເຊິ່ງບ່ອນເກັບຂໍ້ມູນ ແລະ ໄຟລ໌ຂອງເວັບໄຊຈະຮັກສາການຊິ້ງກັນໃນທັງສອງທິດທາງ. ທຸກໆການເຊື່ອມຕໍ່ຈະສະແດງສິດທິພິເສດທີ່ມັນຕ້ອງການ, ໄດ້ຮັບການກວດສອບກັບ API ຂອງຜູ້ໃຫ້ບໍລິການກ່ອນທີ່ມັນຈະຖືກບັນທຶກ, ແລະ ຖືກເກັບໄວ້ໃນ Vault. ທ່ານຍັງສາມາດເຂົ້າສູ່ລະບົບດ້ວຍ GitHub ຫຼື GitLab ໄດ້ເຊັ່ນກັນ.
- GitHub + GitLabເຊື່ອມຕໍ່ບັນຊີທີ່ທ່ານມີຢູ່ແລ້ວ
- ເກົ້າປາຍທາງໂຮສແຂບແປດແຫ່ງ, ບວກກັບກອງເຮືອຂອງພວກເຮົາເອງ
- ການຊິ້ງຂໍ້ມູນສອງທາງທຸກເວັບໄຊ, ທຸກແຖວ
- ຈັດເກັບໄວ້ໃນ Vaultກວດສອບແລ້ວເມື່ອປ້ອນເຂົ້າ, ບໍ່ເຄີຍຢູ່ໃນບັນທຶກ
- ໂທເຄັນໄດ້ຮັບການກວດສອບກ່ອນທີ່ຈະຖືກບັນທຶກໂທເຄັນທີ່ມີຂອບເຂດກວ້າງເກີນໄປຈະບໍ່ຖືກນຳໃຊ້ຢ່າງແນ່ນອນ
- ຍູ້ເພື່ອຕິດຕັ້ງກວດສອບລາຍເຊັນແລ້ວ ແລະ ເປັນທາງເລືອກ
- ສາຂາຂອງທ່ານ, ການສ້າງຂອງທ່ານເຜີຍແຜ່ໄດເຣັກໂທຣີ ຫຼື ເອີ້ນໃຊ້ CI ຂອງທ່ານເອງ
- ຕັດການເຊື່ອມຕໍ່ຢ່າງຖືກຕ້ອງພວກເຮົາລຶບຮຸກທີ່ພວກເຮົາສ້າງຂຶ້ນຢ່າງແນ່ນອນ
ເຊື່ອມຕໍ່ຄັ້ງດຽວ, ແລະ ເບິ່ງສິ່ງທີ່ທ່ານກຳລັງເຫັນດີນຳ
ການເຊື່ອມຕໍ່ແມ່ນຂໍ້ມູນປະຈຳຕົວທີ່ທ່ານມອບໃຫ້ຜູ້ອື່ນ. ຂອງພວກເຮົາຈະບອກສິ່ງທີ່ຕ້ອງການກ່ອນທີ່ທ່ານຈະສ້າງມັນ, ພິສູດວ່າມັນເຮັດວຽກໄດ້ກ່ອນທີ່ຈະບັນທຶກມັນ, ແລະ ສາມາດຖອນຄືນໄດ້ຈາກທັງສອງຝ່າຍ.
ກວດສອບກັບຜູ້ໃຫ້ບໍລິການແລ້ວ, ບໍ່ໄດ້ຮັບເອົາໂດຍອີງໃສ່ຄວາມໄວ້ວາງໃຈລ້າໆ
ພວກເຮົາຮຽກໃຊ້ API ຂອງຜູ້ໃຫ້ບໍລິການເອງດ້ວຍໂທເຄັນຂອງທ່ານກ່ອນທີ່ຈະບັນທຶກມັນ. ໂທເຄັນທີ່ບໍ່ຖືກຕ້ອງ, ໝົດອາຍຸ ຫຼື ມີຂອບເຂດທີ່ບໍ່ຖືກຕ້ອງ ຈະຖືກປະຕິເສດຢູ່ທີ່ແບບຟອມ ແທນທີ່ຈະຖືກຍອມຮັບ, ສະແດງວ່າໃຊ້ໄດ້ປົກກະຕິ, ແລ້ວໄປລົ້ມເຫຼວໃນການນຳໃຊ້ຕົວຈິງຄັ້ງທຳອິດ.
ຖືກເກັບໄວ້ໃນ Vault, ແລະ ບໍ່ມີບ່ອນອື່ນ
ບໍ່ແມ່ນຢູ່ໃນໂຄ້ດຂອງພວກເຮົາ, ບໍ່ແມ່ນຢູ່ໃນໄຟລ໌ສະພາບແວດລ້ອມ, ບໍ່ແມ່ນຢູ່ໃນບັນທຶກ ແລະ ບໍ່ແມ່ນຢູ່ໃນແຖວຄຳສັ່ງ. ຖືກແກ້ໄຂໃນເວລາທີ່ມັນຖືກນຳໃຊ້, ໂດຍວຽກງານທີ່ໃຊ້ມັນ.
ຫຼາຍກວ່າໜຶ່ງບັນຊີ, ເລືອກຕໍ່ເວັບໄຊ
ເຊື່ອມຕໍ່ບັນຊີສ່ວນຕົວ ແລະ ບັນຊີຂອງອົງກອນ, ຫຼື ສອງອົງກອນ. ແຕ່ລະເວັບໄຊຈະເລືອກວ່າຈະນຳໃຊ້ມາຈາກອັນໃດ, ດັ່ງນັ້ນບ່ອນເກັບຂໍ້ມູນຂອງລູກຄ້າ ແລະ ຂອງທ່ານເອງຈະບໍ່ມີການແບ່ງປັນຂໍ້ມູນປະຈຳຕົວຮ່ວມກັນເລີຍ.
ເກົ້າສະຖານທີ່ທີ່ບ່ອນເກັບຂໍ້ມູນສາມາດໄປຮອດໄດ້
ໂຮສຕ໌ຂອບທີ່ໄດ້ຮັບການຈັດການແປດແຫ່ງ ແລະ ກອງເຮືອຂອງພວກເຮົາເອງ. ຈຸດໝາຍປາຍທາງແມ່ນຄຸນສົມບັດຂອງເວັບໄຊ, ບໍ່ແມ່ນຂອງການເຊື່ອມຕໍ່, ດັ່ງນັ້ນບ່ອນເກັບຂໍ້ມູນດຽວກັນສາມາດເຜີຍແຜ່ສາຂາໜຶ່ງໄປຍັງໂຮສຕ໌ Pages ແລະ ອີກເວັບໄຊໜຶ່ງສາມາດເຮັດວຽກເທິງຮາດແວຂອງພວກເຮົາໄດ້.
Cloudflare Pages
ແບນວິດບໍ່ຈຳກັດ, ອະນຸຍາດໃຫ້ນຳໃຊ້ໃນທາງການຄ້າ, ແລະ ໂດເມນ apex ຖືກຈັດການຢູ່ໃນຜູ້ໃຫ້ບໍລິການດຽວກັນທີ່ມັກຈະຮອງຮັບໂຊນ DNS ຂອງທ່ານ. ມັນເປັນຈຸດໝາຍປາຍທາງທຳອິດທີ່ພວກເຮົາເລືອກໃຊ້ຍ້ອນເຫດຜົນເຫຼົ່ານັ້ນ.
ການໂຮສ Cloudflare Pages →GitHub Pages
ເຜີຍແຜ່ໂດຍກົງຈາກບ່ອນເກັບຂໍ້ມູນທີ່ໂຄດມີຢູ່ແລ້ວ. ຖືກໝາຍໄວ້ໃນແຖວ Footprint-Free, ເນື່ອງຈາກໂຄງສ້າງພື້ນຖານ github.io ທີ່ໃຊ້ຮ່ວມກັນນັ້ນເປັນຮ່ອງຮອຍດ້ວຍຕົວມັນເອງ.
ໂຮສຕິ້ງ GitHub Pages →GitLab Pages, Netlify, Vercel ແລະ ອື່ນໆ
GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ແລະ AWS Amplify ແມ່ນປາຍທາງທັງໝົດທີ່ທ່ານສາມາດຊີ້ເວັບໄຊໄປຫາໄດ້, ດ້ວຍການເຊື່ອມຕໍ່ດຽວກັນ ແລະ ປະຫວັດການນຳໃຊ້ອັນດຽວກັນ.
ບໍລິການໂຮສຕິ້ງເວັບໄຊຄົງທີ່ →ໂຮດຕິ້ງທີ່ມີການຈັດການຂອງພວກເຮົາເອງ
ແອັບພລິເຄຊັນທີ່ສົມບູນ ແທນທີ່ຈະເປັນຊຸດທີ່ສ້າງຂຶ້ນ — WordPress, PHP, Node. ນີ້ແມ່ນປາຍທາງທີ່ໄດ້ຮັບການຊິ້ງແບບສອງທາງ, ດັ່ງນັ້ນໄຟລ໌ຢູ່ໃນກ່ອງ ແລະ ສາຂາຈຶ່ງຄົງຄວາມກົງກັນຢູ່ສະເໝີ.
ໂຮສຕິ້ງທີ່ມີການຈັດການ →ເວັບໄຊຢູ່ໃນຂອບເຄືອຂ່າຍຂອງຄົນອື່ນ
ເວັບໄຊທີ່ຖືກເຜີຍແຜ່ໄປຍັງໂຮສທີ່ພວກເຮົາບໍ່ໄດ້ເປັນເຈົ້າຂອງ ຍັງຄົງໃຊ້ໂຄຕ້າ ແລະ ຍັງຄົງປະກົດຢູ່ໃນແຜງຄວບຄຸມຂອງທ່ານ ພ້ອມກັບການນຳໃຊ້, ເວລາເຮັດວຽກ ແລະ ຂໍ້ມູນ SEO ຂອງມັນ ຢູ່ຄຽງຂ້າງກັບສິ່ງອື່ນໆທັງໝົດທີ່ທ່ານດຳເນີນການ.
ໂຄຕ້າເວັບໄຊພາຍນອກ →ຫຼື ແກ້ໄຂມັນຢູ່ນີ້
ຕົວແກ້ໄຂໃນໂປຣແກຣມທ່ອງເວັບເຮັດວຽກກັບໄຟລ໌ດຽວກັນທີ່ການຊິງຄ໌ສອງທາງສົ່ງກັບຄືນ, ດັ່ງນັ້ນການແກ້ໄຂດ່ວນຈາກໜ້າປັດຈຶ່ງກາຍເປັນ commit ໃນສາຂາຂອງທ່ານ ແທນທີ່ຈະເປັນການປ່ຽນແປງທີ່ບໍ່ມີໃຜສາມາດຊອກຫາໄດ້ໃນພາຍຫຼັງ.
ຕົວແກ້ໄຂເວັບ →ການຊິງແບບສອງທາງ
ບ່ອນເກັບຂໍ້ມູນຂອງທ່ານ ແລະ ເວັບໄຊສົດຂອງທ່ານ, ໄປພ້ອມໆກັນ
ເປີດໃຊ້ມັນ ແລ້ວໄຟລ໌ຂອງເວັບໄຊເອງຈະຖືກ commit ກັບຄືນໄປຍັງ branch ຂອງທ່ານ, ໃນຂະນະທີ່ບັນດາ commit ໃນ branch ນັ້ນຈະຖືກສົ່ງກັບມາຍັງເວັບໄຊ. ມັນໃຊ້ໄດ້ກັບທຸກໆເວັບໄຊທີ່ພວກເຮົາ host, ໃນທຸກແພັກເກດ — ຂໍ້ກຳນົດພຽງຢ່າງດຽວແມ່ນເຄື່ອງເຊີບເວີທີ່ຢູ່ເບື້ອງຫຼັງສາມາດ run Git ກັບບັນດາໄຟລ໌ຂອງມັນໄດ້, ເຊິ່ງເປັນການສອບຖາມຈາກເຊີບເວີໂດຍກົງ ຫຼາຍກວ່າການຄາດເດົາເອົາຈາກແພັກເກດ.
ທ່ານເປັນຜູ້ເລືອກວ່າຈະຊິ້ງຄ໌ໄດເຣັກທໍຣີໃດ ເນື່ອງຈາກລູກຄ້າ WordPress ຕ້ອງການໃຫ້ຕິດຕາມທິມຂອງພວກເຂົາ ບໍ່ແມ່ນໄຟລ໌ຫຼັກສີ່ໝື່ນໄຟລ໌. ແລະ ມັນຈະຖືກປິດໄວ້ຈົນກວ່າທ່ານຈະເປີດມັນ: ການເປີດໃຊ້ການຊິ້ງຄ໌ແມ່ນການຕັດສິນໃຈກ່ຽວກັບບ່ອນເກັບຂໍ້ມູນຂອງຜູ້ອື່ນ, ແລະ ການຍ້າຍຂໍ້ມູນຈະຕ້ອງບໍ່ຕັດສິນໃຈແທນທ່ານຢ່າງເດັດຂາດ.
- ການແກ້ໄຂເທິງຮາດແວຂອງພວກເຮົາຈະກາຍເປັນ commit ໃນສາຂາຂອງທ່ານ
- ການ commit ໃນ branch ຂອງທ່ານຈະກັບຄືນມາຍັງເວັບໄຊ
- ຊິ້ງຂໍ້ມູນພຽງໜຶ່ງໄດເຣັກທໍຣີ — ຮູບແບບ, ປລັກອິນ — ບໍ່ແມ່ນຮາກເອກະສານທັງໝົດ
- ປິດໄວ້ໂດຍຄ່າເລີ່ມຕົ້ນ, ລວມທັງໃນທຸກໆເວັບໄຊທີ່ມີຢູ່ແລ້ວ
ເຜີຍແຜ່ໄດເຣັກທໍຣີ, ຫຼື ໃຫ້ CI ຂອງທ່ານສ້າງມັນເອງ
ສອງໂໝດ, ແລະ ຄວາມແຕກຕ່າງແມ່ນບ່ອນທີ່ການ build ເຮັດວຽກ. ທັງສອງສິ້ນສຸດຢູ່ບ່ອນດຽວກັນ: ref ທີ່ພວກເຮົາດຶງມາ ແລະ ເຜີຍແຜ່, ໂດຍມີ commit ຖືກບັນທຶກໄວ້ກັບການ deploy.
- ໂໝດເຜີຍແຜ່ຈະດຶງເອົາສາຂາຂອງທ່ານຕາມສະພາບຕົວຈິງ ແລະ ເຜີຍແຜ່ໄດເຣັກທໍຣີທີ່ທ່ານລະບຸ — ຫວ່າງເປົ່າໝາຍເຖິງຮາກຂອງບ່ອນເກັບຂໍ້ມູນ.
- ໂໝດ CI ດຳເນີນການຄຳສັ່ງສ້າງຂອງທ່ານໃນໄປຯລາຍຂອງຜູ້ໃຫ້ບໍລິການຂອງທ່ານເອງ ແລະ ຄອມມິດຜົນໄດ້ຮັບໄປຍັງສາຂາການເຜີຍແຜ່ແຍກຕ່າງຫາກ, ເຊິ່ງພວກເຮົາຈະດຶງຂໍ້ມູນຄືກັບການອ້າງອີງອື່ນໆ.
- ສາຂາທີ່ການນຳໃຊ້ອອກເຜີຍແຜ່ແມ່ນຖືກລະບຸຊື່ຢ່າງຈະແຈ້ງສະເໝີ, ບໍ່ເຄີຍເປັນ "ສາຂາມາດຕະຖານ" — ຄ່າມາດຕະຖານສາມາດປ່ຽນແປງໄດ້ໂດຍທີ່ທ່ານບໍ່ຮູ້ຕົວ, ແລະ ປະຫວັດທີ່ບໍ່ສາມາດບອກໄດ້ວ່າມັນໄດ້ເຜີຍແຜ່ສາຂາໃດນັ້ນບໍ່ແມ່ນປະຫວັດ.
- ການນຳໃຊ້ໂດຍອັດຕະໂນມັດແມ່ນເປີດໄວ້ເປັນຄ່າເລີ່ມຕົ້ນ ແລະ ສາມາດປິດໄດ້ໂດຍບໍ່ຕ້ອງລຶບ webhook ອອກ, ດັ່ງນັ້ນທ່ານຈຶ່ງສາມາດຕິດຕາມການມາຮອດຂອງການຈັດສົ່ງໄດ້ ກ່ອນທີ່ທ່ານຈະອະນຸຍາດໃຫ້ພວກມັນດຳເນີນການ.
- ທຸກໆການນຳໃຊ້ມັນຈະບັນທຶກ commit, ຜົນໄດ້ຮັບ ແລະ ເວລາຂອງມັນ, ແລະ ເຮັດວຽກຢູ່ໃນພື້ນຫຼັງ — ໜ້າເວັບຈະອັບເດດເມື່ອການສ້າງສຳເລັດ.
- ການຕັດການເຊື່ອມຕໍ່ຈະລຶບສະເພາະ webhook ທີ່ພວກເຮົາໄດ້ສ້າງຂຶ້ນ ຕາມ id ຂອງມັນເທົ່ານັ້ນ ແລະ ຈະບໍ່ລຶບສິ່ງອື່ນໃດໃນບ່ອນເກັບຂໍ້ມູນຂອງທ່ານ.
ຈາກບ່ອນເກັບຂໍ້ມູນໄປສູ່ເວັບໄຊຕົວຈິງ
ເຊື່ອມຕໍ່ບັນຊີ
GitHub ຫຼື GitLab, ພາຍໃຕ້ການເຊື່ອມຕໍ່. ສິດທິພິເສດແມ່ນໄດ້ຖືກລະບຸໄວ້ກ່ອນທີ່ທ່ານຈະສ້າງໂທເຄັນ ແລະ ມັນຈະຖືກກວດສອບກັບຜູ້ໃຫ້ບໍລິການກ່ອນທີ່ມັນຈະຖືກເກັບໄວ້.
ຊີ້ເວັບໄຊໄປຍັງບ່ອນເກັບຂໍ້ມູນ
ເຈົ້າຂອງ, ຄັງເກັບ (repository), ສາຂາ (branch), ແລະ ບໍ່ວ່າພວກເຮົາຈະເຜີຍແຜ່ໄດເຣັກທໍຣີ ຫຼື ດຶງຂໍ້ມູນສິ່ງທີ່ CI ຂອງທ່ານສ້າງຂຶ້ນ. ພວກເຮົາລົງທະບຽນ push webhook ເປັນສ່ວນໜຶ່ງຂອງມັນ.
ຍູ້, ຫຼື ກົດປຸ່ມ
ການ push ໄປຍັງ branch ທີ່ກຳນົດຈະເລີ່ມຕົ້ນການ deploy, ຫຼື ທ່ານສາມາດ deploy ຕາມຄວາມຕ້ອງການໄດ້ຈາກແຖບ Deploy ຂອງເວັບໄຊ. ການ build ຈະດຳເນີນການຢູ່ໃນພື້ນຫຼັງ.
ເບິ່ງມັນ, ແລະ ຊິ້ງຂໍ້ມູນກັບຄືນຖ້າທ່ານຕ້ອງການ
ປະຫວັດການນຳໃຊ້ສະແດງສິ່ງທີ່ໄດ້ເຜີຍແຜ່ ແລະ ເວລາໃດ. ເປີດການຊິ້ງແບບສອງທາງ ແລ້ວການແກ້ໄຂທີ່ທ່ານເຮັດຢູ່ນີ້ຈະກັບມາເປັນ commits ໃນ branch ຂອງທ່ານ.
ເມື່ອມີບາງຢ່າງຜິດພາດ
"ເຊື່ອມຕໍ່ແລ້ວແຕ່ບໍ່ເຄີຍຈັດສົ່ງ" ແມ່ນສະຖານະທີ່ພວກເຮົາຈະແຈ້ງໃຫ້ທ່ານຊາບຢ່າງແທ້ຈິງ
ການເຊື່ອມຕໍ່ບ່ອນເກັບຂໍ້ມູນທີ່ເບິ່ງຄືວ່າປົກກະຕິດີແຕ່ບໍ່ໄດ້ຮັບຫຍັງເລີຍ ແມ່ນຄວາມຜິດພາດແບບມິດງຽບທົ່ວໄປ — ໂທເຄັນທີ່ມີຂອບເຂດບໍ່ຖືກຕ້ອງ, ການຈັດສົ່ງທີ່ຖືກບລັອກຢູ່ຜູ້ໃຫ້ບໍລິການ, ຫຼື ຮຸກທີ່ຜູ້ໃດຜູ້ນຶ່ງລຶບອອກດ້ວຍຕົນເອງ. ມັນບໍ່ສາມາດເບິ່ງເຫັນໄດ້ໃນໜ້າຈໍອື່ນໆ, ດັ່ງນັ້ນບັດບ່ອນເກັບຂໍ້ມູນຈຶ່ງສະແດງມັນໂດຍກົງ: ເວລາທີ່ຜູ້ໃຫ້ບໍລິການສົ່ງໃຫ້ພວກເຮົາຄັ້ງຫຼ້າສຸດ, ແລະ ສິ່ງທີ່ມັນໄດ້ແຈ້ງໄວ້.
ການຈັດສົ່ງຈະຖືກກວດສອບລາຍເຊັນກ່ອນທີ່ພວກເຮົາຈະດຳເນີນການ, ໂດຍໃຊ້ຮູບແບບສະເພາະຂອງແຕ່ລະຜູ້ໃຫ້ບໍລິການ ແທນທີ່ຈະເປັນຮູບແບບທີ່ພວກເຮົາສົມມຸດວ່ານຳໃຊ້ກັບທັງໝົດ. ການຈັດສົ່ງທີ່ບໍ່ໄດ້ຮັບການຢືນຢັນຈະຖືກປະຕິເສດ ແລະ ບັນທຶກໄວ້, ບໍ່ແມ່ນຖືກລະເລີຍໄປແບບງຽບໆ.
- ເວລາ ແລະ ຂໍ້ຄວາມການຈັດສົ່ງຄັ້ງຫຼ້າສຸດ, ໃນບັດ
- ລະບຸວ່າ "ບໍ່ເຄີຍຈັດສົ່ງ", ບໍ່ໄດ້ປະຫວ່າງໄວ້
- ລາຍເຊັນໄດ້ຮັບການກວດສອບຕາມແຕ່ລະຜູ້ໃຫ້ບໍລິການກ່ອນທີ່ຈະມີການດຳເນີນການໃດໆ
- ຮຸກທີ່ພວກເຮົາສ້າງຂຶ້ນຈະຖືກລຶບອອກໂດຍໄອດີເມື່ອທ່ານຕັດການເຊື່ອມຕໍ່
ຕົວຕົນ
ເຂົ້າສູ່ລະບົບດ້ວຍ GitHub ຫຼື GitLab — ຫຼື Google, ຫຼື Microsoft
ຄຽງຄູ່ກັບທີ່ຢູ່ອີເມວ ແລະ ລະຫັດຜ່ານ, ທ່ານສາມາດເຂົ້າສູ່ລະບົບບັນຊີ Zinn Digital® ຂອງທ່ານດ້ວຍ GitHub, GitLab, Google ຫຼື Microsoft. ຊັ້ນລະບຸຕົວຕົນຈະດຳເນີນການແຮນເຊກ (handshake); ພວກເຮົາຈະບໍ່ເຫັນລະຫັດຜ່ານຜູ້ໃຫ້ບໍລິການຂອງທ່ານເລີຍ, ແລະ ການເຊື່ອມໂຍງບັນຊີສື່ສັງຄົມກັບບັນຊີ Zinn® ທີ່ມີຢູ່ແລ້ວຍັງຄົງຕ້ອງໄດ້ຮັບການຢືນຢັນຜ່ານທາງອີເມວ.
ການເຂົ້າສູ່ລະບົບດ້ວຍ GitHub ແລະ ການເຊື່ອມຕໍ່ GitHub ສຳລັບການນຳໃຊ້ ແມ່ນການຕັດສິນໃຈແຍກຕ່າງຫາກ ແລະ ຂໍ້ມູນປະຈຳຕົວແຍກຕ່າງຫາກ. ການເຮັດອັນໜຶ່ງບໍ່ໄດ້ເຮັດໃຫ້ເກີດອີກອັນໜຶ່ງ, ແລະ ການລຶບອັນໜຶ່ງອອກກໍບໍ່ໄດ້ລຶບອີກອັນໜຶ່ງອອກ.
- ເຂົ້າສູ່ລະບົບດ້ວຍ GitHub, GitLab, Google ແລະ Microsoft
- ລະຫັດຜ່ານ ແລະ ການຢືນຢັນຕົວຕົນສອງຊັ້ນໃນບັນຊີດຽວກັນ
- ຂໍ້ມູນປະຈຳຕົວສຳລັບການເຂົ້າສູ່ລະບົບ ແລະ ການນຳໃຊ້ມັນແຍກຕ່າງຫາກ
ຄຳຖາມທີ່ຖາມເລື້ອຍໆ
ຂ້ອຍສາມາດເຊື່ອມຕໍ່ກັບຜູ້ໃຫ້ບໍລິການຄວບຄຸມເວີຊັນໃດແດ່?
GitHub ແລະ GitLab. ເຊື່ອມຕໍ່ບັນຊີທີ່ທ່ານເຮັດວຽກຢູ່ແລ້ວ ແລະ ພວກເຮົາສາມາດນຳໃຊ້ມັນຈາກບ່ອນເກັບຂໍ້ມູນຂອງມັນ, ລົງທະບຽນ push webhook ໃສ່ພວກມັນ, ແລະ — ຖ້າທ່ານຕ້ອງການ — ຊິ້ງໄຟລ໌ເວັບໄຊຂອງທ່ານກັບຄືນໄປອີກທາງໜຶ່ງ. ທັງສອງແມ່ນຜ່ານຮອຍຕໍ່ບັນຊີທີ່ເຊື່ອມຕໍ່ດຽວກັນ, ດັ່ງນັ້ນທຸກຢ່າງຂ້າງລຸ່ມນີ້ແມ່ນໃຊ້ໄດ້ກັບທັງສອງ.
ຂ້ອຍສາມາດເຂົ້າສູ່ລະບົບດ້ວຍ GitHub ຫຼື GitLab ໄດ້ບໍ?
ແມ່ນແລ້ວ, ແລະ ດ້ວຍ Google ຫຼື Microsoft ເຊັ່ນກັນ. ນອກເໜືອໄປຈາກທີ່ຢູ່ອີເມວ ແລະ ລະຫັດຜ່ານແລ້ວ ທ່ານສາມາດເຂົ້າສູ່ລະບົບບັນຊີ Zinn Digital® ຂອງທ່ານດ້ວຍອັນໃດກໍໄດ້ໃນສີ່ຢ່າງນີ້. ຊັ້ນຂໍ້ມູນປະຈຳຕົວຈະຈັດການການເຊື່ອມຕໍ່ (handshake) ແລະ ພວກເຮົາຈະບໍ່ເຫັນລະຫັດຜ່ານຜູ້ໃຫ້ບໍລິການຂອງທ່ານຢ່າງເດັດຂາດ. ການເຂົ້າສູ່ລະບົບດ້ວຍ GitHub ແມ່ນຄົນລະຢ່າງກັບການເຊື່ອມຕໍ່ GitHub ສຳລັບການ deploy — ທ່ານສາມາດເລືອກເຮັດອັນໃດອັນໜຶ່ງ, ເຮັດທັງສອງ, ຫຼື ບໍ່ເຮັດທັງສອງກໍໄດ້.
ຂ້ອຍສາມາດນຳໃຊ້ບ່ອນເກັບຂໍ້ມູນໄດ້ຢູ່ໃສ?
ໄປທີ່ Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ຫຼື AWS Amplify ສໍາລັບເວັບໄຊສະແຕຕິກ ຫຼື ເວັບໄຊທີ່ສ້າງຂຶ້ນ — ຫຼື ໄປຍັງໂຮດຕິ້ງທີ່ມີການຈັດການຂອງພວກເຮົາເອງ ບ່ອນທີ່ບ່ອນເກັບໂຄ້ດ ແລະ ໄຟລ໌ຂອງເວັບໄຊຈະຮັກສາການຊິ້ງຄ໌ກັນທັງສອງທິດທາງ. ທ່ານສາມາດເລືອກປາຍທາງສໍາລັບເວັບໄຊໄດ້ດ້ວຍຕົນເອງ; ການເຊື່ອມຕໍ່ບ່ອນເກັບໂຄ້ດແມ່ນຄືກັນໃນທຸກກໍລະນີ.
ທ່ານສາມາດສ້າງເວັບໄຊໃຫ້ຂ້ອຍໄດ້ບໍ, ຫຼື ວ່າມັນຕ້ອງຖືກສ້າງໄວ້ລ່ວງໜ້າແລ້ວ?
ອັນໃດກໍໄດ້. ໃນໂໝດເຜີຍແຜ່ ພວກເຮົາຈະໃຊ້ branch ຕາມສະພາບຕົວຈິງ ແລະ ເຜີຍແຜ່ໄດເຣັກທໍຣີທີ່ທ່ານລະບຸ. ໃນໂໝດ CI ໄປPipeline ຂອງຜູ້ໃຫ້ບໍລິການຂອງທ່ານເອງຈະດຳເນີນການຄຳສັ່ງ build ຂອງທ່ານ ແລະ commit ຜົນການເຮັດວຽກໄປຍັງ branch ເຜີຍແຜ່ແຍກຕ່າງຫາກ, ເຊິ່ງຈາກນັ້ນພວກເຮົາຈະດຶງຂໍ້ມູນຄືກັບ ref ອື່ນໆ. ຕົວເລືອກທີສອງຈະຮັກສາການ build ຂອງທ່ານໄວ້ໃນ CI ຂອງທ່ານເອງ, ບ່ອນທີ່ມີຂໍ້ມູນລັບ ແລະ ການແຄຊຂອງທ່ານຢູ່ແລ້ວ.
ການ push ຈະຖືກນຳໃຊ້ອັດຕະໂນມັດບໍ່?
ຕາມຄ່າເລີ່ມຕົ້ນ, ແມ່ນແລ້ວ — ພວກເຮົາຈະລົງທະບຽນ webhook ຢູ່ບ່ອນເກັບຂໍ້ມູນ ແລະ ການ push ໄປຍັງສາຂາທີ່ທ່ານລະບຸໄວ້ຈະເລີ່ມການປັບໃຊ້. ທ່ານສາມາດປິດຄຸນສົມບັດນັ້ນ ແລະ ຮັກສາ webhook ໄວ້ໄດ້, ເຊິ່ງມີປະໂຫຍດຫຼາຍກວ່າທີ່ຄິດ: ການຈັດສົ່ງຍັງຖືກບັນທຶກໄວ້, ດັ່ງນັ້ນ ທ່ານຈຶ່ງສາມາດຕິດຕາມການ push ຂອງທ່ານທີ່ເຂົ້າມາກ່ອນທີ່ທ່ານຈະອະນຸຍາດໃຫ້ພວກເຮົາດຳເນີນການຕໍ່ພວກມັນ.
ການຊິ້ງສອງທາງແມ່ນຫຍັງ?
ການແກ້ໄຂທີ່ເຮັດຢູ່ໃນຮາດແວຂອງພວກເຮົາຈະກາຍເປັນ commit ໃນ branch ຂອງທ່ານ, ແລະ commit ໃນ branch ຂອງທ່ານຈະກັບມາຫາເວັບໄຊ. ມັນຈະຖືກປິດໄວ້ຈົນກວ່າທ່ານຈະເປີດມັນ, ເພາະວ່າການເປີດມັນແມ່ນການຕັດສິນໃຈກ່ຽວກັບ repository ຂອງຄົນອື່ນ ແລະ ພວກເຮົາຈະບໍ່ຕັດສິນໃຈແທນທ່ານ. ທ່ານສາມາດເລືອກໄດເຣັກໂທຣີທີ່ຈະ sync ໄດ້ດ້ວຍຕົນເອງ — ໂດຍປົກກະຕິແລ້ວແມ່ນ theme ຫຼື plugin, ບໍ່ແມ່ນໄຟລ໌ຫຼັກສີ່ໝື່ນໄຟລ໌ຂອງ WordPress.
ຈະເກີດຫຍັງຂຶ້ນຫາກທັງສອງຝ່າຍມີການປ່ຽນແປງ?
ບໍ່ມີຫຍັງຖືກຂຽນທັບ ແລະ ບໍ່ມີຫຍັງຖືກ push. ການຊິງຄ໌ຈະຢຸດລົງ, ແຈ້ງໃຫ້ທ່ານຊາບວ່າ branch ໄດ້ຍ້າຍກາຍ commit ທີ່ພວກເຮົາໄດ້ອີງໃສ່, ແລະ ຖາມວ່າທ່ານຕ້ອງການຝັ່ງໃດ — ຮັກສາ repository ໄວ້, ຫຼື ຮັກສາເວັບໄຊທ໌ໄວ້. ເວັບໄຊທ໌ທີ່ບໍ່ເຄີຍຊິງຄ໌ມາກ່ອນ ແລະ ຊີ້ໄປຍັງ branch ທີ່ມີ commit ຢູ່ແລ້ວ ກໍຖືເປັນສະຖານະສະເພາະຂອງມັນເຊັ່ນກັນ, ແລະ ມັນຈະຖາມແທນທີ່ຈະຄາດເດົາວ່າອັນໃດຄືຄວາມຈິງ.
ໂທເຄັນການເຂົ້າເຖິງຂອງຂ້ອຍຖືກປົກປ້ອງແນວໃດ?
ພວກເຮົາສະແດງໃຫ້ທ່ານເຫັນສິດທິພິເສດທີ່ການເຊື່ອມຕໍ່ຕ້ອງການ ກ່ອນທີ່ທ່ານຈະສ້າງມັນ, ກວດສອບໂທເຄັນກັບ API ຂອງຜູ້ໃຫ້ບໍລິການເອງເມື່ອປ້ອນເຂົ້າ — ດັ່ງນັ້ນ ໂທເຄັນທີ່ບໍ່ຖືກຕ້ອງ ຫຼື ມີຂອບເຂດບໍ່ຖືກຕ້ອງ ຈະບໍ່ຖືກບັນທຶກໄວ້ເລີຍ — ແລະ ຫຼັງຈາກນັ້ນຈຶ່ງຂຽນມັນລົງໃນ Vault. ມັນບໍ່ເຄີຍແຕະຕ້ອງລະຫັດ, ບັນທຶກ, ໄຟລ໌ສະພາບແວດລ້ອມ ຫຼື ຄຳສັ່ງຂອງພວກເຮົາເລີຍ. ຖອນສິດມັນຢູ່ຜູ້ໃຫ້ບໍລິການ ຫຼື ລຶບການເຊື່ອມຕໍ່ຢູ່ທີ່ນີ້ ເມື່ອໃດກໍໄດ້ຕາມທີ່ທ່ານຕ້ອງການ.
ຂ້າພະເຈົ້າຈະຮູ້ໄດ້ແນວໃດວ່າທ່ານກຳລັງໄດ້ຮັບ push ຂອງຂ້າພະເຈົ້າແທ້ຫຼືບໍ່?
ບັດບ່ອນເກັບຂໍ້ມູນສະແດງໃຫ້ເຫັນວ່າຜູ້ໃຫ້ບໍລິການໄດ້ສົ່ງຂໍ້ມູນໃຫ້ພວກເຮົາຄັ້ງຫຼ້າສຸດເມື່ອໃດ ແລະ ໄດ້ແຈ້ງຫຍັງແດ່. "ບໍ່ເຄີຍສົ່ງມາກ່ອນ" ແມ່ນການວິນິດໄສທີ່ມີປະໂຫຍດຫຼາຍທີ່ສຸດໃນໜ້າຈໍນັ້ນ, ຍ້ອນວ່າ "ເຊື່ອມຕໍ່ແລ້ວແຕ່ບໍ່ເຄີຍສົ່ງມາກ່ອນ" ແມ່ນສິ່ງທີ່ສະແດງອອກຢ່າງຊັດເຈນເມື່ອໂທເຄັນຖືກກຳນົດຂອບເຂດຜິດ ຫຼື ການສົ່ງຖືກບລັອກ — ແລະ ມັນຈະບໍ່ສະແດງຢູ່ບ່ອນອື່ນເລີຍ. ທຸກໆການສົ່ງຈະໄດ້ຮັບການກວດສອບລາຍເຊັນກ່ອນທີ່ພວກເຮົາຈະດຳເນີນການ.
ຂ້ອຍສາມາດໃຊ້ການນຳໃຊ້ Pages ໃນສາຍ Footprint-Free ໄດ້ບໍ່?
ມັນຖືກສະເໜີໃຫ້ ແລະ ຖືກໝາຍໄວ້. GitHub Pages ແລະ GitLab Pages ໃຊ້ໂຄງສ້າງພື້ນຖານຂອງຜູ້ໃຫ້ບໍລິການຮ່ວມກັນ ແລະ ຊື່ໂຮສສາທາລະນະ github.io ແລະ gitlab.io, ແລະ ນັ້ນຄືຮ່ອງຮອຍ (footprint) — ສິ່ງດຽວທີ່ແຖວນັ້ນມີໄວ້ເພື່ອຫຼີກລ່ຽງ. ສຳລັບເຄືອຂ່າຍທີ່ບໍ່ມີຮ່ອງຮອຍ (zero-footprint), ໃຫ້ຕິດຕັ້ງໃສ່ໂຮສຕິ້ງທີ່ແຍກຕ່າງຫາກແທນ. ສ່ວນບ່ອນອື່ນໆທັງໝົດ, Pages ແມ່ນດີເລີດລະດັບໜຶ່ງ.
ເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງເລືອກ Vercel ຢ່າງຈະແຈ້ງ?
ເນື່ອງຈາກແພັກເກດຟຣີຂອງມັນໄດ້ຮັບອະນຸຍາດສຳລັບການນຳໃຊ້ທີ່ບໍ່ແມ່ນທາງການຄ້າເທົ່ານັ້ນ. ພວກເຮົາຄາດຄະເນປາຍທາງຈາກບັນຊີທີ່ທ່ານໄດ້ເຊື່ອມຕໍ່ໃນບ່ອນທີ່ປອດໄພ, ແລະ Vercel ຖືກຍົກເວັ້ນໂດຍເຈດຕະນາຈາກການຄາດຄະເນນັ້ນ — ການເຊື່ອມຕໍ່ບັນຊີຕ້ອງບໍ່ເຮັດໃຫ້ເວັບໄຊທາງການຄ້າໄປຢູ່ບ່ອນທີ່ໃບອະນຸຍາດບໍ່ອະນຸຍາດໂດຍບໍ່ຮູ້ຕົວ. ເລືອກມັນ ແລະ ມັນຈະເຮັດວຽກຄືກັນກັບອັນອື່ນຢ່າງແນ່ນອນ.
ຂ້ອຍສາມາດເບິ່ງໄດ້ບໍວ່າສິ່ງໃດຖືກນຳໃຊ້ ແລະ ເມື່ອໃດ?
ແມ່ນແລ້ວ. ທຸກໆການນຳໃຊ້ຈະບັນທຶກ commit ທີ່ໄດ້ເຜີຍແຜ່, ເວລາທີ່ມັນເຮັດວຽກ ແລະ ວິທີທີ່ມັນສິ້ນສຸດລົງ, ແລະ ແຖບການນຳໃຊ້ຂອງເວັບໄຊຈະສະແດງປະຫວັດພ້ອມກັບ URL ທີ່ໃຊ້ງານຢູ່ຂ້າງໆ. ການນຳໃຊ້ຈະເຮັດວຽກຢູ່ເບື້ອງຫຼັງ, ດັ່ງນັ້ນໜ້າເວັບຈະອັບເດດເມື່ອການສ້າງສຳເລັດ ແທນທີ່ຈະໃຫ້ທ່ານລໍຖ້າຢູ່ໜ້າສັນຍາລັກໂຫຼດໝູນວຽນ.
ກ່ຽວຂ້ອງ
ນຳໃຊ້ຈາກບ່ອນເກັບຂໍ້ມູນຂອງທ່ານ
ເລີ່ມຕົ້ນການທົດລອງໃຊ້ 14 ມື້ໂດຍບໍ່ຕ້ອງໃຊ້ບັດ, ເຊື່ອມຕໍ່ GitHub ຫຼື GitLab, ແລະ ຊີ້ເວັບໄຊໄປຍັງສາຂາ (branch). ເຜີຍແຜ່ໄປຍັງ edge host, ຫຼື ໃສ່ໂຮສຕິ້ງຂອງພວກເຮົາເອງໂດຍມີການຊິ້ງຄ໌ໄຟລ໌ທັງສອງທິດທາງ.
ເລີ່ມຕົ້ນຟຣີ