Salesforce CI/CD: CI/CD คืออะไร ทำไมต้อง CI/CD

“You’re either the one that creates the automation or you’re getting automated.” — Tom Preston-Werner (GitHub Founder)

การ Build และการ Deployment เป็นหนึ่งในปัญหาที่ Salesforce Developer หลายคนต้องเจอ เนื่องจากการออกแบบ Salesforce Platform ที่เป็น Org Driven Development นั่นก็คือการให้ Developer อัพโหลดโค้ดขึ้นไปที่ Salesforce ใน Org นั้นๆ เพื่อทำการ Compile และ Deploy โดยไม่สามารถ Compile บนเครื่องของตัวเองได้ อีกทั้งยังมีการแก้ไข Config ใน Salesforce แบบ Drag and Drop หรือ Click not Code อีก ทำให้การจัดการ Source Code เป็นเรื่องวุ่นวายเมื่อเราไม่มี Single Source of Truth หรือจุดที่เราสามารถเชื่อได้ว่าโค้ดภายใน Salesforce ปัจจุบันเป็นยังไง

หลายๆ คนอาจจะเคยเจอปัญหาว่า Org 2 อัน มีโค้ดหรือการ Config ค่าที่ต่างกัน ซึ่งทำให้เกิดหลายๆ ปัญหาตามมา เช่น บัคบางตัวสามารถทำให้เกิดใน Org นี้ได้ แต่ไม่สามารถทำให้เกิดในอีก Org หนึ่งได้

Salesforce เป็น Platform ที่ Developer ไม่ชอบมากที่สุด ข้อมูลจาก Stackoverflow Developer Survey 2015

สำหรับบทความนี้ เราจะมาพูดถึง CI/CD หรือ Continuous Integration / Continuous Deployment ที่จะมาแก้ปัญหาความยุ่งเหยิงในการ Deployment และปัญหาอื่นๆ เพื่อให้ชีวิตของเหล่า Salesforce Developer สุขสบายยิ่งขึ้น

CI/CD คืออะไร?

CI/CD ย่อมาจาก Continuous Integration / Continuous Deployment

คำว่า Continuous Integration หมายถึง กระบวนการอัตโนมัติที่นำ Source Code ของโปรแกรมนั้นๆมา Build, Test และ ทำการ Merge เข้า Repository หรือสถานที่เก็บ Source Code

ในขณะที่ Continuous Deployment หรือ บางคนก็เรียกว่า Continuous Delivery คือ กระบวนการอัตโนมัติที่อำนวยความสะดวกด้านการ Deploy Source Code ไปยัง Test Environment เพื่อทำการทดสอบแบบ System Integration Testing หรือ User Acceptance Testing รวมถึงการ Deploy ไปยัง Production

ทำไมต้อง CI/CD?

ลองนึกภาพว่าเราเสียเวลาเขียนโค้ด และ Unit Test จน feature นี้เสร็จแล้ว เราต้องมานั่ง Deploy โค้ดจาก Developer Sandbox ไปยัง อีก Sandbox หนึ่งเพื่อทำ Test ถ้าคุณยังใช้ Change Set ใน Salesforce อยู่ คุณต้องนั่งลากแต่ละ Component มาใส่เพื่อให้โค้ดของคุณถูก Deploy ไปยัง Sandbox เป้าหมายได้ เหนื่อยเขียนโค้ดแล้ว ยังต้องมาเหนื่อย Deploy อีก ทำไมเราไม่ Automate สิ่งนี้ล่ะ!!?

งั้นเรามาลองนึกอีกภาพหนึ่ง เราเขียนโค้ดและ Unit Test เสร็จเรียบร้อย เราทำการ Commit โค้ดของเราขึ้น Git จากนั้นจะมีโปรแกรมอีกตัวที่ทำงานอัตโนมัติที่นำโค้ดของคุณมา Run Test Class และ Deploy ไปยัง Target Sandbox แบบอัตโนมัติ เพียงแค่คุณ Commit โค้ดของคุณ หนึ่งคลิก หนึ่ง Action เท่านั้น สบายไหมล่ะ

นี่คือคำตอบของคำถามว่า “ทำไมต้อง CI/CD?” เมื่อ Process ไหนที่สามารถ Automate ได้ และทำให้ลดงานของคุณได้ สิ่งนั้นควรจะถูก Automate เช่นเดียวกันกับการ Deploy ใน Salesforce ของเรา

พลังแห่ง Source Control

เมื่อพูดถึง CI/CD แล้ว จะไม่พูดถึง Source Control หรือ Version Control ก็คงไม่ได้ เพราะสิ่งนี้ก็เป็นหัวใจสำคัญในการเขียนโค้ดและ CI/CD เช่นกัน

Source Control คือ การบันทึกการเปลี่ยนแปลงของโค้ดอย่างต่อเนื่อง และต้องสามารถแบ่งโค้ดเป็น version ต่างๆ เพื่อตอบสนองกับสถานการณ์ต่างๆในช่วง build project ได้

สำหรับ Source Control ที่หลายๆคนอาจจะคุ้นเคย คือ Git ที่ให้คุณบันทึกโค้ดผ่านการ commit และสามารถสร้าง branch ออกมาหลากหลาย เพื่อแทนโค้ดแต่ละ version ได้

สิ่งที่คุณสามารถทำได้เมื่อมี Source Control

1. เปรียบเทียบ History ของโค้ดแต่ละไฟล์ได้ว่าเกิดการแก้ไขอย่างไร เกิดการแก้ไขโดยใคร และแก้ไขเพราะอะไร
2. Backup โค้ดที่เคยเขียนไว้ได้ และเรายังสามารถย้อนเวลากลับไปเอาโค้ดในอดีตมาใช้แทน หากมีปัญหา หรือต้องการใช้โค้ด version เก่า
3. แยก version ได้ว่า โค้ดส่วนนี้กำลังอยู่ในช่วง SIT หรือ UAT และโค้ดส่วนไหนที่ Test ผ่านหมดแล้ว เตรียม Deploy Production
4. สามารถรองรับการ Roll Back ได้ ถ้ามีปัญหาใน Environment ต่างๆ
5. ทำให้ Developer หลายๆคนที่เขียนโค้ดร่วมกัน สามารถทำงานได้โดยที่โค้ดไม่ตีกัน หรือโค้ดขัดแย้งกัน

แล้วเราจะทำ CI/CD กับ Salesforce ได้ยังไง?

เรามาดู Tool หรือเครื่องมือที่เราต้องมีเพื่อที่จะทำ CI/CD กับ Salesforce กัน

1. Source Control หรือที่เก็บ Source Code —Tool ที่เป็นที่นิยมสุดในตอนนี้ คือ Git ซึ่งคุณจะใช้ Git เฉยๆ แล้ว Host เองซักที่ หรือใช้ Git ที่ Host โดยผู้ให้บริการอย่าง GitHub หรือ GitLab ก็ได้
2. CI/CD Tool — Tool สำหรับการนำ Source Code ของเราไป Deploy และ Run Test Class แบบอัตโนมัติ มีให้เลือกหลากหลายเจ้า ที่เป็นที่นิยม ได้แก่ Jenkins (Host เอง) หรือ Circle CI และ Travis CI (ไม่ต้อง Host เอง และสามารถเชื่อมต่อกับ GitHub ได้เลย)
3. Salesforce CLI — Command Line Interface ของ Salesforce ที่มี feature ต่างๆมากมาย แต่ feature ที่สำคัญที่สุดที่เราต้องการใช้งาน คือ คำสั่ง deploy จาก Source Code ไปยัง Target Org โดยเราจะนำ Salesforce CLI มาให้ CI/CD Tool ของเรามาเรียกใช้ เพื่อให้เกิดการ Deploy แบบอัตโนมัติได้
4. Code Coverage Report (Optional) — Code Coverage Report จะแสดงเปอร์เซ็นต์ของ Code Coverage หรือ จำนวนบรรทัด ที่ถูกครอบคลุมด้วย Test Class ใน Project ของเราหลังการ Run Test Class ในแต่ละครั้ง เราจะสามารถเห็นสถานะการ Unit Test ของ Org นั้นๆ หรือ Project นั้นๆ ผ่าน Tool ตัวนี้ได้ แต่สิ่งนี้เป็น Optional นั่นก็คือถ้าไม่มี Code Coverage Report เราก็ยังทำ CI/CD ได้นะ แค่ Tool ตัวนี้จะให้ข้อมูลให้กับเราเพิ่มมากขึ้น

เมื่อเรานำ Tool ที่กล่าวมามาประกอบกันแล้ว เราจะได้ CI/CD มาคอย Auto Deploy ให้เราชื่นใจกันแล้ว

เปรียบเทียบ Deployment รูปแบบต่างๆ ของ Salesforce

เปรียบเทียบ Deployment แบบต่างๆของ Salesforce

1. Salesforce Change Set

วิธีการ Deploy แบบดั้งเดิมของ Salesforce ที่ใช้การสร้าง Change Set ที่รวม component หลากชนิดที่เราต้องการ Deploy แล้วนำไป upload ที่ Org ปลายทาง

ข้อดี
- Native Salesforce Feature
- ฟรี
- ใช้งานง่าย ผ่าน Web UI ไม่ต้องติดตั้งโปรแกรม

ข้อเสีย
- ยุ่งยาก ถ้ามีหลาย component และมี component หลายชนิด
- ใช้เพื่อ Deploy ได้เท่านั้น ไม่สามารถใช้เปรียบเทียบ Source Code ได้

2. Gearset

Third Party App ที่มีขึ้นเพื่อแก้ปัญหาการ Deploy ผ่าน Change Set ของ Salesforce โดยมี feature หลัก คือ สามารถเปรียบเทียบความแตกต่างระหว่าง component ต่างๆของ Org ต้นทางและ Org ปลายทางได้ และยังมี feature เช่น การ filter component หรือการดู dependency ของแต่ละ component ด้วย

ข้อดี
- ใช้งานง่าย ผ่าน Web UI ไม่ต้องติดตั้งโปรแกรม
- เปรียบเทียบความแตกต่างระหว่าง component ได้
- feature หลากหลายที่ช่วยการ deploy

ข้อเสีย
- ใช้ concept Org Driven Development เหมือนเดิม ต้อง Deploy จาก Org ไป Org ไม่มี Single Source of Truth
- เป็น Third Party App อาจมีการนำ Source Code ใน Org ไปเก็บไว้ที่ไหน เราไม่สามารถรู้ได้
- เสียค่าใช้จ่าย (150 USD ต่อเดือน)

3. CI/CD

ใช้ Git + CI/CD Tool + Salesforce CLI เพื่อทำ Auto Deploy และ Source Control

ข้อดี
- Track History ของแต่ละ component ได้ ว่าถูกแก้ไขไปยังไง
- Auto Deploy ผ่านการ commit ไม่ต้อง Deploy เอง
- สามารถแยกเวอร์ชันของงาน ในกรณีมีงานสองชิ้นที่ขึ้น Production ไม่พร้อมกัน หรือมี Production Issue ที่ต้องรีบแก้ไข โดยต้องไม่นำ component ส่วนอื่นติดขึ้น Production ไปด้วย
- Single Source of Truth สำหรับ Source Code สามารถเชื่อ component ใน Git ได้ว่าจะตรงกับ component ที่อยู่ใน Org

ข้อเสีย
- เสียเวลาติดตั้งในครั้งแรก
- เป็น Total Solution ไม่สามารถแยกชิ้นส่วนออกจากกันได้ เช่น ต้องการแค่ Auto Deploy เท่านั้น ไม่เอา Source Control
- ผู้ใช้งานต้องใช้ Git เป็น และเข้าในการทำงานของ Salesforce Source Code หรือ Salesforce Metadata
- มี Learning Curve ในการใช้งานช่วงแรก

บทส่งท้าย

CI/CD แท้ที่จริงแล้ว เป็นมากกว่า Tool ที่ทำให้เรา Auto Deploy ได้ เพราะ CI/CD สามารถทำให้เราเห็นการเปลี่ยนแปลงของโค้ด, back up โค้ด, ทำให้ Developer หลายๆ คนทำงานร่วมกันได้ และ ยังทำให้ขั้นตอนการย้ายโค้ดไปยัง Environment หรือ Org ต่างๆ มีความสะดวกสบายยิ่งขึ้น

แต่การใช้ CI/CD ก็มี Learning Curve และมี Cost ทั้งเวลาในการ Set up ขึ้นมาครั้งแรก และ Cost ของการใช้งาน CI/CD Tool ซึ่งเป็นสิ่งที่ต้องพิจารณาว่า คุ้มหรือไม่ กับการใช้ CI/CD ใน Project นั้นๆ

สำหรับบทความ “Salesforce CI/CD: CI/CD คืออะไร ทำไมต้อง CI/CD” ก็จบลงเพียงเท่านี้ ในบทความตอนถัดไป เราจะมาพูดถึงวิธีการแบบเจาะลึก ถึงการเริ่มต้นใช้งาน CI/CD กับ Salesforce พร้อมเล่าถึงชีวิตที่เปลี่ยนไปของ Salesforce Developer และ Salesforce Admin เมื่อต้อง build project ที่มี CI/CD