ການຕັ້ງຄ່າຕົວແປສະພາບແວດລ້ອມ

ສາລະບານ:

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

ບົດສະຫຼຸບ

ບັນຫາ

ພວກເຮົາຢາກໃຫ້ແອັບພລິເຄຊັນຂອງພວກເຮົາຕັ້ງຄ່າໄດ້ນອກເໜືອຈາກຜະລິດຕະພັນ/ໄບນາຣີ/ຊອດ ເພື່ອໃຫ້ການ build ຄັ້ງດຽວເຮັດວຽກແຕກຕ່າງກັນໄດ້ຂຶ້ນກັບສະພາບແວດລ້ອມການຕິດຕັ້ງ.

• ເພື່ອບັນລຸສິ່ງນີ້ ພວກເຮົາຢາກໃຊ້ການຕັ້ງຄ່າຕົວແປສະພາບແວດລ້ອມ.

• ພວກເຮົາຢາກຈັດການການຕັ້ງຄ່າໂດຍໃຊ້ໄຟລ໌ທີ່ພວກເຮົາສາມາດຄວບຄຸມເວີຊັນໄດ້.

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

ການຕັດສິນໃຈ

ຕັດສິນໃຈເລືອກໄຟລ໌ .env ພ້ອມໄຟລ໌ຄ່າເລີ່ມຕົ້ນ ແລະ ໄຟລ໌ສະກີມາທີ່ກ່ຽວຂ້ອງ.

ສະຖານະ

ຕັດສິນໃຈແລ້ວ. ເປີດຮັບການພິຈາລະນາຄວາມສາມາດໃໝ່ເມື່ອມີອອກມາ.

ລາຍລະອຽດ

ສົມມຸດຕິຖານ

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

ພວກເຮົາສະໜັບສະໜູນແນວປະຕິບັດຂອງອຸດສາຫະກຳ “12 factor app” ແລະ ຍິ່ງກວ່ານັ້ນແມ່ນແນວປະຕິບັດທີ່ກ່ຽວຂ້ອງ “15 factor app”.

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

ຂໍ້ຈຳກັດ

ພວກເຮົາຢາກເກັບຂໍ້ມູນລັບໃຫ້ຢູ່ນອກລະບົບຄວບຄຸມເວີຊັນ (VCS) ຂອງການຈັດການຊອດໂຄ້ດ (SCM) ຂອງພວກເຮົາ.

ພວກເຮົາຢາກມຸ່ງໝັ້ນຄວາມເຂົ້າກັນໄດ້ກັບເຟຣມເວີກ ແລະ ໄລບຣາຣີຊອບແວທີ່ນິຍົມ. ຕົວຢ່າງ Node ມີໂມດູນ “dotenv” ສຳລັບອ່ານການຕັ້ງຄ່າຕົວແປສະພາບແວດລ້ອມ.

ຈຸດຢືນ

ພວກເຮົາໄດ້ພິຈາລະນາສອງສາມແນວທາງ:

• ເກັບການຕັ້ງຄ່າໃນແອັບ ເຊັ່ນ ໃນໄຟລ໌ config.js.

• ເກັບການຕັ້ງຄ່າໃນສະພາບແວດລ້ອມ ເຊັ່ນ ໃນໄຟລ໌ .env.

• ດຶງການຕັ້ງຄ່າຈາກສະຖານທີ່ທີ່ຮູ້ຈັກ ເຊັ່ນ ເຊີບເວີໃບອະນຸຍາດ.

ຂໍ້ໂຕ້ແຍ້ງ

ພວກເຮົາເລືອກແນວທາງໄຟລ໌ .env ເພາະ:

• ມັນເປັນທີ່ນິຍົມ ລວມທັງໃນບັນດາຜູ້ຊ່ຽວຊານ.

• ມັນເປັນໄປຕາມແບບແຜນຂອງໄຟລ໌ .env ທີ່ທີມຂອງພວກເຮົາໄດ້ໃຊ້ຢ່າງສຳເລັດຜົນຫຼາຍຄັ້ງໃນຫຼາຍໂຄງການ.

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

ຜົນໄດ້ຮັບ

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

ທີ່ກ່ຽວຂ້ອງ

ການຕັດສິນໃຈທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຄາດວ່າແອັບພລິເຄຊັນທັງໝົດຂອງພວກເຮົາຈະໃຊ້ແນວທາງນີ້.

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

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

ຄວາມຕ້ອງການທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຈະເພີ່ມຄວາມສາມາດ devops ສຳລັບໄຟລ໌ ລວມທັງ hooks, ການທົດສອບ ແລະ ການລວມລະບົບຢ່າງຕໍ່ເນື່ອງ.

ພວກເຮົາຕ້ອງຝຶກອົບຮົມເພື່ອນຮ່ວມທີມນັກພັດທະນາທັງໝົດກ່ຽວກັບການຕັດສິນໃຈນີ້.

ຜະລິດຕະພັນທີ່ກ່ຽວຂ້ອງ

ແຕ່ລະພື້ນທີ່ທີ່ພວກເຮົາຕິດຕັ້ງຈະຕ້ອງມີໄຟລ໌ .env ຂອງຕົນເອງ ແລະ ໄຟລ໌ທີ່ກ່ຽວຂ້ອງ.

ຫຼັກການທີ່ກ່ຽວຂ້ອງ

ຍ້ອນກັບໄດ້ງ່າຍ.

ໝາຍເຫດ

ຕົວຢ່າງໄຟລ໌ .env:

NAME=Alice Anderson
EMAIL=alice@example.com

ຕົວຢ່າງໄຟລ໌ .env.defaults:

NAME=Joe Doe
EMAIL=joe@example.com

ຕົວຢ່າງໄຟລ໌ .env.schema ທີ່ມີສະເພາະຄີ:

NAME
EMAIL