ข้อดีของการสร้างสคริปต์คืออะไร

สำหรับอาชีพการเขียนโปรแกรมส่วนใหญ่ของฉันฉันได้ใช้คำสั่ง "build / compile / run" ในทุก ๆ IDE ที่ฉันทำงานด้วยเพื่อสร้างโปรแกรมที่รันได้ นี่คือปุ่มเดียวค่อนข้างง่าย ในขณะที่ฉันเรียนรู้เพิ่มเติมเกี่ยวกับภาษาและกรอบงานต่าง ๆ ฉันเห็นการพูดถึง "build script" มากขึ้นเรื่อย ๆ (ANT, Maven, Gradle และอื่น ๆ ) เพื่อให้โครงการทำงาน ความเข้าใจของฉันเกี่ยวกับสิ่งเหล่านี้คือพวกเขาเป็นคำแนะนำสำหรับคอมไพเลอร์ / ลิงเกอร์ / ผู้เขียนโปรแกรมที่ระบุรายละเอียดการกำหนดค่า - minutiae

ฉันจำได้ว่าการเขียน makefiles กลับไปโรงเรียน แต่ฉันไม่เห็นข้อได้เปรียบพิเศษใด ๆ เลย (เราจะใช้มันเฉพาะเมื่อเขียนในเทอร์มินัล Unix ที่ IDE ไม่มีปุ่ม "สร้าง" ที่มีประโยชน์) นอกเหนือจากนั้นผมเคยเห็นคำถามอื่น ๆ ที่นี่ที่หารือถึงวิธีการสร้างสคริปต์สามารถทำได้มากกว่าเพียงแค่สร้างโปรแกรมของคุณ - พวกเขาสามารถเรียกใช้การทดสอบหน่วยเช่นเดียวกับแหล่งข้อมูลที่เชื่อถือได้โดยไม่คำนึงถึงเครื่องโฮสต์

ฉันไม่สามารถสั่นคลอนความรู้สึกที่สร้างสคริปต์มีความสำคัญต่อการเข้าใจในฐานะนักพัฒนา แต่ฉันต้องการคำอธิบายที่มีความหมาย เหตุใดฉันจึงควรใช้ / เขียนสคริปต์สร้าง

ความรับผิดชอบของ Build Script และ Build Serverกล่าวถึงบทบาทที่เล่นภายในขอบเขตที่กว้างขึ้น ฉันกำลังมองหาข้อได้เปรียบที่เฉพาะเจาะจงที่เสนอโดยบิลด์สคริปต์กับคำสั่ง "บิลด์ / รัน" ของ IDE หรือวิธีการง่ายๆ

การทำงานอัตโนมัติ

เมื่อคุณกำลังพัฒนาเฉพาะในโครงการที่ง่ายที่สุดปุ่ม "สร้าง" เริ่มต้นจะทำทุกสิ่งที่คุณต้องการ คุณอาจต้องสร้าง WS out of APIs สร้างเอกสารเชื่อมโยงกับแหล่งข้อมูลภายนอกปรับใช้การเปลี่ยนแปลงไปยังเซิร์ฟเวอร์ ฯลฯ IDE บางตัวอนุญาตให้คุณปรับแต่งกระบวนการสร้างโดยการเพิ่มขั้นตอนพิเศษหรือตัวสร้าง แต่นั่นหมายความว่าคุณเท่านั้น สร้างสคริปต์สร้างของคุณผ่านสินค้าโภคภัณฑ์ IDE

แต่การพัฒนาระบบไม่ได้เป็นการเขียนโค้ดเท่านั้น มีหลายขั้นตอนที่เกี่ยวข้อง สคริปต์อิสระของ IDE สามารถดำเนินการได้โดยอัตโนมัติซึ่งหมายความว่า:

• เมื่อคุณส่งมอบการเปลี่ยนแปลงการควบคุมเวอร์ชันการสร้างใหม่สามารถเปิดใช้โดยอัตโนมัติโดยเซิร์ฟเวอร์ มันจะทำให้แน่ใจว่าคุณไม่ได้ลืมที่จะกระทำสิ่งที่จำเป็นสำหรับการสร้าง

• ในทำนองเดียวกันหลังจากการสร้างเสร็จสิ้นการทดสอบสามารถเรียกใช้โดยอัตโนมัติเพื่อดูว่าคุณทำอะไรหัก

• ตอนนี้ส่วนที่เหลือขององค์กร (QA, sysadmins) มีผลิตภัณฑ์ที่สร้างขึ้นแล้ว

  a) สามารถทำซ้ำได้อย่างสมบูรณ์แบบจากรุ่นควบคุม

  b) เป็นเรื่องปกติสำหรับทุกคน

แม้เมื่อฉันทำงานเป็นทีมชายคนหนึ่งฉันก็ใช้สคริปต์เพื่อจุดประสงค์นั้น เมื่อฉันได้พัฒนาการแก้ไขฉันจะส่งไปที่ SVN ให้ส่งออก SVN กลับไปยังไดเรกทอรีอื่นและใช้สคริปต์การสร้างเพื่อสร้างวิธีแก้ไขซึ่งจะไปที่ระบบการผลิตล่วงหน้าและการผลิตในภายหลัง หากไม่กี่สัปดาห์ต่อมา (ด้วย codebase ในพื้นที่ของฉันเปลี่ยนแปลงไปแล้ว) มีคนบ่นว่ามีข้อบกพร่องฉันจะรู้ว่าการแก้ไข SVN แบบใดที่ฉันจะต้องเช็คเอาต์เพื่อแก้ไขข้อผิดพลาดของระบบอย่างถูกต้อง

เช่นเดียวกับรหัส build สคริปต์จะถูกเรียกใช้งานโดยคอมพิวเตอร์ คอมพิวเตอร์มีคุณสมบัติที่ดีเป็นพิเศษในการทำตามคำแนะนำ ในความเป็นจริง (นอกรหัสแก้ไขตัวเอง) คอมพิวเตอร์จะดำเนินการตามลำดับของคำแนะนำแบบเดียวกับที่ได้รับอินพุตเดียวกัน สิ่งนี้นำเสนอระดับความสอดคล้องซึ่งมีเพียงคอมพิวเตอร์เท่านั้นที่สามารถจับคู่ได้

ในทางตรงกันข้ามถุงบรรจุน้ำที่ใส่น้ำของเรานั้นน่ารังเกียจอย่างยิ่งเมื่อพูดถึงขั้นตอนต่อไป สมองวิเคราะห์ที่น่ารำคาญนั้นมีแนวโน้มที่จะตั้งคำถามกับทุกสิ่งที่เจอ "โอ้ ... ฉันไม่ต้องการสิ่งนั้น" หรือ "ฉันจะใช้ธงนี้จริงเหรอ? เอ๊ะ ... ฉันแค่จะเพิกเฉย" นอกจากนี้เรามีแนวโน้มที่จะได้รับความพึงพอใจ เมื่อเราทำอะไรซักสองสามครั้งเราจะเริ่มเชื่อว่าเรารู้คำแนะนำและไม่ต้องดูเอกสารการสอน

จาก "The Pragmatic Programmer":

นอกจากนี้เราต้องการรับประกันความสม่ำเสมอและการทำซ้ำในโครงการ ขั้นตอนแบบแมนนวลปล่อยให้ความสอดคล้องเปลี่ยนแปลงไป ไม่รับประกันความสามารถในการทำซ้ำโดยเฉพาะอย่างยิ่งหากแง่มุมของกระบวนการเปิดสำหรับการตีความโดยบุคคลอื่น

นอกจากนี้เรายังซบเซาอย่างมากในการดำเนินการคำสั่ง (เทียบกับคอมพิวเตอร์) ในโครงการขนาดใหญ่ที่มีหลายร้อยไฟล์และการกำหนดค่ามันจะใช้เวลาหลายปีในการดำเนินการทุกขั้นตอนในกระบวนการสร้าง

ฉันจะให้คุณตัวอย่างโลกแห่งความจริง ฉันกำลังใช้งานซอฟต์แวร์ฝังตัวบางตัวซึ่งส่วนใหญ่มีการแชร์รหัสผ่านแพลตฟอร์มฮาร์ดแวร์ต่าง ๆ แต่ละแพลตฟอร์มมีฮาร์ดแวร์ที่แตกต่างกัน แต่ซอฟต์แวร์ส่วนใหญ่เหมือนกัน แต่มีชิ้นส่วนเล็ก ๆ ที่เฉพาะเจาะจงกับฮาร์ดแวร์แต่ละตัว โดยปกติแล้วชิ้นส่วนทั่วไปจะถูกวางไว้ในห้องสมุดและเชื่อมโยงกับแต่ละเวอร์ชั่น อย่างไรก็ตามไม่สามารถรวบรวมชิ้นส่วนทั่วไปลงในห้องสมุดสาธารณะ มันจะต้องรวบรวมกับการกำหนดค่าที่แตกต่างกันทุกคน

ตอนแรกฉันรวบรวมการตั้งค่าแต่ละอย่างด้วยตนเอง ใช้เวลาเพียงไม่กี่วินาทีในการสลับระหว่างการกำหนดค่าและไม่เจ็บปวดอย่างมาก ในตอนท้ายของโครงการพบข้อบกพร่องที่สำคัญในส่วนของรหัสที่ใช้ร่วมกันโดยที่อุปกรณ์จะต้องเข้าควบคุมบัสการสื่อสารเป็นหลัก นี่มันไม่ดีเลย! เลวจริงๆ. ฉันพบข้อบกพร่องในรหัสแก้ไขและคอมไพล์ใหม่ทุกรุ่น ยกเว้นหนึ่ง ในระหว่างกระบวนการสร้างฉันได้ฟุ้งซ่านและลืมไป ไบนารีได้รับการปล่อยตัวเครื่องสร้างขึ้นและอีกหนึ่งวันต่อมาฉันได้รับโทรศัพท์แจ้งว่าเครื่องหยุดตอบสนอง ฉันตรวจสอบมันและพบว่าอุปกรณ์ล็อครถบัส "แต่ฉันแก้ไขข้อผิดพลาดนั้น!"

ฉันอาจจะแก้ไข แต่ก็ไม่เคยพบวิธีที่จะลงบนบอร์ดหนึ่งที่ ทำไม? เพราะฉันไม่ได้มีกระบวนการสร้างอัตโนมัติที่สร้างทุกรุ่นด้วยการคลิกเพียงครั้งเดียว

หากสิ่งที่คุณต้องการทำคือการ<compiler> **/*.<extension>สร้างสคริปต์ที่มีจุดประสงค์เล็ก ๆ น้อย ๆ (แม้ว่าใคร ๆ ก็สามารถเถียงได้ว่าถ้าคุณเห็นMakefileในโครงการคุณรู้ว่าคุณสามารถสร้างมันขึ้นมาได้make) สิ่งที่เป็น - โครงการที่ไม่สำคัญมักจะต้องการมากกว่านั้น - อย่างน้อยที่สุดคุณจะต้องเพิ่มไลบรารีและ (เมื่อโครงการเติบโต) กำหนดค่าพารามิเตอร์การสร้าง

IDE มักเป็นอย่างน้อยที่สามารถกำหนดค่าได้ - แต่ตอนนี้กระบวนการสร้างอาศัยตัวเลือกเฉพาะของ IDE หากคุณกำลังใช้Eclipse , Alice ชอบNetBeansและ Bob ต้องการใช้IntelliJ IDEAคุณไม่สามารถแชร์การกำหนดค่าได้และเมื่อหนึ่งในคุณผลักดันการเปลี่ยนแปลงไปยังตัวควบคุมแหล่งที่มาพวกเขาต้องแก้ไขการกำหนดค่า IDE ที่สร้างด้วยตนเอง ไฟล์ของผู้พัฒนารายอื่นหรือแจ้งผู้พัฒนารายอื่นเพื่อให้พวกเขาทำเอง (ซึ่งหมายความว่าจะมีการกระทำที่การกำหนดค่า IDE ไม่ถูกต้องสำหรับ IDE บางตัว ... )

คุณต้องหาวิธีการเปลี่ยนแปลงใน IDE แต่ละตัวที่ใช้โดยทีมและถ้าหนึ่งในนั้นไม่รองรับการตั้งค่านั้น ...

ตอนนี้ปัญหานี้ขึ้นอยู่กับวัฒนธรรม - นักพัฒนาของคุณอาจพบว่ามันเป็นที่ยอมรับหากไม่มีตัวเลือก IDE แต่นักพัฒนาที่มีประสบการณ์เกี่ยวกับ IDE มักจะมีความสุขและมีประสิทธิภาพมากขึ้นเมื่อใช้งานและผู้ใช้โปรแกรมแก้ไขข้อความมักจะกระตือรือร้นในการใช้เครื่องมือที่พวกเขาชอบดังนั้นนี่คือหนึ่งในสถานที่ที่คุณต้องการให้อิสระกับนักพัฒนา - และสร้างระบบช่วยให้คุณทำเช่นนั้นได้ บางคนอาจมีการตั้งค่าระบบการสร้าง แต่ก็ไม่ได้ใกล้เคียงกับความคลั่งไคล้เช่นการตั้งค่า IDE / บรรณาธิการ ...

แม้ว่าคุณจะได้รับนักพัฒนาทั้งหมดเพื่อใช้ IDE เดียวกัน - ขอให้โชคดีในการสร้างเซิร์ฟเวอร์เพื่อใช้ ...

ตอนนี้สำหรับการปรับแต่งกระบวนการสร้างอย่างง่ายแล้ว IDE นั้นมักจะให้ GUI ที่ดีสำหรับ หากคุณต้องการสิ่งที่ซับซ้อนมากขึ้น - เช่นการประมวลผลล่วงหน้า / สร้างไฟล์อัตโนมัติก่อนการรวบรวม - โดยปกติคุณจะต้องเขียนสคริปต์ก่อนการสร้างในพื้นที่ข้อความพื้นฐานภายในการกำหนดค่าของ IDE ระบบการสร้างใดที่คุณจะต้องใช้รหัสส่วนนั้น แต่คุณสามารถทำได้ในตัวแก้ไขจริงที่คุณเขียนรหัสและที่สำคัญกว่า: กรอบการทำงานของระบบการสร้างมักจะให้การสนับสนุนบางอย่างสำหรับการจัดระเบียบสคริปต์เหล่านี้

ในที่สุด - สร้างระบบที่ดีกว่าเพียงแค่สร้างโครงการ - คุณสามารถตั้งโปรแกรมให้ทำงานอื่น ๆ ที่ทุกคนในทีมอาจต้องดำเนินการ ตัวอย่างเช่นในRuby on Railsมีงานสร้างระบบสำหรับการเรียกใช้การย้ายฐานข้อมูลสำหรับทำความสะอาดไฟล์ชั่วคราว ฯลฯ การวางงานเหล่านี้ในระบบบิลด์ทำให้แน่ใจว่าทุกคนในทีมสามารถทำงานได้อย่างต่อเนื่อง

IDEs จำนวนมากเพียงรวมคำสั่งที่ใช้ในการสร้างบางอย่างแล้วสร้างสคริปต์และเรียกมัน!

ตัวอย่างเช่นใน Visual Studio คุณสามารถดูพารามิเตอร์บรรทัดคำสั่งสำหรับการคอมไพล์ C ++ ในช่อง 'บรรทัดคำสั่ง' หากคุณดูผลลัพธ์ของบิลด์อย่างใกล้ชิดคุณจะเห็นไฟล์ชั่วคราวที่มีบิลด์สคริปต์ที่ใช้ในการรันคอมไพล์

ทุกวันนี้มันเป็นMSBuildทั้งหมดแต่นั่นก็ยังคงทำงานโดย IDE โดยตรง

เหตุผลที่คุณใช้บรรทัดคำสั่งคือคุณกำลังตรงไปที่ต้นทางและข้ามชายกลางคนกลางที่อาจได้รับการอัปเดตหรือต้องการการพึ่งพาจำนวนมากที่คุณไม่ต้องการหรือต้องการบนเซิร์ฟเวอร์ที่ไม่มีหัว ทำหน้าที่เป็นเซิร์ฟเวอร์การรวมต่อเนื่อง (CI) ของคุณ

นอกจากนี้สคริปต์ของคุณทำมากกว่าขั้นตอนที่มุ่งเน้นนักพัฒนาที่ออกแบบมา ตัวอย่างเช่นหลังจากการสร้างคุณอาจต้องการให้ไบนารีของคุณจัดทำและคัดลอกไปยังตำแหน่งพิเศษหรือสร้างแพ็คเกจติดตั้งหรือเครื่องมือเอกสารทำงานบนพวกเขา งานที่แตกต่างกันจำนวนมากดำเนินการโดยเซิร์ฟเวอร์ CI ที่ไม่มีจุดหมายบนเครื่องนักพัฒนาดังนั้นในขณะที่คุณสามารถสร้างโครงการ IDE ที่ทำตามขั้นตอนเหล่านี้ทั้งหมดคุณต้องรักษาสองงานไว้ - โครงการสำหรับนักพัฒนาและอีกงานสำหรับงานสร้าง งานบิลด์บางงาน (ตัวอย่างเช่นการวิเคราะห์แบบสแตติก) อาจใช้เวลานานซึ่งคุณไม่ต้องการให้กับโครงการผู้พัฒนา

ในระยะสั้นมันง่ายกว่า - สร้างสคริปต์เพื่อทำทุกสิ่งที่คุณต้องการและมันง่ายและรวดเร็วในการเริ่มต้นบรรทัดคำสั่งหรือการกำหนดค่าเซิร์ฟเวอร์บิลด์

make

จดจำและพิมพ์ได้ง่ายกว่ามาก

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

และโครงการสามารถมีคำสั่งการรวบรวมที่ซับซ้อนมาก บิลด์สคริปต์ยังมีความสามารถในการคอมไพล์สิ่งที่เปลี่ยนแปลงเท่านั้น หากคุณต้องการสร้างงานทำความสะอาด

make clean

ง่ายขึ้นและเชื่อถือได้มากขึ้นเมื่อตั้งค่าอย่างถูกต้องแทนที่จะพยายามจดจำแต่ละสถานที่อาจมีการสร้างไฟล์กลาง

แน่นอนถ้าคุณใช้ IDE การคลิกปุ่มสร้างหรือล้างข้อมูลก็ง่ายเช่นกัน อย่างไรก็ตามมันเป็นเรื่องยากมากที่จะย้ายเคอร์เซอร์ไปยังสถานที่ที่ระบุบนหน้าจอโดยอัตโนมัติโดยเฉพาะอย่างยิ่งเมื่อสถานที่นั้นอาจเคลื่อนที่หากหน้าต่างเคลื่อนตัวไปมา

คุณจะทำยังไงต่อ อีกวิธีหนึ่งคือการระบุคำสั่งยาวหนึ่งบรรทัดคำสั่ง

อีกเหตุผลหนึ่งที่ makefiles อนุญาตให้มีการรวบรวมเพิ่มขึ้นซึ่งจะช่วยเพิ่มเวลาในการรวบรวมได้มากขึ้น

Makefiles ยังสามารถสร้างกระบวนการสร้างข้ามแพลตฟอร์มได้ CMake สร้างสคริปต์บิลด์ต่าง ๆ ตามแพลตฟอร์ม

แก้ไข:

ด้วย IDE คุณจะเชื่อมโยงกับวิธีการทำสิ่งต่าง ๆ โดยเฉพาะ หลายคนใช้เป็นกลุ่มหรือ emacs แม้ว่าพวกเขาจะไม่ได้มีคุณสมบัติคล้าย IDE หลายคน พวกเขาทำเพราะพวกเขาต้องการพลังที่บรรณาธิการมอบให้ บิลด์สคริปต์จำเป็นสำหรับผู้ที่ไม่ได้ใช้ IDE

แม้แต่ผู้ที่ใช้ IDE คุณอาจต้องการทราบว่าเกิดอะไรขึ้นดังนั้นสคริปต์บิลด์จะให้รายละเอียดเกี่ยวกับการใช้งานต่ำซึ่งวิธีการของ GUI ไม่มี

IDE เองก็มักจะสร้างสคริปต์ภายในเช่นกัน ปุ่ม Run เป็นอีกวิธีในการรันคำสั่ง make

คำตอบข้างต้นครอบคลุมพื้นที่ที่ดีจำนวนมาก แต่ตัวอย่างหนึ่งในโลกแห่งความจริงที่ฉันต้องการเพิ่ม (ที่ฉันไม่สามารถเพิ่มเป็นความคิดเห็นเนื่องจากไม่มีกรรม) มาจากการเขียนโปรแกรม Android

ฉันพัฒนาโทรศัพท์ Android / iOS / Windows วิชาชีพและฉันจะใช้บริการของ Google APIs (ส่วนใหญ่ Google Maps บริการ) จำนวนมาก

ใน Android บริการเหล่านี้ต้องการให้ฉันเพิ่มที่เก็บคีย์หรือไฟล์ ID นักพัฒนาซอฟต์แวร์ประเภทหนึ่งที่บอกกับ Google ว่าฉันเป็นคนที่ฉันพูดว่าฉันเป็นใครในคอนโซลนักพัฒนาซอฟต์แวร์ หากแอพของฉันถูกคอมไพล์ด้วยที่เก็บคีย์อื่นส่วน Google Maps ของแอพจะไม่ทำงาน

แทนที่จะเพิ่มและจัดการ keystores โหลไปยังคอนโซลนักพัฒนาเพียงอย่างเดียวเท่านั้นที่สามารถนำมาใช้ในการอัปเดตแอพได้ฉันได้ใส่ที่เก็บคีย์นี้ใน repo ที่ปลอดภัยของเราและใช้ Gradle เพื่อบอก Android Studio ว่า keystore ใช้ในการสร้าง "debug" หรือ "release" ตอนนี้ฉันต้องเพิ่มที่เก็บคีย์สองตัวลงในคอนโซลนักพัฒนาซอฟต์แวร์ของ Google หนึ่งตัวสำหรับ "ดีบั๊ก" และอีกอันสำหรับ "รีลีส" และสมาชิกในทีมของฉันทั้งหมดสามารถโคลน repo และได้รับสิทธิในการพัฒนาโดยไม่ต้องไปที่ dev คอนโซลและเพิ่มแฮช SHA ของที่เก็บคีย์เฉพาะของพวกเขาหรือแย่กว่านั้นทำให้ฉันจัดการพวกเขา. สิ่งนี้มีประโยชน์เพิ่มเติมในการมอบสำเนาของที่เก็บคีย์ซึ่งสมาชิกในทีมแต่ละคนได้รับซึ่งหมายความว่าถ้าฉันไม่อยู่ในสำนักงานและมีกำหนดการอัพเดตสมาชิกในทีมจะต้องทำตามคำแนะนำสั้น ๆ เพื่อผลักดัน ปรับปรุง

สร้างระบบอัตโนมัติเช่นนี้ช่วยสร้างความสอดคล้องและลดภาระหนี้ทางเทคนิคโดยลดเวลาในการตั้งค่าเมื่อเราได้รับนักพัฒนาใหม่เครื่องจักรใหม่หรือเมื่อเราต้องทำการอิมเมจเครื่องใหม่

สร้างข้อได้เปรียบสคริปต์:

• การเปลี่ยนแปลงจะมีลักษณะเหมือนโค้ด (ตัวอย่างเช่นในคำสั่ง git diff) ไม่เหมือนกับตัวเลือกที่เลือกไว้ในกล่องโต้ตอบ

• การสร้างผลผลิตมากกว่าการสร้างที่เรียบง่าย

ในโครงการก่อนหน้าของฉันฉันได้ใช้สคริปต์สร้างเพื่อ:

• สร้างเอกสารโครงการ (ตาม doxygen)
• สร้าง
• เรียกใช้การทดสอบหน่วย
• สร้างรายงานความครอบคลุมการทดสอบหน่วย
• แพ็คไบนารีลงในไฟล์เก็บถาวรรีลีส
• สร้างบันทึกประจำรุ่นภายใน (ตามข้อความ "บันทึก git")
• การทดสอบอัตโนมัติ

บ่อยครั้งที่คุณสามารถเรียกปุ่ม "สร้าง" ด้วยวิธีอัตโนมัติ (Visual Studio ยอมรับอาร์กิวเมนต์บรรทัดคำสั่งเป็นต้น) ผู้คนเขียนสคริปต์การสร้างทันทีที่พวกเขาต้องการสิ่งที่ปุ่มสร้างไม่สามารถให้ได้

ตัวอย่างเช่น IDEs ส่วนใหญ่จะให้คุณสร้างแพลตฟอร์มได้ครั้งละหนึ่งแพลตฟอร์มเท่านั้น หรือทีละภาษาเท่านั้น จากนั้นมีสิ่งที่คุณทำกับผลลัพธ์ที่สร้างขึ้น: IDE ของคุณสามารถม้วนมันทั้งหมดลงในแพ็คเกจการติดตั้งได้หรือไม่?