เป็นเรื่องที่เกี่ยวกับสายงานที่ทำ ใครหลุดเข้ามาอ่าน อาจจะงงงวย
ความเดิมสองตอนก่อนคือ วิธีติดตั้ง Jenkin และ วิธีใช้ PHPUnit เพื่อทำ Automation Test ซึ่งเราก็ได้เห็นภาพของ CI (Continuous Integration) กันมาแล้ว มาบล็อกครั้งนี้เป็นตอนสุดท้ายของซีรี่ “เริ่มต้นทำ CI/CD” ก็คือ หลังจากเขียนโค้ดและทดสอบผ่านทั้งหมด เราจะให้ Jenkins นำโค้ดที่ทำเข้าสู่ Production Server ให้อัตโนมัติ (Automation Deployment) Continue reading “เริ่มต้นทำ CI/CD – Automation Deployment ด้วย Git และ Jenkins (3 – จบ)” »
บล็อกที่แล้วเขียนเรื่อง วิธีติดตั้ง Jenkin ไว้ เพื่อเตรียมทำ CI (Continuous Integration)
แต่ก่อนจะไปถึงตรงนั้น นอกจากต้องใช้ Version Control เป็นแล้ว ก็ต้องมีวิธีการทดสอบโค้ดที่เขียนก่อน
และคุณประโยชน์ที่เราจะไปใช้ Scrum เพื่อทำ Agile คือ การส่งมอบงาน หรือ Software ที่ใช้ได้ ให้ได้ไวๆ
ดังนั้น การส่งมอบให้ได้ไว คือการทำงานเป็นรอบ และการทำงานเป็นรอบ เราจะได้ผลตอบรับไว (fast feedback) ว่าใช่หรือไม่ใช่ ผิดหรือถูก
เช่นกัน Software ที่ใช้ได้และส่งมอบงานได้ไว ก็ต้องมี Automate Test ที่ทำงานได้แทนเรา และครอบคลุม หนึ่งในนั้นคือ Unit Test Continue reading “เริ่มต้นทำ CI/CD – Automation Testing ด้วย PHPUnit และ Jenkins (2)” »
ตอนแรกว่าจะเขียนรวดเดียวจบถึงวิธีทำ CI/CD (Continuous Integration and Continuous Deployment) ด้วย Jenkins และ Bitbucket แต่พอเขียน Jenkins จบ รู้สึกว่ายาวไปหน่อย เลยขอตัดเอาเป็น Jenkins ก่อนก็แล้วกันนะ
Jenkins เป็น Automation Tools ที่เอาไว้ทำอะไรต่างๆแบบอัตโนมัติ ซึ่งในที่นี้เราเอามันไปใช้ทำ CI/CD เพื่อช่วยชีวิตนักพัฒนาอย่างเราให้สบายขึ้น อบย่างเช่น นักพัฒนาเพียงแค่เขียนโค้ด นำขึ้น Git แล้วให้ Jenkins ทำการทดสอบจากที่เราตั้งค่าไว้ ไม่ว่าจะ Robot Framework หรือ Test Unit ก็ตาม เมื่อผ่านเรียบร้อย ก็นำกลับไป Merge Code เข้า Git หรือจะ Deploy ต่อไปยัง Server ก็ว่ากันไป (ซึ่งผมจะเขียนบล็อกสอนทำตามนี้แหละ) Continue reading “เริ่มต้นทำ CI/CD – วิธีติดตั้ง Jenkins บน Ubuntu (1)” »
ให้คิดกันเล่นๆ ก่อนจะไปเนื้อหาหลัก ถ้าเราเป็นทีม Business ที่จะทำซอฟต์แวร์ขึ้นมาสักตัวหนึ่ง อย่างแรกที่ทำคืออะไรครับ?
… (2 วินาที)
โอเค ทุกคนน่าจะตอบว่า ก็ต้องเก็บ Requirement สิ ว่าต้องทำอะไรบ้าง (ส่วนใครไม่ได้ตอบตามนี้ ผมจะมโนไปว่าตอบก็แล้วกันนะ)
แล้ว Requirement ที่ว่า ก็ต้องมีคุณสมบัติต่างๆ ที่ประกอบกันเป็นซอฟต์แวร์ของเราใช่ไหม หรือที่เรียกกันว่า Feature เช่น อัพโหลดรูปได้ ส่งอีเมลได้ ล็อกอินด้วยเฟสบุ๊กได้ เป็นต้น
ซึ่งในแต่ละ Feature ที่เราเขียนๆกันมา เราต้องคิดต่อใช่ไหมครับว่าจะมีการทำงานอย่างไร?
ใครตอบว่าไม่คิด ก็ให้ลองนึกดีๆ เพราะบางทีเราก็คิดแบบเร็วๆ หรือเห็นภาพตัวอย่างระบบที่เคยเห็นมาก่อน
แต่ถ้าใครคิดละเอียดๆหน่อย จะเขียนไว้หรือวาดรูปออกมาอย่างชัดเจน บางทีเราก็เรียกมันว่า Business Flow, Business Logic ก็แล้วแต่สะดวก แต่ในที่นี้ผมขอเรียกรวมๆ ว่า Flow ก็แล้วกัน
ซึ่งเราเขียนมันออกมาเพื่อให้เห็นการไหลของข้อมูล (Input) เงื่อนไขต่างๆ (Process) และผลลัพธ์ตอนจบ (Output)
โดยที่กล่าวมาทั้งหมด เป็นกระบวนการทาง Business เพื่อตอบว่า เรา “จะทำอะไร (What)”
ตัดฉากมาดูของฝั่งทีม Developer บ้าง, ทุกวันนี้เราสนใจเรื่องของฝั่ง Business หรือไม่?
… (2 วินาที)
ส่วนใหญ่ ถ้ายังทำงานแบบเดิมๆ ซึมๆ ก็มักไม่ค่อยสนใจว่า Business จะทำ Feature พวกนี้ไปเพื่ออะไร ทำไปทำไม หรือมันมีการเชื่อมโยงข้อมูลอย่างไรบ้าง
เพราะเขาเหล่านั้นมักตีขอบเขตตัวเองไว้ว่า ฉันมีหน้าที่แค่หาวิธี “ทำอย่างไร (How)” ที่จะทำ Task งานนั้นให้เสร็จ แล้วก็ก้มหน้าก้มตาเขียนโค้ดให้ได้ตามที่ Business ต้องการ ก็จบ..
การทำงานแบบนี้ มันเลยเกิดปัญหาตามมา คือ ทีม Developer ไม่เห็นหรือไม่สนใจภาพรวมทั้งหมดของซอฟต์แวร์ ไม่มีเป้าหมายร่วมกับทางทีม Business
และพบว่า บ่อยครั้งเมื่อไม่เข้าใจกันของทั้งสองทีม ก็เกิดความไม่ลงรอยกัน เพราะตีความ Requirement ไม่เหมือนกัน
และผลลัพธ์ของมัน คือ ซอฟต์แวร์ (แม้จะทำออกมาดีแค่ไหน) ไม่ตอบโจทย์ทาง Business, ไม่ตรงตาม Requirement และถูกตีกลับมาแก้ไขอยู่ร่ำไป
เสียทั้งเงิน ทั้งเวลา ทั้งอารมณ์ ความสัมพันธ์ของทั้งสองทีม และซอฟต์แวร์ก็อาจทำงานผิดพลาดอีกด้วย
ซึ่งถ้าคุณอ่านมาถึงตรงนี้ แล้วคิดว่า “เออ เจอปัญหาแบบนี้จริงๆ” และอยากหาทางปรับปรุงมันให้ดีขึ้น เราจะทำอย่างไรดี? Continue reading “ATDD – จะทำอย่างไรให้ชี้นกเป็นนก ชี้ไม้เป็นไม้” »
The Nature of Software Development เขียนโดย Ron Jeffries เป็นหนังสือที่พยายามอธิบายการทำซอฟต์แวร์ให้ง่าย และนำเสนอการทำงานเป็นรอบๆ (Iterative) ได้น่าสนใจมาก เน้นให้ผู้อ่านปรับทัศนะคติการทำซอฟต์แวร์ใหม่ ในแบบที่เขาเรียกว่า “The Natural Way” เพราะเขาเชื่อว่ามันเป็นหนทางที่เข้าใจง่าย เน้นการส่งมอบคุณค่าให้ได้ไว และบ่อยๆ
หนังสือเล่มนี้ใช้ภาษาอ่านไม่ยาก คนทั่วไปอ่านได้ เหมือนกำลังฟังลุง Ron บ่นๆ ไปเรื่อยๆ เพื่อปูพื้นฐานและปรับทัศนคติ ใครอ่านที่ผมสรุปไว้และสนใจอยากลองหาฉบับเต็มมาอ่าน ลองดูได้จากลิงค์นี้ครับ The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece
การทำซอฟต์แวร์ขึ้นมาตัวหนึ่ง จะมีหลายกระบวนการ เช่น วางแผน พัฒนา จัดการคนทำงาน เพื่อให้งานมันเสร็จ และผู้ว่าจ้าง หรือลูกค้าเรา สามารถใช้งานซอฟต์แวร์นั้นได้ ซึ่งสิ่งที่เราส่งมอบให้ มันคือสิ่งที่มีคุณค่า เพราะถ้าซอฟต์แวร์ยังเป็นแค่โค้ด หรือยังเล่นไม่ได้ ต่อให้เขียนโค้ดดีแค่ไหน มันก็ยังไร้ค่าใช่หรือเปล่า?
แล้วคำถามต่อไปคือ เมื่อซอฟต์แวร์ มันใช้เวลาผลิตนาน จะให้มันเสร็จไวๆ มอบของ(คุณค่า)ให้ลูกค้าได้เห็นบ่อยๆ จะทำอย่างไรล่ะ? Continue reading “The Nature of Software Development โดย Ron Jeffries” »
