จากประโยคที่คุณพิมพ์ ถึงเว็บที่คนทั้งโลกเปิดได้ deploy ทำงานยังไงตั้งแต่ต้นจนจบ
คุณสร้างของในเครื่องตัวเองได้แล้ว แต่มันจะกลายเป็นเว็บจริงที่คนทั้งโลกเปิดได้ยังไง บทนี้อธิบาย deploy build และทั้งสายพานตั้งแต่ประโยคที่คุณพิมพ์จนถึง URL จริง รวมถึงแผนที่ไว้ไล่หาว่าถ้าของไม่ขึ้น ปัญหาอยู่ขั้นไหน และทำไม deploy พังถึงปลอดภัย ไม่ใช่หายนะ
จากประโยคที่คุณพิมพ์ ถึงเว็บที่คนทั้งโลกเปิดได้
ตอนนี้คุณสร้างของกับ AI ในเครื่องตัวเองได้แล้ว เปิดดูในเครื่อง ปุ่มกดได้ หน้าตาสวย ทุกอย่างทำงานครบ แต่พอมีคนถามว่า ขอลิงก์หน่อย เปิดดูจากมือถือได้ไหม คุณกลับให้ไม่ได้ เพราะของทั้งหมดยังอยู่แค่ในเครื่องคุณเครื่องเดียว ไม่มีใครในโลกเปิดเจอ
ช่องว่างตรงนี้คือสิ่งที่บททั้งภาคนี้สัญญาว่าจะพาคุณข้าม การทำให้ของที่ดีอยู่ในเครื่องคุณ กลายเป็นเว็บจริงที่คนทั้งโลกพิมพ์ที่อยู่แล้วเปิดเจอ มีคำเฉพาะของมันว่า deploy บทนี้จะพาคุณเห็นทั้งสาย ตั้งแต่ประโยคที่คุณพิมพ์ใส่ AI ไปจนถึงเว็บที่เปิดได้จริง ทุกข้อต่อมีชื่อ และพอคุณรู้จักทั้งสาย คุณจะไล่ออกว่าถ้าวันไหนของไม่ขึ้น ปัญหาไปสะดุดอยู่ขั้นไหน
ทำไมการเข้าใจสายพานนี้ถึงสำคัญกับการ vibe code
ก่อนลงรายละเอียด ขอปูให้ชัดว่าทำไมเรื่องนี้ถึงคุ้มที่จะเข้าใจจริง ไม่ใช่แค่กดผ่าน ๆ
เหตุผลแรกตรงไปตรงมา นี่คือคำสัญญาของทั้งภาค คุณเรียนสร้างของมาหลายบทเพื่อจุดนี้ คือได้ของที่ขึ้นจริง มีคนเปิดใช้ได้จริง ถ้าหยุดที่ของในเครื่องตัวเอง มันก็เป็นแค่ภาพร่างที่ไม่มีใครเห็น deploy คือก้าวที่เปลี่ยนมันจากร่างเป็นของจริง
เหตุผลที่สองสำคัญกว่าในเชิงปฏิบัติ พอคุณ vibe code สิ่งที่เกิดบ่อยมากคือ คุณสั่งแก้ของแล้ว เปิดเว็บจริงดู แต่ของที่แก้ไม่ขึ้น หน้าเว็บยังเป็นแบบเดิม ถ้าคุณไม่รู้ว่าจากประโยคที่พิมพ์ไปจนถึงเว็บจริงมันมีกี่ขั้น คุณจะงงอยู่ตรงนั้น ไม่รู้จะบอก AI ว่าอะไร แต่ถ้าคุณเห็นทั้งสายเป็นข้อ ๆ คุณจะถามตัวเองได้ทันทีว่า มันไปสะดุดขั้นไหน นี่คือเหตุผลจริงที่ต้องรู้จักสายพานทั้งเส้น ไม่ใช่แค่รู้ว่ามีปุ่ม deploy
deploy build และสายพาน รู้จักสามคำนี้ก่อน
ส่วนนี้คือใจความเชิงหลักการของบท มีสามคำที่ต้องรู้จักให้ชัด แต่ละคำมีนิยาม มีวิธีทำงาน มีกฎ และมีวิธีที่คนทำกันจริง ของบางอย่างในบทนี้คุณเรียนมาแล้วในบทก่อน เช่น commit push GitHub และ hosting กับ domain บทนี้จะหยิบมาวางต่อกัน ไม่สอนซ้ำ
deploy อ่านว่า ดีพลอย นิยาม คือการเอาเวอร์ชันที่ทำงานได้ในเครื่องคุณ ไปวางไว้บนเครื่องที่ฝากเว็บ เพื่อให้มันขึ้นออนไลน์ที่อยู่จริงที่คนทั้งโลกเปิดได้ ทำงานยังไง deploy ไม่ใช่การก๊อปไฟล์ไปวางเฉย ๆ มันคือการบอกเครื่องที่ฝากเว็บว่า เอาเวอร์ชันล่าสุดนี้ไปเป็นตัวที่เสิร์ฟให้คนทั้งโลกตั้งแต่ตอนนี้ พอ deploy สำเร็จ ใครพิมพ์ที่อยู่เว็บคุณเข้ามา จะเจอเวอร์ชันใหม่ทันที ไม่ใช่ของเก่า กฎ ของในเครื่องคุณกับของบนเว็บจริง เป็นคนละชุดกัน ของจะขึ้นเว็บจริงต่อเมื่อ deploy สำเร็จเท่านั้น แก้ในเครื่องเฉย ๆ เว็บจริงยังไม่เปลี่ยน
build อ่านว่า บิลด์ แปลว่า สร้าง หรือ ประกอบ นิยาม คือขั้นที่เครื่องที่ฝากเว็บเอาไฟล์ของคุณ มาเตรียมให้กลายเป็นรูปแบบสำเร็จที่พร้อมเสิร์ฟให้คนเปิด ทำงานยังไง ไฟล์ที่ AI เขียนให้คุณ ยังเป็นรูปแบบที่สะดวกสำหรับการแก้ ไม่ใช่รูปแบบที่เบราว์เซอร์ของคนทั่วไปเปิดได้เร็วที่สุดทันที build คือขั้นที่เครื่องเอาไฟล์พวกนั้นมาประกอบ แปลง และบีบอัดให้เป็นชุดไฟล์สำเร็จ เหมือนเอาวัตถุดิบมาปรุงเป็นจานที่พร้อมเสิร์ฟ ถ้าระหว่างประกอบเจออะไรผิด เช่นพิมพ์โค้ดพลาดจุดหนึ่ง build จะล้มเหลว และจะไม่มีของใหม่ออกไปเสิร์ฟ กฎ deploy ที่สำเร็จต้องผ่าน build ก่อนเสมอ ถ้า build ล้ม การ deploy รอบนั้นก็ไม่เกิด เว็บจริงไม่เปลี่ยน
สายพาน หรือ the pipeline นิยาม คือทั้งสายตั้งแต่ประโยคที่คุณพิมพ์ ไปจนถึงเว็บที่ขึ้นจริง ร้อยทุกขั้นต่อกันเป็นเส้นเดียว ทำงานยังไง แต่ละขั้นในสายส่งงานต่อให้ขั้นถัดไป คุณพิมพ์สั่ง AI แก้ไฟล์ คุณ commit เก็บ push ขึ้น GitHub เครื่องที่ฝากเว็บเห็นแล้ว build แล้ว deploy ออกเป็นเว็บจริง งานไหลจากต้นไปปลายเป็นทอด ขั้นก่อนหน้าต้องเสร็จก่อน ขั้นถัดไปถึงเริ่ม กฎ ของจะขึ้นเว็บจริงก็ต่อเมื่อทุกขั้นในสายเสร็จครบ สะดุดขั้นใดขั้นหนึ่ง ของก็ค้างอยู่ตรงนั้น ไม่ไหลถึงปลาย
ในทางปฏิบัติ สำหรับเว็บที่สร้างกับ AI มันเกิดขึ้นจริงยังไง ของจริงที่คนทำกันคือ ไม่ต้องมานั่งสั่ง deploy เองทุกครั้ง แต่ตั้งค่าให้มันทำเองอัตโนมัติ วิธีคือเอา repo บน GitHub ของคุณ ไปเชื่อมกับเครื่องที่ฝากเว็บอย่าง Netlify หรือ Vercel ทำครั้งเดียวต่อหนึ่งโปรเจกต์ พอเชื่อมแล้ว ทุกครั้งที่คุณ push ของขึ้น GitHub เครื่องที่ฝากเว็บจะเห็นเอง แล้ว build กับ deploy ให้อัตโนมัติ สิ่งนี้เรียกว่า auto-deploy แปลว่าหลังตั้งค่าครั้งแรกเสร็จ ขั้นตอนการขึ้นเว็บของคุณเหลือแค่ push เท่านั้น ที่เหลือเครื่องจัดการเอง
ทำไมถึงนิยมต่อกับ GitHub แบบนี้ เพราะมันเชื่อมเข้ากับสิ่งที่คุณทำอยู่แล้วพอดี คุณ push เพื่อสำรองงานขึ้นออนไลน์อยู่แล้ว (เรื่อง push กับ GitHub เป็นของบท git) การขึ้นเว็บเลยมาฟรีแทบจะอัตโนมัติ ไม่ต้องเพิ่มขั้นตอนใหม่ ตัวอย่างจริงคือเว็บ AI ภาษาคน เว็บนี้เอง เส้นทางของมันคือ สั่ง AI แก้ของ commit เก็บ push ขึ้น GitHub แล้ว Netlify ที่ต่อไว้กับ repo นั้น ก็ build แล้ว deploy ออกมาเป็น aipasakon.com ให้คนเปิดได้ ทุกครั้งที่เจ้าของแก้อะไร วงจรนี้วิ่งเองรอบหนึ่ง
วิธีอ่านสถานะ deploy พอตั้ง auto-deploy ไว้ ทุกครั้งที่ push เครื่องที่ฝากเว็บจะแสดงสถานะของรอบนั้นให้ดู มีสามสถานะหลักที่ต้องอ่านออก
- building หรือกำลังประกอบ คือเครื่องกำลัง build อยู่ ยังไม่เสร็จ ให้รอ
- published หรือ live คือ build เสร็จ deploy สำเร็จ เวอร์ชันใหม่ขึ้นเว็บจริงแล้ว เปิดดูได้
- failed คือมีขั้นผิดพลาด มัก build ไม่ผ่าน รอบนี้ไม่ขึ้นเว็บ และสำคัญมาก เว็บจริงยังเป็นเวอร์ชันเก่าที่ดีอยู่ ไม่ได้พังตาม
การอ่านสถานะนี้เป็นทักษะจริงที่ใช้ทุกวัน เพราะมันบอกคุณตรง ๆ ว่ารอบที่เพิ่ง push ไป ขึ้นเว็บแล้วหรือยัง หรือสะดุดตรงไหน
เห็นทั้งสาย จากประโยคที่พิมพ์ ถึงเว็บจริง ทีละขั้น
จนถึงตรงนี้คุณรู้จัก deploy build และสายพานทีละคำแล้ว แต่ของพวกนี้จะชัดที่สุดเมื่อเห็นมันร้อยต่อกันเป็นเส้นเดียวในงานจริง สมมติคุณเพิ่งสั่ง AI ให้เพิ่มปุ่มบันทึกลงในแอป แล้วอยากให้มันขึ้นเว็บจริง นี่คือสิ่งที่เกิดขึ้นทีละขั้น และสังเกตว่าแต่ละขั้นเป็นเจ้าของหน้าที่อะไร
- คุณพิมพ์สั่ง AI แก้ไฟล์ คุณบอก AI ว่าขอเพิ่มปุ่มบันทึก AI ลงมือแก้ไฟล์ในโปรเจกต์ในเครื่องคุณ ตอนนี้ของใหม่อยู่ในเครื่องคุณเครื่องเดียว ยังไม่มีใครในโลกเห็น
- คุณ commit เก็บเป็นจุดเซฟ คุณสั่ง commit AI ถ่ายรูปสถานะไฟล์ตอนนี้เก็บเป็นจุดเซฟหนึ่ง พร้อมข้อความกำกับ ตรงนี้ยังเป็นเรื่องในเครื่องคุณล้วน ๆ commit เป็นของบท git ขอแค่ทวนว่ามันคือจุดเซฟในเครื่อง
- ของถูก push ขึ้น GitHub คุณสั่ง push AI ส่ง commit ล่าสุดขึ้นไปเก็บบน GitHub ตอนนี้ของใหม่ออกจากเครื่องคุณ ไปอยู่บนออนไลน์แล้วหนึ่งที่ push กับ GitHub ก็เป็นของบท git ขอแค่ทวนว่ามันคือการ sync ของขึ้นที่เก็บออนไลน์
- เครื่องที่ฝากเว็บเห็น แล้ว build Netlify ที่ต่อไว้กับ repo นั้น เห็นว่ามีของใหม่ push ขึ้น GitHub มันดึงของล่าสุดมา แล้วเริ่ม build คือประกอบไฟล์ให้เป็นรูปแบบสำเร็จที่พร้อมเสิร์ฟ ตอนนี้สถานะจะขึ้นว่า building
- มัน deploy แล้วขึ้นเว็บจริง พอ build เสร็จเรียบร้อย เครื่องก็ deploy คือเอาเวอร์ชันใหม่ขึ้นไปเป็นตัวที่เสิร์ฟจริง สถานะเปลี่ยนเป็น published ตอนนี้ใครพิมพ์ที่อยู่เว็บคุณเข้ามา จะเจอปุ่มบันทึกใหม่ทันที
สังเกตว่าทั้งห้าขั้นไม่ได้อยู่แยกกัน แต่ร้อยกันเป็นสายเดียว คือ พิมพ์สั่ง AI แก้ ไป เซฟเป็น commit ไป push ขึ้น GitHub ไป เครื่อง build ไป deploy ขึ้นจริง และสามขั้นแรกอยู่ในมือคุณ สองขั้นหลังเครื่องทำเองอัตโนมัติหลังคุณ push สายนี้คือสิ่งที่วิ่งทุกครั้งที่คุณอยากให้ของขึ้นเว็บจริง
ถ้าของไม่ขึ้น ให้ไล่หาว่าสะดุดขั้นไหน
ประโยชน์ที่จับต้องได้ที่สุดของการเห็นทั้งสาย คือเวลาของไม่ขึ้น คุณไล่หาเป็น แทนที่จะงงทั้งก้อน อาการที่พบบ่อยที่สุดคือ คุณแก้ของแล้ว เปิดเว็บจริงดู แต่หน้าเว็บยังเป็นแบบเดิม ของใหม่ไม่ขึ้น ให้ไล่ย้อนจากปลายกลับไปต้นทีละขั้น
- deploy ขึ้นแล้วหรือยัง เปิดแผงสถานะที่เครื่องที่ฝากเว็บ ดูว่ารอบล่าสุดเป็น published หรือยัง ถ้าเป็น failed แปลว่า build พัง ของเลยไม่ขึ้น ให้ไปดูว่า build ล้มเพราะอะไร ถ้าเป็น building อยู่แปลว่ายังไม่เสร็จ แค่รอ
- push ขึ้น GitHub แล้วหรือยัง ถ้าไม่เห็นรอบ deploy ใหม่เกิดขึ้นเลย เป็นไปได้ว่าของยังไม่ถูก push ขึ้น GitHub เครื่องเลยไม่เห็นว่ามีอะไรใหม่ ไม่มีอะไรให้ build ให้เช็คว่า commit ล่าสุด push ขึ้นไปแล้วจริงไหม
- commit แล้วหรือยัง ถ้ายังไม่ได้ commit เลย ก็ไม่มีอะไรให้ push ของที่แก้ค้างอยู่ในเครื่องเฉย ๆ ยังไม่เข้าสาย
- AI แก้ไฟล์จริงหรือเปล่า ขั้นต้นสุด บางทีคุณสั่งแล้วแต่ AI ยังไม่ได้ลงมือแก้ไฟล์จริง หรือแก้คนละจุดกับที่คุณคิด ของเลยไม่เปลี่ยนตั้งแต่ต้นทาง
สังเกตว่าการไล่แบบนี้ทำได้เพราะคุณรู้ว่าสายมีกี่ขั้น แต่ละขั้นทำอะไร คุณเลยถามได้ตรงจุดว่าของไปค้างตรงไหน นี่คือเหตุผลจริงที่บทนี้ให้คุณเห็นทั้งสาย ไม่ใช่แค่รู้ว่ามีปุ่ม deploy
deploy พัง คือเรื่องปลอดภัย ไม่ใช่หายนะ
ตรงนี้มีความสบายใจที่ต้องเข้าใจให้ถึงกลไก ไม่ใช่แค่ปลอบ คนเริ่มต้นมักกลัวว่ากด deploy แล้วถ้าพัง เว็บจริงจะล่มไปด้วย คนที่กำลังเปิดอยู่จะเจอจอขาว ความจริงไม่ใช่แบบนั้นเลย
กลไกคือ เวอร์ชันใหม่จะขึ้นไปแทนของเก่า ก็ต่อเมื่อ build และ deploy สำเร็จครบเท่านั้น ถ้า build ล้มกลางทาง เครื่องที่ฝากเว็บก็แค่ทิ้งรอบนั้นไป แล้วเสิร์ฟเวอร์ชันเก่าที่ดีอยู่ต่อไปเหมือนไม่มีอะไรเกิดขึ้น คนที่เปิดเว็บคุณอยู่ ไม่รู้ด้วยซ้ำว่ามี deploy ที่ล้มเหลวเกิดขึ้นเบื้องหลัง เพราะหน้าเว็บที่เขาเห็นไม่เปลี่ยนเลย
แปลว่า deploy ที่พัง ไม่ได้ทำให้เว็บจริงพัง มันแค่ทำให้ของใหม่ยังไม่ขึ้น ของเก่ายังอยู่ครบ นี่คือหลักการเดิมที่คุณเจอมาตลอดภาคนี้ คือทุกอย่างย้อนกลับได้และปลอดภัย เพียงแต่คราวนี้มันยังจริงอยู่ แม้ตอนของขึ้นเว็บไปแล้ว ความเสี่ยงของการกด deploy จึงต่ำกว่าที่กลัวมาก กรณีแย่สุดของ deploy ที่พังคือ ของใหม่ไม่ขึ้น ไม่ใช่ ของเก่าหาย
ปุ่มบันทึกของคุณ ขึ้นเว็บจริงแล้ว
ตลอดภาคนี้เราพาปุ่มบันทึกเล็ก ๆ ปุ่มเดียวเดินทางมาเรื่อย จากที่มันทำงานได้แค่ในเครื่องคุณ เปิดดูได้คนเดียว มาถึงบทนี้คือจุดสำคัญ คุณ commit แล้ว push แล้วเครื่องที่ฝากเว็บก็ build แล้ว deploy และปุ่มบันทึกนั้น ขึ้นไปอยู่บน aipasakon.com จริง คนแปลกหน้าที่ไหนก็ได้ในโลก เปิดเว็บแล้วกดปุ่มนั้นได้
ปุ่มเดียวกันที่เมื่อก่อนเป็นของส่วนตัวอยู่แค่ในเครื่องคุณ ตอนนี้อยู่บนเว็บจริงให้ทุกคนใช้ นี่คือสิ่งที่คำว่า ขึ้น production หมายถึงจริง ๆ ไม่ใช่คำลอย ๆ แต่คือปุ่มจริงที่คนจริงกดได้ และเส้นทางที่พามันมาถึงตรงนี้ ก็คือสายพานที่คุณเพิ่งเห็นทั้งเส้นนั่นเอง
ภาพช่วยจำ
ตอนนี้คุณเข้าใจกลไกจริงแล้ว ขอเติมภาพหนึ่งไว้ช่วยจำ ทั้งสายพานนี้เหมือนการทำจดหมายข่าวส่งให้สมาชิก ตอนคุณนั่งเขียนและแก้ต้นฉบับอยู่บนโต๊ะ นั่นคือร่างส่วนตัวของคุณ เหมือนของที่อยู่ในเครื่องคุณ การเซฟต้นฉบับเป็นเวอร์ชันที่ตั้งชื่อไว้ เหมือนการ commit เก็บจุดเซฟ พอเขียนเสร็จคุณส่งฉบับสมบูรณ์ไปให้โรงพิมพ์ เหมือนการ push ขึ้น GitHub แล้วโรงพิมพ์เดินแท่นพิมพ์และส่งจดหมายข่าวออกไปถึงมือสมาชิกทุกคน นั่นคือ build กับ deploy ที่เครื่องที่ฝากเว็บทำให้
จุดที่การเปรียบเทียบนี้ใช้ไม่ได้ และเป็นจุดที่ deploy เก่งกว่า คือจดหมายข่าวที่ส่งออกไปแล้วถึงมือคนแล้ว แก้อะไรไม่ได้อีก พิมพ์ผิดก็ต้องทนไปทั้งฉบับ แต่เว็บที่ deploy ไปแล้ว คุณแก้แล้ว deploy ใหม่ทับได้ในไม่กี่นาที เจอที่ผิดตอนบ่าย แก้แล้วส่งขึ้นใหม่ตอนบ่ายได้เลย นี่คือเหตุผลที่หลักการย้อนกลับได้ยังสำคัญ แม้ตอนของขึ้นเว็บไปแล้ว ของที่ขึ้นจริงไม่ใช่ของที่ตายตัวแก้ไม่ได้ แต่เป็นของที่คุณวนแก้แล้วส่งขึ้นใหม่ได้เรื่อย ๆ
ถึงตรงนี้ ต่อให้ลืมภาพจดหมายข่าวไป คุณก็ยังอธิบายได้ว่า deploy คือการเอาเวอร์ชันที่ดีในเครื่อง ไปวางบนเครื่องที่ฝากเว็บให้ขึ้นออนไลน์ build คือขั้นประกอบไฟล์ให้พร้อมเสิร์ฟ และสายพานคือทั้งเส้นตั้งแต่ประโยคที่พิมพ์ ถึงเว็บจริง ภาพจดหมายข่าวเป็นแค่หมุดช่วยจำ ไม่ใช่ตัวคำอธิบาย
ความเข้าใจผิดที่พบบ่อย
ก่อนปิดบท ขอเก็บกวาดความเข้าใจผิดสามข้อที่ทำให้คนงงบ่อยที่สุด
เข้าใจผิดว่า commit แล้วเท่ากับขึ้นเว็บเลย จริง ๆ commit คือการเซฟในเครื่องคุณเท่านั้น ของยังไม่ออกไปไหน มันจะขึ้นเว็บจริงต่อเมื่อ push ขึ้น GitHub แล้วเครื่องที่ฝากเว็บ build กับ deploy สำเร็จ commit เป็นแค่ขั้นแรก ไม่ใช่ขั้นสุดท้าย
เข้าใจผิดว่าแก้โค้ดแล้วเว็บเปลี่ยนทันที จริง ๆ หลัง push แล้ว เครื่องต้องใช้เวลา build กับ deploy อีกครู่หนึ่ง ไม่ใช่วินาทีที่คุณ push แล้วเว็บเปลี่ยนเดี๋ยวนั้น และถ้า build ล้ม ของก็ไม่เปลี่ยนเลย เว็บยังเป็นเวอร์ชันเก่า ฉะนั้นเวลาแก้แล้วเว็บยังไม่เปลี่ยน อย่าเพิ่งตกใจ ให้ไปดูสถานะ deploy ว่ายัง building อยู่ หรือ failed ไปแล้ว
เข้าใจผิดว่าตอน deploy เว็บจริงจะอยู่ในความเสี่ยง จริง ๆ ระหว่าง build กับ deploy เว็บจริงยังเสิร์ฟเวอร์ชันเก่าที่ดีอยู่ตลอด เวอร์ชันใหม่จะขึ้นมาแทนก็ต่อเมื่อสำเร็จครบเท่านั้น ถ้าพังกลางทาง ของเก่าก็อยู่เหมือนเดิม คนที่เปิดเว็บอยู่ไม่ได้รับผลกระทบ
💡 ใจความสำคัญ: deploy คือการพาของจากเครื่องคุณขึ้นไปเป็นเว็บจริงที่คนทั้งโลกเปิดได้ และมันคือทั้งสายที่ร้อยต่อกัน พิมพ์สั่ง AI แก้ เซฟเป็น commit push ขึ้น GitHub เครื่อง build แล้ว deploy ขึ้นจริง สามขั้นแรกคุณสั่ง สองขั้นหลังเครื่องทำเองหลังคุณ push พอเห็นทั้งสาย คุณไล่ออกว่าของไปค้างขั้นไหนเวลามันไม่ขึ้น และที่สำคัญ deploy ที่พังไม่ใช่หายนะ เพราะเว็บจริงเสิร์ฟของเก่าต่อไปจนกว่ารอบใหม่จะสำเร็จ คุณจึงกล้าส่งของขึ้นได้เรื่อย ๆ
ถึงตรงนี้คุณทำได้ครบทั้งสองด้านแล้ว สร้างของในเครื่องเป็น และพามันขึ้นเว็บจริงให้คนทั้งโลกใช้เป็น เหลือคำถามสุดท้ายว่า แล้วทั้งหมดที่เรียนมาในภาคนี้มันต่อกันเป็นภาพเดียวยังไง และจากนี้คุณจะเดินต่อไปทางไหน นั่นคือเรื่องของบทปิดท้ายภาค ที่จะมัดทุกอย่างเข้าด้วยกัน