เรื่องมันมีอยู่ว่า ผมจำได้ดีเลยวันนั้นเป็นวันหนึ่งในฤดูหนาว ที่อากาศหนาวกว่าทุกๆวัน……ไม่ใช่ละ…นิยายผีญี่ปุ่นปะนิ….เอาใหม่….จริงๆสิ่งที่อยากจะเอามาเล่าในวันนี้เป็นสิ่งที่ใช้ใน Doppio มาประมาณสักปีนึงแล้วแหละ แต่ไม่มีเวลาได้มาเขียนมาแชร์ ช่วงนี้พอมีเวลา เลยอยากเอามาแชร์ให้เพื่อนๆได้อ่านกัน เรื่องมีอยู่ว่า ตอนที่ Doppio ตั้งบริษัทขึ้นมาแรกๆ แล้วเริ่มมีงาน automation ของ Mobile application เข้ามา ด้วย Concept ว่า Automation ที่ทำไปต้องใช้งานได้จริง มี reliability และ stability ที่ดี เราจึงต้องมีการ setup CI ขึ้นมาเพื่อ keep running test เพื่อจุดประสงค์

1. ทำให้แน่ใจว่า script ที่เรา develop ยังใช้งานได้อยู่ และมีความ stable
2. เราสามารถนำผลการรันรอบล่าสุดไปใช้ได้เลยหากมีการต้องทำ regression test ในวันนั้น (โดยต้องมีการ cross check timeline/version การdeploy กับ Developer อีกครั้งก่อนนำไปใช้)

และเนื่องด้วยพอเป็น mobile application automation ซึ่งเราใช้ Appium เป็น framework หลัก เราเลยจำเป็นที่จะต้องมีเครื่องที่รัน Emulator หรือ Simulator ของ iOS / Android ไว้ทำการรัน ในยุคแรกเราก็ใช้วิธีแบบลูกทุ่งๆ คือ ซื้อ mac mini มาวางไว้สำหรับแต่ละโปรเจคที่ต้องทำ CI เพราะงั้นในยุคแรกๆ ไม่แปลกที่เราจะมี conversation ว่า เฮ้ยๆ ลูกค้า A นี่ใช้ Mac mini เบอร์ไรนะ เพราะว่า Mac mini ที่เราซื้อมาจะถูก allocate ให้โปรเจคแต่ละโปรเจคของใครของมัน

เวลาก็ผ่านไปอย่างรวดเร็ว ลูกค้าของบริษัทก็เยอะขึ้นเรื่อยๆ จนเราเริ่มมี Mac mini เยอะขึ้นๆ และเราก็เริ่มมีคำถามกับตัวเองว่า เราต้องมี Mac mini เยอะขนาดนี้เลยเหรอวะ นี่เราใกล้จะเปิด Apple store ได้แล้วนะ เราก็เลยมานั่งดูกันอย่างจริงจังๆว่า Mac mini 1 เครื่องของเรา จริงๆ แล้วในแต่ละวัน เราใช้งานมันมากน้อยแค่ไหน แล้วเราก็พบว่า จริงๆ Mac mini แต่ละเครื่องของเรา เราใช้งานมันไม่ได้ตลอด 24 ชั่วโมง บางเครื่องอาจจะใช้อยู่ 4 ชั่วโมง บางเครื่องใช้อยู่ 8 ชั่วโมง ขึ้นกับว่าโปรเจคที่ใช้งาน Mac mini พวกนั้นอยู่ มันรันเทสนานแค่ไหน และรันเทสถี่แค่ไหน (ในทางเทคนิค เราจะเรียกสิ่งนี้ว่า utilization rate ซึ่งถ้าเจ้า rate นี้ใกล้ 100% แค่ไหน ก็แปลว่าเราใช้เครื่องคุ้มแบบสุดๆ เต็มเม็ดเต็มหน่วย) ทีนี้เราก็เลยนั่งคิดต่อว่า ทำยังไงที่จะใช้ Mac mini ที่มีอยู่ให้คุ้มค่าที่สุด และซื้อเครื่องเพิ่มเมื่อมันจำเป็นจริงๆ เท่านั้น โดยปัญหาที่เราต้องแก้ก็คือ ในช่วงเวลาใดเวลาหนึ่ง ทำยังไงให้โปรเจค X มันรู้ว่าเครื่อง Mac เครื่องนี้มันมีโปรเจค Y ใช้อยู่ และไม่ไปแย่งเครื่องกันใช้จนทำให้ resource ของเครื่อง Mac นั้นมันไม่พอ คิดไปคิดมา มันก็เลยเกิดไอเดียว่า มันต้องมีคนกลางคนนึงเป็นคนคอยคุมการใช้เครื่องเหล่านี้ โดยเราคิดโมเดลคล้ายๆกับโมเดลการยืมหนังสือของห้องสมุด แล้วจำลองว่า Emulator / Simulator แต่ละเครื่องที่รันอยู่ใน Mac mini นั้น ก็เปรียบเหมือนกับหนังสือ ถ้าใครอยากจะหยิบไปใช้งาน ก็จะต้องมาแจ้งการยืม กับ บรรณารักษ์ห้องสมุดในตอนที่ยืม และ ในตอนที่คืนหนังสือ ก็ต้องมาคืนกับบรรณารักษ์ห้องสมุดเช่นกัน ห้ามมีใครคนใดคนนึงเดินไปหยิบหนังสือจากชั้นหนังสือได้ด้วยตัวเอง เราเรียกสิ่งนี้ว่า Farm manager (ใน Doppio เรียกสิ่งนี้ว่า Woody) Concept ของ Woody ก็โชว์แบบง่ายได้ตามรูปด้านล่าง

จากภาพด้านบนจะเห็นว่า ตัว Automation code จะมีหน้าที่ที่จะต้องส่ง API request มาขอยืมเครื่องจาก Farm manager โดยระบุข้อมูลคร่าวๆดังนี้

1. API key (เพื่อแสดงสิทธิ์การใช้งานของตัวเอง โดยแต่ละ API key จะมีโควต้าสูงสุดที่ใช้งานเครื่องได้พร้อมๆกัน กำหนดไว้อยู่)
2. Spec ของเครื่องที่ต้องการจะยืมเช่น Android / iOS , Version , ขนาดหน้าจอเป็นต้น

หลังจากนั้นสิ่งที่ตัว Farm manager ทำคือการทำสิ่งที่เรียกว่า Manage and prepare นั่นคือการตรวจสอบดูว่า ใน Farm มี Mac mini เครื่องไหนที่ยังว่างอยู่ และทำการส่งคำสั่งไปจัดเตรียมเครื่อง emulator เหล่านั้นให้เรียบร้อย ไม่ว่าจะเป็นการ Start Appium server , Start emulator , จัดเตรียม live view (เดี๋ยวจะอธิบายทีหลังว่ามันคืออะไร) เมื่อทำการ Manage and prepare เสร็จเรียบร้อยแล้ว ก็จะทำการเอาข้อมูลของ Emulator ตอบไปใน Response ของ API request ที่ตัว automation code เรียกใช้งานมา และหลังจากนั้นตัว Automation code ก็นำข้อมูลเหล่านั้นไปใช้งานเพื่อ connect ไปหา emulator ที่ตัวเองยืม โดยหลังจากที่ตัว Automation code ใช้งานเสร็จแล้ว ก็จะมีการยิง API request กลับมาหาตัว Farm manager อีกครั้ง เพื่อทำสิ่งที่เรียกว่า Return process เพื่อให้ Farm manager นำเครื่อง emulator กลับเข้าสู่สถานะ Free อีกครั้ง จะเห็นว่า สิ่งที่เราได้เพิ่มขึ้นมาจากการมี farm manager คือ สองอย่าง

1. Utilization ของ เครื่อง Mac mini เพราะเราสามารถใช้งาน Mac mini ได้คุ้มค่าขึ้นจากการที่มี farm manager คอยจัดการ
2. Scalability จากเดิมที่ถ้าไม่มี farm manager คอยจัดการ ในหนึ่งโปรเจค เราอาจจะมี mac mini ให้หนึ่งเครื่อง เราอาจจะรัน parallel สูงสุดได้แค่ 3 emulators (เท่าที่สังขารของ mac mini เราจะอำนวย) แต่ตอนนี้ด้วยการที่เรามี farm manager เราสามารถทำให้เทสของเรารันกระจายไปบน mac mini 5 เครื่องก็ได้ (โดยในเครื่องเดียวกัน ก็อาจจะมี emulator ของโปรเจคอื่นรันอยู่ด้วย) ทำให้การ scale เครื่องขึ้นทำได้ง่ายมากขึ้น

ปัญหาคนไม่คืนหนังสือ

ปัญหาคลาสสิคของห้องสมุด (แม้ทั้งผมและทีม engineer ที่เขียนเจ้า framework นี้ขึ้นมาจะไม่เคยประกอบอาชีพเป็นบรรณารักษ์ก็ตาม) คือการที่คนยืมหนังสือไปแล้วไม่คืน ยืมแล้วหายไปเลย ไม่มี ไม่หนี ไม่จ่าย ไม่ปรากฎตัว ซึ่งถ้าเกิดปัญหานี้ขึ้นกับตัว framework เราสิ่งที่จะเกิดขึ้นก็คือ เครื่องไม่พอนั่นเอง คือ เวลามีใครจะมายืมเครื่อง ตัว Farm manager ของเราจะตอบว่า เครื่องไม่พอจ้าาาา วันหลังค่อยมาใหม่น้า แบบนี้อยู่ร่ำไป เราก็เลยสร้างโปรแกรมเล็กๆขึ้นมาอีกตัว ให้ Farm manager เราเรียกสิ่งนี้ว่า Auditor โดยเจ้าตัว Auditor นี้จะทำหน้าที่คอยตรวจตรา Farm ว่า มี Emulator / Simulator ตัวไหนที่โดนยืมไปแต่ไม่ได้มีการใช้งานหรือเปล่า ถ้าตรวจเจอปุ๊ป สิ่งที่ Auditor ทำคือการ Force return หรือแปลเป็นไทยง่ายๆคือ ยึดคืนนั่นเอง

ทำไปทำมาบานปลายฟีเจอร์มากขึ้นเรื่อยๆ

ตอนแรกที่ทำออกมาตัว Woody นี่ก็ประสบความสำเร็จดี utilization rate ของเครื่อง Mac สูงขึ้นและเราใช้เครื่อง Mac กันได้คุ้มค่ามากขึ้น หลังจากนั้นก็เริ่มมี request เพิ่มมาว่า อยากดูหน้าจอของมือถือตอนที่มันรัน Automate อยู่ได้ไหม บางทีมันรันแล้วตาย แล้วมันจินตนาการยากว่ามันตายยังไง อยากเห็นตอนรัน มันก็เลยเกิดฟีเจอร์ live view ขึ้นมาเพื่อให้เราสามารถเข้าไปดูหน้าจอสดๆ ตอนที่มันรันได้สำหรับแต่ละ emulator หลังจากนั้นไม่พอ ก็มี request ต่อมาอีกว่า เนี้ยบางทีมันรันต่อไม่ได้ อ่ะ อยากลองเอาเม้าส์ไปกดตอนจังหวะนั้นเลยว่ามันเป็นบัคหรือเปล่า ดูอย่างเดียวไม่พอ แต่อยาก control ได้ด้วย ทีมงานเราก็ทำเพิ่มไปอีกเป็นฟีเจอร์ live control ทำไปทำมาบานปลายกลายเป็น website ไว้ ใช้ in house mobile farm อย่างที่โชว์ด้านล่าง

ทำไมไม่ใช้ On Cloud Mobile farm service

เป็นคำถามที่หลายมักจะถามว่า มีบริการ Mobile farm service มากมายไม่ว่า เช่น pCloudy, AWS mobile farm, browser stack , lambda test ต่างๆ ทำไมเราถึงไม่ไปใช้ service พวกนี้ที่มีอยู่ อันนี้ต้องบอกก่อนว่า ไม่ได้บอกว่า บริการพวกนี้ไม่ดี เพียงแต่จากประสบการณ์และลักษณะการใช้งานที่เราเคยเจอคือ ราคาของบริการพวกนี้ค่อนข้างแพงถึงแพงมาก สำหรับเรา เนื่องจากส่วนใหญ่มักเป็นบริการที่ใช้ Real device ในการให้บริการ และอย่างที่สองที่เป็นปัจจัยหลักเลยคือ บริการพวกนี้ส่วนใหญ่มักมี Data center อยู่ในต่างประเทศ (ใกล้สุดก็ Singapore) ทำให้บางที latency เวลาใช้งานค่อนข้างสูงในการส่งคำสั่งแต่ละคำสั่งกลับไปกลับมา ระหว่างเครื่องที่รันเทสกับเครื่องที่ทำหน้าที่เป็น emulator ทำให้เกิดปัญหา เทสรันช้า หรือเกิดความ Flaky สูง (บางเจ้าอาจจะมีบริการให้ upload test script ทั้งยวงขึ้นไปรันบนเครื่องเค้าเลย ซึ่งก็ช่วยแก้ปัญหาตรงนี้ได้ แต่ส่วนตัวเราไม่ค่อยชอบท่านี้เท่าไหร่ เนื่องจากเวลาจะทำการรัน parallel มันต้องมีการทำ shading แบ่งงานที่จะรันตั้งแต่ก่อนรัน เพื่อแยกไปรันในแต่ละเครื่อง)

สุดท้ายแล้วขอขายของหน่อย

หลังจากที่ทำใช้ภายในบริษัทมาสักพัก ก็มีลูกค้าหลายคนทั้งที่เป็นลูกค้าของ Doppio อยู่แล้วและไม่ได้เป็น เข้ามาถามว่า อยากใช้บ้างขอเช่าใช้ด้วยได้ไหม ซึ่งก็มีลูกค้าหลายเจ้าที่เช่าใช้งานอยู่ สำหรับใครที่สนใจหา Mobile farm เพื่อรัน CI ของ automation test ตัวเอง ก็ลองติดต่อมาสอบถามได้นะคร้าบ ที่ connect@doppiotech.com จ้าาาาาา

สุดท้ายแต่ไม่ท้ายสุด แม้เราจะสาธยายมายืดยาวถึงวิธีการทำงานของ Framework และไอเดียเบื้องหลังต่างๆ แต่สิ่งเหล่านี้จะเกิดขึ้นมาไม่ได้เลย และคงเป็นแค่ไอเดียบนกระดาษแผ่นนึง หากไม่มีน้องๆ ในทีม Doppio ที่ช่วยกันสร้างและพัฒนาสิ่งเหล่านี้ให้เกิดขึ้น เก่งมากจร้าาาา หวังว่าบทความนี้คงเป็นประโยชน์กับใครหลายๆคนนะครับ วันนี้ลาไปก่อน บ๊ายบาย