ວິທີນຳໃຊ້ GitLab UI ສຳລັບການບຳລຸງຮັກສາເອກະສານທີ່ຊັບຊ້ອນຂຶ້ນ

ທີມງານເອກະສານ Fedora <https://discussion.fedoraproject.org/tag/docs-team> Last review: 2023-05-13
Many of the repositories have now been migrated to Fedora Forge.
ເອກະສານຕ້ອງການການບຳລຸງຮັກສາເມື່ອເນື້ອຫາເພີ່ມຂຶ້ນ. ນັກຂຽນ ແລະ ຜູ້ກວດສອບສາມາດປະກອບສ່ວນເຂົ້າໃນ Docs ໄດ້ຢ່າງງ່າຍດາຍ ແລະ ມີປະສິດທິພາບພາຍໃນສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ເວັບ GitLab. ຕັ້ງແຕ່ Web IDE, CI pipeline ໄປຈົນເຖິງການກວດສອບເນື້ອຫາເວັບທີ່ສະແດງຜົນຮ່ວມກັນ ແລະ ການອະນຸມັດໜ້າເວັບ, ທ່ານສາມາດເຮັດວຽກກ່ຽວກັບເນື້ອຫາທີ່ດີ ແລະ ການບຳລຸງຮັກສາເອກະສານໄດ້ໂດຍບໍ່ຕ້ອງຂັດຈັງຫວະດ້ວຍການຕິດຕັ້ງ ແລະ ການຕັ້ງຄ່າ. ບົດຄວາມນີ້ສົມມຸດວ່າທ່ານມີຄວາມຄຸ້ນເຄີຍກັບ Git ແລະ ການລວມຕົວຢ່າງຕໍ່ເນື່ອງ (CI) ແລ້ວ.

ການບຳລຸງຮັກສາເອກະສານ

ການບຳລຸງຮັກສາເອກະສານມີຫຼາຍຮູບແບບ.

  • ຄວາມຖືກຕ້ອງທາງດ້ານເຕັກນິກ

  • ຄວາມທັນສະໄໝ

  • ການຄັດສັນເອກະສານຕາມລຳດັບທີ່ສົມເຫດສົມຜົນ

  • ຄວາມສອດຄ່ອງໃນການນຳສະເໜີ

  • ເທັມເພລດມາດຕະຖານ, ຄຸນລັກສະນະ ແລະ ຂໍ້ກຳນົດທີ່ໃຊ້ໃນຄັງເກັບຂໍ້ມູນ Docs ທັງໝົດ

  • ການນຳໃຊ້ CI pipeline ເພື່ອກວດສອບຄຸນນະພາບເອກະສານແບບອັດຕະໂນມັດ

ສ່ວນຕໍ່ໄປນີ້ຈະແນະນຳຂັ້ນຕອນການບຳລຸງຮັກສາ ແລະ ປັບປຸງຄຸນນະພາບຂອງຄັງເກັບຂໍ້ມູນ Fedora Docs ຢ່າງຕໍ່ເນື່ອງ ໂດຍໃຊ້ເຄື່ອງມືທີ່ມີມາໃຫ້ໃນ GitLab.

GitLab Web IDE

ເປີດຕົວເປັນສ່ວນໜຶ່ງຂອງ GitLab ລຸ້ນ 15.7 ໃນເດືອນທັນວາ 2022, Web IDE ໃໝ່ມີທັງຕົວສຳຫຼວດໄຟລ໌, ເຄື່ອງມືແກ້ໄຂຂໍ້ຄວາມ ແລະ ການຄວບຄຸມເວີຊັນຢູ່ໃນບ່ອນດຽວກັນ.

ຕົວສຳຫຼວດ

ຕົວສຳຫຼວດຢູ່ແຖບດ້ານຊ້າຍຊ່ວຍໃນການຄົ້ນຫາໂຄງສ້າງຄັງເກັບຂໍ້ມູນ ແລະ ລາຍຊື່ໄຟລ໌ໃນ Fedora Docs. ບໍ່ວ່າຈະເປັນຄັງເກັບຂໍ້ມູນໃດ, ໂຄງສ້າງຄັງເກັບຂໍ້ມູນມາດຕະຖານຈະຊ່ວຍໃຫ້ຜູ້ປະກອບສ່ວນສາມາດຄົ້ນຫາໄຟລ໌ ແລະ ອ້າງອີງຂ້າມຫຼາຍໆໜ້າໄດ້ຢ່າງວ່ອງໄວ.

explorer intro
Figure 1. ຕົວສຳຫຼວດ

ເຄື່ອງມືແກ້ໄຂຂໍ້ຄວາມ

ຫຼັງຈາກປ່ຽນແປງແລ້ວ, ໃຫ້ໄປທີ່ໄອຄອນ Source Control ໃນແຖບກິດຈະກຳ ແລະ ຄລິກ Changes ພາຍໃຕ້ປຸ່ມ Commit & Push ເພື່ອເບິ່ງລາຍຊື່ໄຟລ໌ທີ່ທ່ານປ່ຽນແປງໃນມຸມມອງແບບຄຽງຂ້າງກັນ. ຫາກທ່ານທຳການ commit ຫຼາຍຄັ້ງ, Changes ຈະສະແດງພາບລວມຂອງການປ່ຽນແປງທັງໝົດທີ່ທ່ານມີ.

source control
Figure 2. ເບິ່ງລາຍຊື່ໄຟລ໌ທີ່ຖືກປ່ຽນແປງ

ຫາກທ່ານຄລິກ Create MR, ທ່ານຈະຖືກສົ່ງໄປທີ່ fork ຂອງທ່ານເພື່ອສ້າງ merge request. ຕົວເລືອກ Go to project ແມ່ນເໝາະສົມເມື່ອທ່ານທຳການ commit ຍ່ອຍໆຕາມຂັ້ນຕອນ ແລະ ຕ້ອງການລວມພວກມັນເຂົ້າເປັນອັນດຽວ.

commit
Figure 3. ຂຽນ, commit, ສ້າງ MR

CI pipeline

ການທົດສອບອັດຕະໂນມັດສຳລັບ Docs ຈະກະຕຸ້ນການກວດສອບໄວຍາກອນ, ຂໍ້ຜິດພາດທາງດ້ານຮູບແບບ ແລະ ຊ່ວຍແກ້ໄຂພວກມັນກ່ອນທີ່ຈະຮ່ວມ MR. ເປົ້າໝາຍແມ່ນເພື່ອຄວາມສອດຄ່ອງຂອງເອກະສານທົ່ວທັງໂຄງການ ແລະ ການປະຕິບັດຕາມຄູ່ມືຮູບແບບ. ທີມງານ Docs ໄດ້ນຳໃຊ້ເຄື່ອງມືກວດສອບໄວຍາກອນເອກະສານ (linter) ສຳລັບບາງຄັງເກັບຂໍ້ມູນທີ່ທ່ານສາມາດຊອກຫາໄຟລ໌ຕັ້ງຄ່າ vale ໄດ້. ຜູ້ປະກອບສ່ວນບາງຄົນຂຽນບົດຄວາມໂດຍບໍ່ມີຄວາມຮູ້ກ່ຽວກັບຄູ່ມືຮູບແບບ ແລະ ຄວາມງ່າຍໃນການອ່ານ. ໃຫ້ເບິ່ງການຕັ້ງຄ່າ vale linter ສຳລັບ CI ໃນຄັງເກັບຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ:

ເຄື່ອງມືກວດສອບເອກະສານ (Linter) ທຳການທົດສອບຫຼາຍກວ່າ 20 ຢ່າງ:

  • ເພື່ອກະຕຸ້ນ CI pipeline ໃນການສະແກນຫາຂໍ້ຜິດພາດຕ່າງໆ.

  • ເພື່ອກວດສອບຄຳສັບ ແລະ ໂຄງສ້າງຂອງເອກະສານ.

  • ເພື່ອກວດສອບຄວາມຖືກຕ້ອງຂອງລິ້ງ.

  • ເພື່ອກວດສອບຄວາມງ່າຍໃນການອ່ານ ແລະ ທົດສອບການນຳໃຊ້ພາສາທີ່ເໝາະສົມ ແລະ ອື່ນໆ.

ກະລຸນາຮັບຊາບວ່າ linter ຊ່ວຍໃຫ້ທ່ານຂຽນໄດ້ດີຂຶ້ນ, ແຕ່ມັນບໍ່ໄດ້ແກ້ໄຂຂໍ້ຜິດພາດໃຫ້ໂດຍອັດຕະໂນມັດ.

ການກວດສອບດ້ວຍສາຍຕາ

ດ້ວຍແອັບກວດສອບ, ຕົວຢ່າງການສະແດງຜົນສົດຂອງໜ້າເວັບຈະປາກົດຂຶ້ນຫາກທ່ານຄລິກໄອຄອນ view app ຫຼື view deployment ໃນ preview MR_number.

view app
Figure 4. ຕົວຢ່າງການສະແດງຜົນສົດໂດຍໃຊ້ view app

ທ່ານຈະເຫັນໜ້າ Artifacts-build ພ້ອມກັບໝາຍເລກວຽກ ແລະ ລິ້ງໄປຫາໜ້າເວັບທີ່ສະແດງຜົນເຊິ່ງໂຮດຢູ່ເທິງ GitLab. ຄລິກລິ້ງເພື່ອສຳຫຼວດເນື້ອຫາ ຄືກັນກັບທີ່ທ່ານເຄີຍລັນສະຄຣິບ Docsbuild ໃນເຄື່ອງຄອມພິວເຕີສ່ວນຕົວ.

preview
Figure 5. ຕົວຢ່າງ MR ໃນການ deployment

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

ປຸ່ມ View app ຈະຫາຍໄປຫຼັງຈາກ MR ຖືກຮ່ວມແລ້ວ.

ລາຍງານຄຸນນະພາບໂຄດ

ເພື່ອເບິ່ງຜົນການກວດສອບຂອງ CI linting, ໃຫ້ໄປທີ່ Pipelines ໃນແຖບດ້ານຊ້າຍ ແລະ ຄລິກ code quality.

pipeline
Figure 6. ເບິ່ງຜົນການກວດສອບຂອງ CI linting

ທີມງານ Docs ຈະປະເມີນທາງເລືອກຕ່າງໆ ເພື່ອສະທ້ອນເຖິງການປ່ຽນແປງຢ່າງເປັນລະບົບໂດຍອີງຕາມລາຍງານຄຸນນະພາບໂຄດ.

ຂອບໃຈສຳລັບການປະກອບສ່ວນຂອງທ່ານ.

Want to help? Learn how to contribute to Fedora Docs ›