เคล็ดลับในการบรรลุการส่งมอบ "ต่อเนื่อง"


14

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

ระหว่างการทำซ้ำ:

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

ทุกวันจันทร์:

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

ทุกวันอังคาร:

  • ผู้ทดสอบได้ทดสอบการรวมสาขามากที่สุดเท่าที่พวกเขาจะสามารถให้เวลาที่มีอยู่และไม่มีข้อบกพร่องที่รู้จักกันดังนั้นการเปิดตัวจะถูกตัดและผลักออกไปยังโหนดการผลิตช้า

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

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

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


1
นอกจากจะตอบ @ emddudley เกี่ยวกับหนังสือเล่มนี้อย่างต่อเนื่องการจัดส่งผมจะแนะนำให้คุณดู infoq.com/presentations/Continuous-Deployment-50-Times-a-Dayการนำเสนอที่น่าสนใจมากเกี่ยวกับการใช้งานอย่างแท้จริงหลายครั้งต่อวันเข้าไปในที่เกิดขึ้นจริงสด การผลิต
sdg

คำตอบ:


6
  • พบข้อบกพร่อง "บอบบาง" ในการผลิตที่ไม่ได้ระบุไว้ในสภาพแวดล้อมการจัดเตรียม - หนึ่งในโครงการที่มีปัญหาเช่นนี้ที่ฉันเคยเห็นมานี้ค่อนข้างประสบความสำเร็จในการจัดการโดยชั้นเชิงฉันจะเรียกสองประเด็น ฉันหมายถึงข้อผิดพลาดเช่นนั้นพวกมันสร้างตั๋วสองใบในตัวติดตามปัญหา: ตัวหนึ่งถูกกำหนดให้กับนักพัฒนาเพื่อแก้ไขรหัสอีกตัวหนึ่งเพื่อผู้ทดสอบเพื่อออกแบบและสร้างการทดสอบการถดถอยหรือการเปลี่ยนแปลงในสภาพแวดล้อมการแสดงละคร ที่ช่วยในการแสดงละครใกล้พอที่จะแยง

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

  • สาขาฟีเจอร์ที่บังคับใช้อย่างกระตือรือร้น - นั่นหมายความว่าเมื่อก่อนคุณเคยลองทำงานในสาขาเดียวและพบว่ามันด้อยกว่าหรือไม่ ถ้าใช่ให้ข้ามส่วนที่เหลือ มิฉะนั้นลองทำงานกับสาขาเดียว (ถ้าจำเป็น google สำหรับกลยุทธ์การแยกสาขา "สาขาการพัฒนา"หรือกลยุทธ์การแยกย่อย "ลำต้นที่ไม่เสถียร" เพื่อดูรายละเอียด) หรือถ้าคุณใช้ Perforce ให้ค้นหาเว็บสำหรับแนวทางของ Microsoft เกี่ยวกับการแยกและรวมเข้าด้วยกัน ฉันลองพูดแบบนั้นเหรอ? คำขอโทษที่เหมาะสมควรเป็นแบบทดสอบ : ฉันหมายถึง 1) วางแผนเวลาและวิธีการในการวัดว่าสาขาเดียวดีกว่าหรือไม่กว่าที่คุณมีอยู่ตอนนี้และ 2) วางแผนสำหรับเมื่อใดและอย่างไรคุณจะเปลี่ยนกลับเป็นสาขาคุณลักษณะในกรณีนี้ การทดสอบล้มเหลว


PS

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


ปรับปรุง

<คัดลอกจากความคิดเห็น>

ฉันรับรู้การแก้ปัญหาร้อนบ่อยๆเพื่อเป็นอาการของท่อทดสอบที่ขาด - นี่ไม่ใช่อย่างนั้นหรือ ไม่ว่าจะด้วยวิธีใดพวกเขาต้องการการเปิดตัวซ้ำ ๆ เพื่อรับการแก้ไขด่วนทำให้ทำงานได้มากขึ้นสำหรับทีม ops นอกจากนี้การแก้ไขร้อนมักจะเขียนรหัสภายใต้ความกดดันครั้งรุนแรงซึ่งหมายความว่าพวกเขาน่าจะมีคุณภาพต่ำกว่างานปกติ

</ คัดลอกจากความคิดเห็น>

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

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

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

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

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

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


Update2

<คัดลอกจากความคิดเห็น>

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

</ คัดลอกจากความคิดเห็น>

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

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

BTW แม้จะมีการตรวจจับที่เร็วกว่าที่ด้านข้างของพวกเราเราจัดการให้มีช่วงชีวิตบั๊กเฉลี่ยเท่ากัน (ช่วงชีวิตคือเวลาระหว่างการแนะนำและการแก้ไขไม่ใช่ระหว่างการแนะนำและการตรวจจับ) อาจเป็นไปได้ว่าเรามีข้อได้เปรียบเล็กน้อยที่นี่เนื่องจากมีการทำซ้ำที่สั้นกว่าและปล่อย slipped น้อยกว่าเราสามารถอ้างได้ว่าโดยเฉลี่ยการแก้ไขของเราเข้าถึงผู้ใช้เร็วกว่าของพวกเขา

สรุปแล้วฉันยังเชื่อว่าการแยกรหัสเผยแพร่มีโอกาสที่ดีขึ้นในการปรับปรุงประสิทธิภาพการทำงานของทีม


ในความคิดเพิ่มเติม ...

  • การแยก codeline ของการปล่อยมีโอกาสที่ดีกว่า - เมื่ออ่านใหม่ฉันรู้สึกว่านี่อาจสร้างความประทับใจที่ฉันไม่แนะนำให้คุณลองทดสอบซ้ำ ฉันต้องการทำให้ชัดเจนอย่างสมบูรณ์แบบที่ฉันไม่ต้องการ

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

BTW เกี่ยวกับอุปสรรคสิ่งที่ควรติดตามเพิ่มเติมในกรณีนั้นคือปัญหาเช่นความล้มเหลวในการทำซ้ำข้อผิดพลาดที่ด้าน dev และสายเพื่อค้นหา / ล่าช้าเพื่อตรวจสอบการแก้ไขที่ด้านผู้ทดสอบ อาจติดเหล่านี้ของคุณท่อเกินไปเช่นมันเกิดขึ้นตอนนี้มีโปรแกรมแก้ไขด่วน


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

1
@maple_shaft เป็นครั้งแรกที่ฉันเห็นข้อผิดพลาดที่เปิดในตัวติดตามเทียบกับชุดทดสอบคือในปี 2002 หรือ 2003 และดูเหมือนว่าจะเป็นการฝึกที่สร้างขึ้นในทีมที่ฉันเข้าร่วมตอนนั้น ในฐานะที่เป็นข้อบกพร่อง diffs ระหว่างแยงและการแสดงละครการกำหนดเป้าหมายเหล่านี้แน่นอนดูเหมือนนิยายกับผมตั้งแต่ครั้งแรกที่ผมเคยเห็นมัน (และรู้สึกประหลาดใจจริงๆ) น้อยกว่า 2 ปีที่แล้ว
ริ้น

1
@gnat ดูเหมือนสามัญสำนึกซึ่งเป็นสาเหตุที่ฉันสงสัยว่าทำไมฉันไม่เคยได้ยินมาก่อน ตอนนี้ที่ฉันคิดเกี่ยวกับมันแม้ว่าจะทำให้รู้สึกเพราะทุกกลุ่ม QA ที่ฉันเคยทำงานด้วยดูเหมือนมีความสุขอย่างสมบูรณ์เพื่อกำจัดแมลง
maple_shaft

1
@maple_shaft lol ยอมรับด้วยวิธีนี้ดูเหมือนว่าจะหายากอย่างไม่สมควร คุณทราบหรือไม่ว่าวิธีการหนึ่งนั้นสามารถสร้างบั๊กได้ไม่เพียง แต่กับผู้ทดสอบเท่านั้น แต่ยังสำหรับนักเขียน doc / spec ด้วย? - Build 12 of Dev Guide พูดว่า "black" ที่หน้า 34 บรรทัดที่ 5; ควรเป็น "สีขาว" - มอบหมายให้ John Writer - แก้ไขในรุ่น 67. - ตรวจสอบแก้ไขในรุ่น 89 โดย Paul Tester
ริ้น

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

8

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

IMHO กำหนดการแน่นเกินไป

คุณสามารถเพิ่มความครอบคลุมของรหัสได้ด้วยการเขียนการทดสอบหน่วยที่มีประสิทธิภาพมากขึ้นและการทดสอบการรวมสภาพแวดล้อมที่เฉพาะเจาะจง

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

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

โดยรวมแล้วดูเหมือนว่าคุณจะมีแนวปฏิบัติที่ดีและคุณมีระบบที่ดีในการจัดการกับวงจรการปล่อยที่รุนแรง คุณดูเหมือนจะอยู่บนเส้นทางที่ถูกต้อง


ใช่ หนึ่งสัปดาห์กับผลิตภัณฑ์ขนาดใหญ่ในภาษาที่คอมไพล์จำเป็นต้องมีการทดสอบการรวมเข้าด้วยกันแบบลมแรงไม่ต่อเนื่อง แต่มันก็ลดลง รักษาให้มากเกินไปและคุณจะได้สัมผัสกับการตายของงาน!
ZJR

+1; เราดำเนินการทำซ้ำสามสัปดาห์ในขณะนี้และพบว่าทำงานได้ดี
Duncan Bayne

@ZJR คุณช่วยขยายความหมายของคุณในบริบทนี้ได้ไหม?
Ben

@Duncan, การทำซ้ำของเรามี 2 สัปดาห์ แต่เรากำลังพยายามที่เดียวสัปดาห์เพิ่มขึ้น อาจเป็นไปได้หรืออาจเป็นไปไม่ได้ / เป็นความคิดที่ไม่ดี คิดว่าการเพิ่มสัปดาห์เดียวจะมีรหัสใหม่น้อยลงและด้วยเหตุนี้จะมีปัญหาน้อยลง
Ben

1
@Ben Aston จำนวนของรหัสไม่ได้สร้างปัญหากำหนดเวลาไม่สมจริงความเครียดและความคาดหวังสูงสร้างปัญหา
maple_shaft

1

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

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

ฉันคิดว่ามีความเครียดมากขึ้นในการพยายามที่จะทำให้ลำตัว / เจ้านายที่แตกหักมีเสถียรภาพมากกว่าที่มีอยู่คุณรู้เพียงแค่ทำให้มันมั่นคง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.