เพิ่งเห็นว่าทาง OWASP นั้นได้ทำ project ด้าน security ของ CI/CD ออกมานอกจากจะมี Web, API, Mobile และ Docker Securityเนื่องจาก CI/CD ได้รับความนิยม หรือ เรียกได้ว่าเป็นสิ่งที่ต้องทำเป็นปกติทั้ง environmentทั้ง process การทำงานทั้งระบบงาน และ pipeline การทำงานเพื่อให้สามารถส่งมอบระบบงานได้อย่างรวดเร็ว และ มีคุณภาพ
จากบทความเรื่อง 6 strategic ways to level up your CI/CD pipelineที่เขียนใน blog ของ GitHub นั้นทำการแนะนำ 6 แนวทางในการปรับปรุง CI/CD ให้ดีขึ้นประกอบไปด้วยสิ่งต่าง ๆ ดังนี้
ปัญหา ระบบ CI/CD ของระบบงานนั้น ยิ่งเวลาผ่านไปทำไมยิ่งทำงานช้าลงเรื่อย ๆแถมก็ไม่มีใครมาแก้ไข หรือ ปรับปรุงอีกด้วยหรือว่ามันไม่มีคุณค่าต่อทีมกันแน่นะแต่ทุกคนก็นั่งรอให้ CI/CD ทำงานเสร็จ แล้วรอลุ้นดูผล !!มันยังไงกันนะ
เขียนรูปนี้ใน feed facebook แล้วทำให้คิดถึงปัญหาอย่างหนึ่งในการพัฒนา software นั่นก็คือ ค่าใช้จ่ายสำหรับการแก้ไขข้อผิดพลาดยิ่งข้อผิดพลาดเกิดบน production server แล้วยิ่งมีค่าใช้จ่ายในการแก้ไขสูงขึ้นอย่างมาก
หลังจากที่ใช้งานมาสักพักใหญ่ ๆ ก็เลยมาอ่านที่มาที่ไปหน่อยว่า GitOps เป็นมาอย่างไรจะนำมาจาก GitOps Techโดย GitOps เริ่มมาตั้งแต่ปี 2017 จากบริษัท Weaveworksซึ่งมีการพูดคุยที่เยอะมาก ๆ รวมทั้งทำให้เกิดความสับสนจึงทำการสรุปไว้ในบทความข้างต้น เพื่อให้เข้าใจตรงกัน
สิ่งที่น่าสนใจในการพัฒนาและส่งมอบให้เร็วพร้อมกับคุณภาพที่สูงนั้นเป็นคำถามที่น่าสนใจมาก ๆแน่นอนว่า เราอาจจะพบเจอปัญหาต่าง ๆ มากมายไม่ว่าจะเป็นปัญหาคอขวดในการทำงานไม่ว่าจะเป็นข้อจำกัดต่าง ๆ ของขั้นตอนการทำงานเราควรต้องทำอย่างไรดี ? สิ่งที่ควรจะทำคือ การปรับปรุงสิ่งพื้นฐานต่าง ๆ เหล่านี้แบบค่อยเป็นค่อยไปอย่างต่อเนื่อง
จากการแนะนำเรื่องของ Continuous Integration และ Continuos Delivery นั้น มีการพูดคุยถึงคุณสมบัติที่ดีของระบบเหล่านี้ ว่าควรจะมีอะไรบ้าง เพื่อให้เราไม่หลงทางในการนำมาใช้งาน
เรื่องที่สำคัญของการพัฒนา software คือ ขั้นตอนการ build, test, release และ deploy เป็นอย่างไรบ้าง ในการพัฒนาที่ดี น่าจะต้องวางแผนและกำหนดขั้นตอนการทำงานไว้ ซึ่งเราจะเรียกขั้นตอนเหล่านี้ว่า Build pipeline (workflow) นำมาจากแนวคิดของ Continuous Integration และ Continuous Delivery โดยในบทความนี้ จะนำ GitHub Actions มาสร้างกระบวนการเหล่านี้ มาเริ่มกันเลย
ปัญหาในการพัฒนา software ส่วนใหญ่ที่พบเจอคือ “It didn’t work in production” นั่นคือทุกอย่างมันจะดูดีมาก ๆ เมื่อไม่ทำการ deploy ไปยัง production server !!
หลังจากทำรวมรู้จักกับ GitHub Actions และลงทะเบียนขอใช้งานไปวันนี้ก็รับ email แจ้งว่า สามารถเข้าลองใช้งานได้แล้ว เมื่อไปดูใน repository ของเราที่ GitHub ก็จะมี menu ชื่อว่า Actions ขึ้นมาดังนี้