Software Configuration Management

จาก วิกิตำรา
ข้ามไปยัง: การนำทาง, ค้นหา

Software Configuration Management (SCM) การเปลี่ยนแปลงเป็นสิ่งที่ไม่อาจหลีกเลี่ยงได้เลย เมื่อมีการพัฒนาซอฟต์แวร์เกิดขึ้น ซึ่งอาจเนื่องด้วยเหตุผลที่ว่า มีการเปลี่ยนแปลงความต้องการของลูกค้า ตัวองค์กรเอง (Requirement) หรือตัวนักพัฒนานั้นมีความต้องการที่จะพัฒนาหรือปรับปรุงตัวซอฟต์แวร์นั้นขึ้นมาใหม่ และเมื่อเกิดการพัฒนาซอฟต์แวร์ขึ้นย่อมจะทำให้มีผลกระทบต่อชิ้นงานเดิม (Project) ในทุกส่วน ไม่ว่าจะเป็น System Model , Source Code,Document แล้วองค์กรหรือตัวนักพัฒนาซอฟต์แวร์เองนั้นจะมีวิธีการรับมือต่อการเปลี่ยนแปลงที่เกิดขึ้นได้อย่างไร SCM คือคำตอบในการรับมือกับปัญหานี้ คำนิยามของ SCM ( Software Configuration Management ) " SCM is the discipline of managing and controlling chage in the evolution of Software System " From IEEE Standare 1042-1987 SCM คือ ข้อกำหนดเพื่อสร้างมาตรฐานในการจัดการและควบคุมการเปลี่ยนแปลงในส่วนของวิวัฒนาการของการพัฒนางานด้านซอฟต์แวร์

วัตถุประสงค์ของ SCM เพื่อสร้างมาตรฐาน และสามารถบำรุงรักษาความถูกต้องของตัวผลิตภัณฑ์ทางด้านซอฟต์แวร์ในทุกวัฏจักรการทำงาน โดยหลักสำคัญ SCM นั้นตั้งใจที่จะลดความสับสนและข้อผิดพลาดต่างๆที่เกิดขึ้น อันเนื่องมาจากเกิดความแตกต่างในแต่ละเวอร์ชันของซอฟต์แวร์ เหตุผลที่มีการจัดทำ SCM • เพื่อเตรียมพร้อมรับมือการควบคุมการเปลี่ยนแปลงหลายอย่างที่จะเกิดขึ้น • ช่วยในการประสานงานของนักพัฒนาแต่ละคน ที่ต้องทำงานส่วนของชิ้นงาน (Project) เดียวกัน • เพื่อเตรียมข้อมูลเกี่ยวกับสถานะปัจจุบันของการออกในแต่เวอร์ชัน พร้อมทั้งการแก้ไขข้อผิดพลาดที่เกิดขึ้น (Bug Fixes) • เพื่อเตรียมการสำรอง หรือกู้ข้อมูลงานด้านซอฟต์แวร์ เมื่อเกิดปัญหาฐานข้อมูลล่ม หรือเกิดความเสียหายขึ้นในการพัฒนางานด้านซอฟต์แวร์ ความสามารถของ SCM • Version Control (ความสามารถหลักของ SCM) มีการสร้างกลไกการที่จะสามารถติดตาม และบันทึกประวัติการเปลี่ยนแปลงที่เกิด ขึ้นเกี่ยวกับตัวผลิตภัณฑ์ทางด้านซอฟต์แวร์ ตลอดวัฎจักรของการพัฒนาซอฟต์แวร์ พร้อมทั้งระบุและรวบรวมการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นเข้าด้วยกัน • Change Management การควบคุมการเปลี่ยนแปลง จะทำโดยมีการจัดการที่พักข้อมูล(Repository) เก็บ ในแต่ละองค์ประกอบ (Component) ของซอฟต์แวร์ โดยวิธีการเก็บนั้นจะจัดเก็บเฉพาะความแตกต่างในองค์ประกอบของตัวผลิตภัณฑ์ซอฟต์แวร์ และเวอร์ชันของซอฟต์แวร์ โดยความรักษาความปลอดภัยในทรัพย์สินทางซอฟต์แวร์ o ในแต่ละเวลา ที่มีการเปลี่ยนแปลงไฟล์ การ Revision ก็จะทำงานทันที เช่น foo.1 , foo.2 , foo.3 , …. o ประวัติ ( History ) จะบันทึกเรคคอร์ดว่ามีใครที่ทำการเปลี่ยนแปลง หรือมีการ Revision ณ เวลาใด พร้อมทั้งมีหมายเหตุระบุเมื่อมีการเปลี่ยนแปลงเกิดขึ้น o Deltas คือ มีการจัดเก็บเฉพาะความแตกต่างระหว่าง 2 Revision โดยไม่ได้ระบุเนื้อหาในส่วนอื่นๆ (ซึ่งสามารถลดพื้นที่ในการจัดเก็บได้ถึง 98 %) • Configuration Control ใช้เป็นมาตรฐานในการระบุเวอร์ชันของแต่ละตัวผลิตภัณฑ์ • Build Management ช่วยนักพัฒนาในส่วนการทำงานต่างๆ โดยทั่วไป o สร้างและพัฒนาข้อกำหนดในการพัฒนางานด้านซอฟต์แวร์ ( Building and rebuilding a configuration ) o สนับสนุนการทำงานแบบ Workspace ( Workspace Support ) o มีลักษณะการทำงานแบบ Concurrent ( Concurrent Working ) • Process Management

Versioning Control ผมคิดว่า คำว่า Versioning Control (VC) น่าจะคุ้นหูมากกว่า configuration management ซึ่งจะว่าไปแล้วก็คือเรื่องเดียวกัน แล้วแต่ว่าจะเรียกยังไง แต่ที่เรียกว่า Configuration Management นั้นก็เพราะต้องการที่จะเน้นให้เห็นชัดเจนว่านอกจาก program ที่จะต้องมีเลข version แล้ว ทุก artifact หรือ item ที่เกิดขึ้นใน project จะต้องมีการกำกับ version ทั้งหมด ไม่ว่าจะเป็น file ต่างๆ, source code, requirement, bug, issue และอื่นๆ เมื่อมี version ก็แสดงว่ามี history ซึ่งแต่ละ history ของแต่ละ artifact มีความแตกต่างกันอย่างไรในแต่ละ version และ program แต่ละ version ประกอบด้วย artifact อะไรบ้าง version ไหนบ้าง ทั้งหมดเราเรียกรวมกันว่า Configuration Management ครับ Common problems Related with SCM ก่อนที่จะลงรายละเอียดของ SCM ลองมาดูปัญหา classic ที่เกิดขึ้นกันก่อนครับ • การรวบรวม source code จากทุกคนมา build เป็นงานที่ใช้เวลามาก ลองนึกดูว่าถ้าคุณเป็นคนที่ต้อง build code และ deploy โดยต้องรวบรวม code ทั้งหมดจาก programmer ทุกคน มันวุ่นวายแค่ไหน เพราะเมื่อเอา code มารวมกัน คุณต้องคอยระวังไม่ให้ code ที่มีหลายๆ คนแก้โดนทับแล้ว code นั้นหายไป • Source code ที่เราเขียนไปแล้ว โดน code ที่อยู่กับคนอื่น write ทับเวลาที่เอามารวมกัน มาจากข้อแรกครับ ถ้าแค่ 3 คนก็ไม่เท่าไหร่ ถ้า 5 คน 10 คน หรือ 30 คน โอกาสที่จะเกิดความผิดพลาดก็มากขึ้นเรื่อยๆ • การ compare code ทำได้ลำบาก เพราะเมื่อมี code ที่หลายคนแก้ file เดียวกัน ก็ต้อง compare ไม่ให้เกิดปัญหา 2 ข้อที่ว่ามา ก็ต้องอาศัย tool • แก้ code ใน version เก่า กรณีนี้ก็จะคล้ายกับกรณีที่ผ่านมา คือแทนที่จะแก้ code ใน version ล่าสุด แต่กลับแก้ code version เก่าที่เครื่องตัวเอง เพราะอาจจะมีคน update code file นั้นไปแล้ว • เกิด bug ที่แก้ไปแล้วกลับมาอีก ปัญหาก็มาจากการเอา code version เก่าของคนอื่นทับลงไปใน version ใหม่นั่นแหละครับ • Code อยู่กับทุกคนเลย ไม่สามารถกำหนด security และ privacy ได้ และตามไม่ได้ว่าใครเอา code file ไหนไปใช้ได้ (ที่จริงก็ตามได้นะ เพราะทุกคนมีทุก file เลย ไม่ต้องคิดมาก -_-!) • บอกไม่ได้ว่าใครแก้ file นั้นบ้าง แล้วที่แก้ แก้ไปตรงไหนบ้างในแต่ละ version เพราะบางครั้งเราต้องรู้เหตุผลของการเปลี่ยน code เช่น ทำไมถึงเปลี่ยน algorithm จากของเดิมเป็น code ใหม่ เพราะมันกระทบกับจุดอื่น ทำให้เกิด bug ขึ้นมา (ไม่ได้จับผิดนะครับ แต่เพื่อป้องกันไม่ให้เกิดปัญหาเดิมได้อีก) • ไม่สามารถ build binary ของ version เก่าได้ เช่น ในระหว่างที่กำลังพัฒนา 2.0 ต้องการถอยกลับมาตั้งต้นที่ 1.0 เพื่อแตกออกไปเป็นอีก product หนึ่ง แต่ code ตอนนี้มี code ของ feature ใหม่ๆ ปนลงไปหมดแล้ว ต้องถอด code ใหม่ออกซึ่งก็ทำให้เกิด bug ตามมาอีกมากมายและใช้เวลาเยอะ • เมื่อมีการแจ้ง bug เข้ามา ระบุไม่ได้ว่า bug นั้นเกิดที่ version ไหน เพราะเป็นไปได้ว่า bug ที่เกิดขึ้นได้ถูก fix ไปแล้วและ user ใช้ version เก่า แต่เนื่องจากไม่ได้ทำ CM จึงไม่มีการ track issue ต่างๆ ที่เกิดขึ้นในแต่ละ version • ต้องการ merge เอา project 2 ตัวเข้าด้วยกัน เช่น Windows XP ออก SP1 สังเกตุว่าตัว SP1 จะมีขนาดเล็กกว่า Windows ทั้งตัว และจะมี Windows XP + SP1 ที่ install แล้วเป็น SP1 เลยโดยไม่ต้องมา patch ทีหลัง code ของ SP1 จะต้องเป็นชุดเดียวกัน เพราะถ้าต้องเขียนทั้ง Windows + SP1 และ SP1 เปล่าๆ แยกกัน จะเสียเวลา และมี code ที่ duplicate กัน 2 ที่ ถ้าไม่มี SCM การ merge code แทบจะเป็นไปไม่ได้เลย ปัญหาเหล่านี้เกิดขึ้นเพราะไม่ได้มีการบริหารจัดการที่ดีกับ artifact ต่างๆ ที่เกิดขึ้นในระหว่างการพัฒนาซอฟท์แวร์ ซึ่ง Configuration Management จะเป็นกระบวนการที่จะช่วยจัดระเบียบสิ่งต่างๆ ให้เข้าที่เข้าทาง การทำ CM นั้นต้องอาศัย software เข้ามาช่วย เพราะการทำ version control กับทุก artifact นั้น เป็นงานที่เปลืองแรงและเสียเวลามาก ต้องอาศัยคนกำหนด standard และทำเอกสารมากมาย ซึ่งรายละเอียดจะว่าในหัวข้อของ SCM ต่อไป แต่ถ้าใช้ tool แล้ว tool เหล่านั้นจะทำเรื่องต่างๆ ให้เราอัดตโนมัติ เช่น การกำหนด ID ของ artifact, การกำหนดเลข version, การ log คนที่แก้ไข, history เป็นต้น Software Configuration Management นิยามของ software configuration management ในหนังสือ Software Engineering8th Edition ของ Ian Sommerville ระบุไว้ว่า “The process of identifying, organizing and controlling changes to the software during development and maintenance…” ถ้าแปลเป็นไทยก็คือ เป็นกระบวนการที่จะกำหนด จัดการ และความความเปลี่ยนแปลงต่างๆ ที่เกิดขึ้นกับ software ทั้งในระหว่างการพัฒนารวบไปถึงช่วงเวลา M/A ด้วย นั่นคือ แม้ว่าการพัฒนาจะจบไปแล้วแต่อยู่ใน phase ของการ MA การทำ change management ก็ยังคงต้องทำต่อไป เพราะ software ที่ไม่เกิดการเปลี่ยนแปลงเลย ก็คือ software ที่ไม่ได้ใช้ หรือเตรียมที่จะเลิกใช้แล้ว เพราะไม่มีอะไรให้ต่อยอดอีก Configuration Item ในการทำ SCM นั้น การทำ version control ไม่ได้ทำเฉพาะกับ file หรือ source code เท่านั้น แต่อะไรที่เกิดขึ้นใน project แล้วถือว่าเป็นส่วนประกอบใน project นั้นแล้ว จะต้องทำ version control หมด เช่น issue ที่เกิดขึ้น (bug, discussion, etc.) ตัวอย่างเอกสารจากลูกค้า, screen ตัวอย่างจากโปรแกรมเก่า เป็นต้น สิ่งเหล่านี้เราเรียกรวมๆ ว่า Configuration Item ซึ่งเมื่อมีการ update ก็จะต้องมี version และ history, ใครเป็นคนแก้ แก้ทำไม, เป็นต้น สิ่งที่จะต้องกำหนดในแต่ละ artifact ในการทำ CM คือ • Configuration Item Identifier : กำหนด code หรือ ID ที่เป็น unique ให้แต่ละ item • Description : item นั้นมีไว้เพื่ออะไร • Change history : ทุกครั้งที่มีการแก้ไขจะต้องทีการเก็บ history ไว้ เช่น o Owner : ใครเป็นเจ้าของ file (ในกรณีที่ถ้ามีการแก้ไข ต้อง notify คนนี้ หรือ ต้องแจ้งให้ owner แก้) o Current version : ปัจจุบัน version อะไร o Last modified : แก้ครั้งสุดท้ายเมื่อไหร่ o Last modified By : แก้โดยใคร o What’s modified : อะไรที่ถูกแก้ o Comment : ทำไมถึงแก้ artifact นั้น ในกรณีที่เป็น change request (CR) ก็จะมีเพิ่มเติมอีก (รายละเอียดของ change request จะกล่าวถึงในหัวข้อถัดไป) เช่น • Synopsis : หัวข้อหรือ title ของ CR นั้น • Description : รายละเอียดต่างๆ • Status : สถานะของ CR นั้น • Enter / Submit By : ใครเป็นคนบันทึก CR • Severity : ความรุนแรงของ CR นั้น • Responsibility : ใครเป็นผู้ดูแล CR นั้น เช่น ถ้าเป็น bug ใครจะเป็นคนแก้ไข เป็นต้น Repository เมื่อต้องทำการรวบรวม Artifact ต่างๆ เข้าด้วยกัน สิ่งที่ต้องคำนึงถึงต่อไปคือ ที่เก็บ ซึ่งจะต้องเป็นที่เก็บส่วนกลางที่ทุกคนต้องสามารถ access ได้ตามสิทธิ์ที่แต่ละคนได้รับ สิ่งที่ต้องคำนึงถึงหลักๆ คือ • Location : กำหนดว่าจะจัดเก็บอย่างไร • Access Right : สิทธิ์ในการเข้าถึงที่แตกต่างกัน จะจัดการอย่างไร • Version control : ควบคุม version และเก็บ history อย่างไร • Add file, Check-in and Check-out : ใครจะเป็นคนเพิ่ม file ใหม่ๆ เข้าไปใน repository แล้วคนอื่นจะ check-in และ check-out file ได้อย่างไร • Merging : กรณีที่ต้องแก้ไข file เดียวกัน จะทำการ merge อย่างไร • Backup and Restore : มีแผนการทำ backup อย่างไร และจะ restore อย่างไรเมื่อเกิดปัญหากับ repository Project Management ในระหว่างการพัฒนา requirement ต่างๆ ก็จะถูก implement ไปเป็น software ซึ่ง project manager ก็จะต้องคอยควบคุมความคืบหน้าต่างๆ ซึ่งโดยทั่วไปก็จะมีการกำหนด mile stone ของ project เช่น เมื่อ implement ทุก requirement แล้วก็จะถึง phase ของการ test ในระหว่างนี้เราจะกำหนดว่าเป็น Beta1 เมื่อ fix bug รอบและ ก็จะนำไป test ใหม่ เรียกว่า Beta 2 ไปเรื่อยๆ จน version ไหนที่ไม่มี bug ใหม่ๆ อีก ก็จะเรียกว่า version 1.0 การกำหนด version ของ program ก็จะต้องมีการระบุว่าใน version นั้นๆ ประกอบด้วย file อะไรบ้าง แต่ละ file เป็น version อะไร เพราะในระหว่างการ test (ตามกรณีนี้) เมื่อมีการแจ้ง bug จะต้องระบุว่า bug ที่เกิดอยู่ใน version ไหน เพราะ tester หลายๆ คนอาจจะ test ต่าง feature กัน จึงมีโอกาสที่จะ test คนละ version กันได้ ถ้าไม่มีการระบุ version ก็อาจจะไปเสียเวลา fix เอา bug ที่แก้ไปแล้วได้ เป็นต้น Change Management ในระหว่างการพัฒนา ซอฟท์แวร์ก็จะเกิดการเปลี่ยนแปลงไปเรื่อยๆ บางครั้งก็จะเป็น request ต่างๆ ไม่ว่าจะเป็น requirement หรือ feature ต่างๆ เราจะเรียก request เหล่านี้ว่า change request คืออะไรที่ request มาแล้วมีโอกาสทำให้เกิดการ change ใดๆ ขึ้นกับ source code หรือ document เราเรียก change request หมด เพียงแต่จะแยก type ว่าเป็นอะไร เช่น Request requirement change, New Requirement, Issue, Suggestion ซึ่ง bug ที่ user แจ้งมา ก็ถือเป็น type หนึ่งของ change request เหมือนกัน และ change request เหล่านี้จะต้องมีการ control โดยทั่วไปก็อาจจะเป็น tester หรือ helpdesk ของทีมที่จะช่วยรับ change request เหล่านี้ แต่ไม่ควรที่จะให้ developer หรือ programmer เป็นผู้รับ change request เอง เพราะ • programmer จะรู้ solutionที่จะ implement change request เหล่านั้น ก็จะรับปากไปโดยที่ไม่ได้คำนึงถึงผลที่จะกระทบจาก change request นั้น • เสียเวลา programmer เพราะงานพัฒนาเองก็มีงานมากพอสมควรอยู่แล้ว การพูดคุยกับ user เพื่อ submit change request ก็จะเสียเวลางานไป ควรแยกงานออกไปให้ role อื่นเข้ามาช่วยดูแล เมื่อถึงเวลา review จึงค่อยให้ programmer เข้ามาสรุปแนวทางแก้ไข การ implement change ก็จะต้องคำนึงถึงผลกระทบที่จะเกิดขึ้นด้วย เช่น ถ้าจะ implement requirement นั้น มันจะกระทบกับ design อะไรบ้าง code จุดไหนที่กระทบ จะต้องมีการ test แล้ว change request นั้นมี priority สูงถึงขนาดที่จะต้องแทรกงานที่กำลัง implement หรือไม่ ถ้าต้องแทรก จะกระทบกับ schedule และ cost อย่างไร และจะ deploy ที่ version ไหน สิ่งเหล่านี้คือเรื่องที่ต้องคำนึงถึง โดยทั่วไปก็จะมีอีก role หรือ team เข้ามาดูแล เราเรียกว่า Change Control Board หรือ CCB Change Control Board (CCB) ถ้าเป็นการทำ process ที่จะต้องมีการ review หรือ approve จะต้องมีการตั้งทีมๆ หนึ่งขึ้นมาเพื่อ control และ track change ที่เกิดขึ้นกับ project เราเรียกทีมนี้ว่า Change Control Board หรือ CCB โดยทั่วไป CCB ก็จะประกอบด้วยสมาชิดในทีมพัฒนาเอง อาจจะเป็น help desk, project manager และ SA ที่จะช่วยกัน filter, tracking และ control change ต่างๆ ซึ่งหน้าที่ของทีมนี้ ก็คือ • รับ Change Request จาก user หรือลูกค้า ทำการ submit CR เข้าสู่ระบบเพื่อให้ SA หรือ Developer เข้ามา review ก่อนที่จะทำหรือ planning ต่อไป • Review CR ก่อนที่จะ implement CR นั้น CR ควรที่จะต้องถูก review ก่อน เช่น CR นั้นมีความสำคัญหรือไม่ CR นั้นจะเป็นต่อลูกค้าจริงหรือไม่ คุ้มค่าที่จะทำหรือไม่ ถ้าทำแล้วกระทบกับใครหรืองานจุดไหน ลูกค้า (คนจ่ายเงิน) รับรู้เรื่องนี้หรือไม่กรณีที่อาจจะมีค่าใช้จ่ายเพิ่มหรืองานอาจจะ delay ถ้าต้องทำ เป็นต้น การ review ก็จะเป็นการป้องกันไม่ให้ทีมทำงานที่ไม่จำเป็น หรือไม่ควรที่จะต้องทำ และให้แน่ใจว่า software นั้นมี feature ที่มีประโยชน์จริงๆ เท่านั้น • Track change request status คอยดูแลสถานะของ CR ว่า CR เหล่านั้นถูก review หรือยัง แก้ไขหรือยัง เสร็จแล้วหรือไม่ ใครดูแลรับผิดชอบใจแต่ละ status เช่น ถ้าเป็น bug ใครเป็นคน fix, ใครจะเป็นคน test เมื่อ fix แล้ว เป็นต้น • Deployment plan กำหนดว่า CR นั้นจะถูก deploy ไปใน version ไหน โดยปกติ Process ของ change management และ CCB นั้นจะขึ้นอยู่กับ methodology ที่แต่ละองค์กรเลือกใช้ เช่นถ้าเป็น eXtreme Programming จะไม่ได้เน้นว่าจะต้องมี change process หรือ CCB เพราะ developer ทำงานแบบ pare developer ถ้าเกิด change ขึ้นมา ก็จะ log ลงไปใน user story ใครที่ดูแล user story นั้นก็ดูแลกันไป หรือในกรณีที่เป็นองค์กรใหญ่ๆ ที่มีแผนก Helpdesk แยกต่างหากไป วิธีการก็จะแตกต่างกันไป อาจจะต้องมีการทำ review สรุปค่าใช้จ่าย เป็นต้น ซึ่ง configuration management ก็จะพูดถึงงานที่เกี่ยวข้องและ role เท่านั้น SCM Tools จากรายละเอียดที่ว่ามาข้างต้น จะเห็นว่าถ้าจะทำ SCM โดยใช้เอกสารมาควบคุมนั้น จะเสียเวลาและกำลังคนมาก โดยทั่วไปก็จะนำ tool เข้ามาช่วย และการเลือก tool เข้ามาช่วย ก็ขึ้นอยู่กับว่าเราต้องการทำ SCM ละเอียดขนาดไหน เช่น ถ้าเราต้องการ repository กลางเพื่อให้สมาชิกในทีมสามารถ check-in และ check-out source code ได้ ก็อาจจะเลือกใช้ open source ก็ได้ เช่น Control Version System (CVS) ก็ได้ หรือถ้าต้องการทำ bug / issue tracking ก็ใช้ BugZilla ร่วมได้ ส่วนอะไรที่เป็น knowledge และ code standard โดยทั่วไปก็จะใช้ wiki-wiki tool กัน ส่วน tool ที่เป็น commercial ก็จะมีหลายๆ ตัว เช่นถ้าเป็นของ IBM จะมี 2 product ที่ทำงานร่วมกัน คือ Rational Clear Quest และ Rational Clear Case ส่วนของ Borland ก็จะเป็น StarTeam ครับ การใช้งาน tool ก็จะมีทั้งที่เป็นแบบ client / server คือมี application สำหรับ user และมี server กลางให้บริการ ต้อง install ตัอง client ที่เครื่อง หรือเป็น web-base หรือแบบที่ integrate กับ IDE เลย เช่น CVS ที่ integrate กับ Eclipse หรือ StarTeam Client ที่ integrate กับ Delphi, JBuilder หรือ Visual Studio 2005 เป็นต้น ซึ่งแต่ละแบบก็มีข้อดีข้อเสียต่างกันไป ขึ้นอยู่กับ tool และ vendor

StarTeam เป็น Software Change & Configuration Management Tool คือรองรับทั้งการทำ versioning control และการทำ change management ไปในตัว ซึ่ง feature หลักๆ คือ • Version Control : o File version control สามารถทำ version control กับ file อะไรก็ได้ ไม่ได้จำกัดเฉพาะ source code รวมถึง manage detail ของ file อัตโนมัติ เช่น owner, version number, history, etc. o Version control for other artifact นอกจาก file แล้วเรายังสามารถ submit item อื่นๆ ได้อีก ไม่ว่าจะเป็น change request, requirement, task หรือ topic ต่างๆ StarTeam จะทำ version control ให้กับ artifact เหล่านี้โดยอัตโนมัติ o Release management นอกจากแต่ละ file แล้ว StarTeam ยังสามารถกำหนด version ของ project เพื่อให้สามารถระบุได้ว่า ณ version 1.0 นั้น ประกอบด้วย file อะไรบ้าง version ไหนบ้าง รวมไปถึง configuration item หรือ artifact อื่นๆ ทั้งหมดที่อยู่ใน StarTeam ด้วย นั่นหมายความว่า ถ้าต้องการ rollback ไปยัง version ที่เรากำหนด เราจะได้ status ของโปรเจ็ค ณ เวลานั้นทั้งหมด และยังสามารถกำหนด deployment เป็น state ต่างๆ ได้ เช่น Alpha, Beta1, Beta2, RTM, Production เพื่อให้ง่ายต่อการ rollback หรือ deploy ไปใช้ o Branching & Merge ในกรณีที่เราต้องการแตก project ออกไปเพื่อ custom application ให้กับลูกค้าบางราย หรือสาขาเพียงสาขาเดียวเท่านั้น StarTeam สามารถแตก (Branch) project ออกไปเพื่อพัฒนาแยกไปคนละสายกับ product ที่มีอยู่ (หรือกรณีที่เป็น Multi-OS / Multi-Platform เป็นต้น) รวมทั้งมี tool เพื่อช่วยในการ merge project ที่ถูก branch ออกไปแล้วไปเป็น project ใหม่ก็ได้เช่นกัน (เหมือนกับกรณีที่ merge code ของ Windows XP SP1 เข้าไปใน code ของ Windows XP เดิม) • Change Management : o StarTeam รองรับการเก็บ change request ในตัว เพื่อให้ทีมสามารถ share และ manage CR เหล่านั้นได้โดยไม่ต้องใช้ tool อื่นเพิ่มเติม โดยเราสามารถเพ่มประเภทของ CR ได้เองนอกเหนือจาก default type ที่ StarTeam ให้มา o นอกจาก Change Request แล้ว StarTeam เราสามารถบันทึก Requirement ใน StarTeam ได้ ทำให้สามารถทำ Requirement Management ได้ในระดับหนึ่ง สามารถสร้าง Task ใน StarTeam เพื่อ assign งานและ track progress ของ Task ต่างๆ ของสมาชิกในทีมได้ รวมถึง Topic, Issue หรือ Risk ต่างๆ ที่เกิดขึ้นใน project แต่ยังไม่ได้สรุปว่าควรจะ implement หรือไม่ เพื่อให้ artifact ต่างๆ ของ project ถูกรวมอยู่ใน repository เดียวกัน และครอบด้วย security ที่ใช้ user และ rules เดียวกัน • Change Traceability : เมื่อเกิดการ change ขึ้น คนที่ต้อง manage change จะต้อง track ได้ว่า change นั้น เกี่ยวข้องกับอะไรบ้าง StarTeam สามารถ link item ต่างๆ ที่ต้องการเข้าด้วยกันได้ เพื่อตอบคำถามต่างๆ เช่น CR ที่เกิดขึ้นนั้น เกี่ยวข้องกับ requirement ไหนบ้าง หรือต้องแก้ code file ไหนบ้าง เป็นต้น หรือในมุมกลับกัน เราก็บอกได้ว่า Requirement ไหนบ้างที่เกิด Change Request บ่อย ถูกแก้ไปกี่ครั้ง เป็นต้น • Integrated Security : o ในบางองค์กร การเข้าถึง artifact ต่างๆ จะต้องมี authorization ตาม role ใน StarTeam จะมี User และ Role ถูก build-in อยู่ด้วย เราสามารถกำหนด access right ให้กับแต่ละ project ได้อย่างอิสระ นั่นคือ user แต่ละคนอาจจะมี role ที่ต่างกันในต่าง project เราก็สามารถกำหนดได้อย่างละเอียดไปถึงระดับแต่ละ folder หรือแต่ละ configuration item ที่อยู่ใน StarTeam เลยทีเดียว o ในกรณีที่เป็นองค์กรขนาดใหญ่ที่ implement LDAP หรือ Active Directory แล้ว ก็สามารถ integrate StarTeam เข้ากับ LDAP Server โดยไม่ต้องกำหนด user และ group ใน StarTeam ให้ซ้ำซ้อนอีก • Workflow Customization : สำหรับทีมขนาดเล็ก หรือขนาดกลางที่ไม่ได้มี policy หรือ process ที่ซับซ้อน workflow อาจจะไม่จำเป็นนัก StarTeam ก็มี build-in work flow สำหรับ change request มาให้ แต่ในกรณีที่เป็นองค์กรที่ต้องมีการ review ก่อน หรือจะต้อง notify ให้ใครเข้ามา approve นั้น StarTeam ก็มี feature ให้สามารถ customize work flow ได้ตามต้องการ รวมถึงสามารถ customize user interface ของ StarTeam ได้เองเพื่อให้ UI เหมาะกับ work flow ที่ได้ customize แล้ว (เฉพาะใน version Enterprise Advantage เท่านั้น) • Scalability / Geography Distributed Development Team : เนื่องจาก StarTeam เป็น enterprise application ที่ออกแบบมาเพื่อรองรับ user จำนวนมาก ตัว StarTeam เองจึงที architecture ให้สามารถขยายจำนวนของ user ได้ รวมถึงยังสามารถวาง server ไว้ในประเทศหนึ่ง แล้ว connect จากอีกประเทศหนึ่งเข้ามา access item ต่างๆ ใน StarTeam ได้ เพราะ StarTeam เองถูก implement อยู่บน TCP/IP Standard และ encrypt ข้อมูลโดยที่ไม่ต้องใช้ SSL เพิ่มเติมแต่อย่างใด • Multi-platform support : StarTeam Client มี version สำหรับ Windows, Linux และ MacOSX ส่วน Server นั้นสามารถติดตั้งได้บน Windows Server หรือ Linux Server ก็ได้ และรองรับ Database SQL Server และ Oracle เป็นหลัก • 3rd Party Integration : o นอกจาก Application Based Client แล้ว StarTeam ยังมี client ที่ integrate กับ IDE ต่างๆ เช่น IBM Eclipse, Visual Studio 2003 – 2005, Delphi, JBuilder และ Web-based client ด้วย o กรณีที่ต้องการทำ project planning และ task tracking แต่ไม่ได้ใช้ Microsoft Project Server นั้น StarTeam ก็มี integration tool สำหรับ publish task จาก Microsoft Project ไปเป็น task ใน StarTeam เพื่อให้สมาชิกในทีมสามารถ submit work ได้ จากนั้น project manager ก็สามารถ import work กลับมาให้ Microsoft Project เพื่อ update progress ของงานได้ ทำให้เราสามารถ link task ต่างๆ กับ File, CR, Requirement, Task และ Topic บน StarTeam ได้ด้วย o Test Management Tools Integrate : StarTeam สามารถ integrate กับ test tool ได้ด้วย เช่น Mercury QC หรือ Silk Central Test Manager เมื่อ tester ทำการ submit bug ที่เกิดขึ้นใน tool ที่กล่าวมาข้างต้น bug เหล่านั้นก็จะถูกสร้างเป็น Change Request ใน StarTeam ทำให้ทีม developer และ team tester สามารถทำงานร่วมกันได้บน tool ที่แตกต่างกัน การทำ SCM ยังไงก็ต้องใช้ tool เพียงแต่เราจะทำละเอียดขนาดไหน ซึ่ง tool ที่เสียเงิน ก็มักจะทำได้ตามทฤษฎีทุกตัว เพียงแต่จะ implement ในรูปแบบไหนเท่านั้นเอง แต่ละ vendor ก็มีวิธีที่แตกต่างกันไป ถ้าใช้ open source ก็อาจจะติดตรงที่ไม่สามารถ link กันได้เหมือนตัวอย่างของ StarTeam ที่กล่าวมาข้างต้น อาจจะต้องใช้หลายตัวและ customize เอง แต่ถ้าทำแค่ version control การใช้ CVS ก็ถือว่าเพียงพอแล้วครับ ขึ้นอยู่กับความจำเป็นครับ

ทั้งหมดนี้เป็น introduction เกี่ยวกับ Software Configuration & Change Management และ StarTeam ซึ่งก็ยังมีรายละเอียดอีกมากมายที่เกี่ยวข้องที่ยังไม่ได้พูดถึง แต่ผมก็หวังว่าทุกท่านคงจะเห็นและเข้าใจแล้วว่าอะไรคือ SCM ประโยชน์ของการทำ SCM คืออะไร ถ้ามีข้อสงสัยก็ post คำถามไว้ตาม link ที่อยู่ข้างต้นนะครับ คราวหน้าผมจะพูดถึงการเอา StarTeam มาใช้งานครับ