Agile Development Requires High Infrastructure?
อ่านบล็อก GullFOSS เขียนโดยวิศวกรของซันที่ทำ OpenOffice.org ว่าด้วยเรื่อง Experimenting with Agile software development
ติดใจย่อหน้านี้
We found out that an agile development style has high requirements on the building infrastructure:
- New builds are needed at least daily, usually more often.
- Builds need to run absolutely unattended, without any need for human interaction.
This is challenging, when not only compiling and linking, but as well installing an Office, installing an extension, running smoketest, unit tests and other automated tests - and all those on several platforms.
ผมมีประสบการณ์ในสาย Software Engineering มาน้อยมากๆ แต่ที่จับทางได้ก็น่าจะเป็นแบบที่เน้นไว้ คือใช้ automated tools ให้เยอะที่สุดเท่าที่เป็นไปได้ (เพื่อเอาแรงคนไปทำอย่างอื่น) รวมถึงออกแบบ process การทำงานให้ automatic/semantic ด้วยเช่นกัน
บ้านเรายังไม่ค่อยเน้นเรื่องนี้กันเท่าไร (เห็นแต่เถียงกันว่า IDE ของใครเจ๋งกว่า) ที่เห็นเริ่มใช้กันบ้างก็พวก Revision Control แต่อย่าง Bug Tracking, Branch Commit Tracking, Automated Testing Suite, Regression, Build Farm, QA นี้ยังไม่มากนัก มันน่าจะลงทุนสูงแบบในบล็อกข้างต้นว่าไว้ แต่ถ้าผลงานออกมาดีมันก็น่าจะคุ้มไม่ใช่หรือ?
- mk's blog
เค้าคิดว่าเอาเวลามาเขียนโปรแกรม คงจะคุ้มกว่ามานั่งวางระบบพวกนี้
แต่สุดท้ายมันก็จะหนักตอนทดสอบนี่แหละ
spec, test cases, test suite, qa ทั่วไป และเฉพาะเจาะจงอย่าง regression, automated testing suite เท่าที่เห็นมีใช้กันแพร่หลายแล้วนะครับ เรียงตามลำดับ
(ไม่นับซอฟต์แวร์เฮาส์เล็ก ๆ)
ส่วน issue tracking นี่ น่าจะยิ่งแพร่หลายกว่า
ซอฟต์แวร์เฮาส์เล็ก ๆ หลายที่ก็ใช้
บริษัทประเภทอื่น ๆ ก็ใช้ (เช่นที่เกี่ยวข้องกับการบริการ, support center)
ระบบ build ของ eclipse เป็นระบบที่น่าสนใจมาก
ลองหาอ่านดู
ผมคิดว่าเป็นเรื่องปกติที่คนที่ทำ experiment กับเรื่องที่ไม่เคยทำ จะพบว่าการติดตั้ง จัดเตรียม มีความซับซ้อน ยุ่งยาก แต่เมื่อคุ้นเคยหรือทำบ่อยเพียงพอกับโปรเจคต่อๆไปแล้ว เวลาที่ใช้ในการติดตั้ง automated test tools ไม่ได้ใช้เวลานานและทำเพียงครั้งเดียว และกลายเป็นสิ่งที่ขาดไม่ได้ สำหรับทีมพัฒนา เมื่อระบบ build, test เป็นแบบอัตโนมัติ ทีมพัฒนาก็สามารถทำงานได้โดยไม่ต้องกังวล จนกระทั่งมีใคร break build หรือเกิด test failures ขึ้นมา
เรื่องความถี่ในการ build คงต้องขึ้นอยู่กับขนาดระบบที่พัฒนา โปรเจคที่ผมทำเค้าใช้หลัก continuous integration ใช้ cruisecontrol build อัตโนมัติเมื่อมีคน check in code วันหนึ่งมีเป็น 10 builds และแต่ละ build จะมีการรัน unit tests ทั้งหมด ส่วนการ deploy จะทำอย่างต่ำวันละรอบ ส่วนการทำ smoke test, user interface test ก็ใช้ automated user interface testing tools ทำโดยอัตโนมัติ รันเป็นแบ๊กกราวนด์ทิ้งไว้ สามารถลดภาระของ QA ได้มากทีเดียว
