เรื่องนี้เป็นเรื่องที่น่าสนใจเวลาที่เราทำ CI/CD ในโลกของ data แล้วบทความนี้ก็ชี้ประเด็นว่ามันมีอะไรที่หายไปในเครื่องมือที่ใช้ทำ CI/CD บ้าง
Incremental build
อย่างแรกก็คือเรื่อง incremental build ถ้าใครที่ใช้ dbt น่าจะเข้าใจ pain point แถว ๆ นี้อยู่ เช่น
- เวลาที่เรามีโมเดลเยอะ ๆ แล้วเนี่ย ตอนที่เราเอาไป deploy โดยการสั่ง
dbt run -t prodเนี่ย มันใช้เวลาค่อนข้างนาน (มาก) แล้วก็จะยิ่งนานมากขึ้นเรื่อย ๆ - ถ้าเราแก้แค่บางโมเดล เราก็อาจจะไม่ต้องรันซ้ำก็ได้ใน CI/CD pipeline แต่เราจะทำอย่างไรให้ pipeline ของเรารู้ว่าโมเดลไหนแก้ โมเดลไหนไม่ได้แก้?
บทความเค้าก็เสนอวิธีทำ hashcode กับ model นั้นไว้ (ดูจาก content ของไฟล์) แล้วตอนที่เรา deploy เราก็เช็ค hashcode นั้น ๆ ก็จะทำให้เราสามารถเลือกเฉพาะโมเดลที่มีการแก้ไข เอามา deploy ได้
แต่นั่นแหละ… เราก็ต้องทำเพิ่มจากเครื่องมือ CI/CD ปกติอยู่ดี
Sync of data across different environments
ถ้าเป็นโลกของ software ก็จะไม่ค่อยมีปัญหาเท่าไหร่ เพราะว่าเราสามารถทำให้ environment อย่าง development หรือ production เหมือนกันเกือบ 100% ได้ โดยไม่ยากมาก
แต่! ในโลกของข้อมูลเนี่ย… ข้อมูลในแต่ละ environment นี่มันไม่เหมือนกันเลย 
แล้วก็ data warehouse แต่ละเจ้าก็มีวิธีที่แตกต่างกันโดยสิ้นเชิง ถ้าเป็น Redshift เค้าบอกว่าก็ต้องสร้างอีก 1 cluster 
ถ้าเป็น Snowflake เค้าก็มีสิ่งที่เรียกว่า zero-copy clone อยู่
ถ้ามีเครื่องมือ CI/CD ตัวไหนที่สามารถทำให้ชีวิตแถว ๆ นี้ง่ายขึ้นก็น่าจะดี
Ability to check results of data tests during CI/CD
ถ้าเป็นการพัฒนา software เวลาที่ test พัง เราก็จะเจอ root cause แล้วก็แก้ได้เลย (โดยส่วนใหญ่) แต่ว่าถ้าเป็น data test เนี่ย ตอนที่ test พัง เราเจอแหละ root cause แต่เราจะดูแค่นั้นไม่ได้ เราต้องไปดูเพิ่มด้วยว่าอะไรทำให้ data เป็นมาแบบนั้น 
ก็จะมีความยากกว่า
แถว ๆ นี้ก็มีเครื่องมืออย่าง dbt tests หรือ Great Expectations เข้ามาช่วย ซึ่งอย่างไรก็ดี ถ้าเครื่องมือพวก CI/CD มี adapter ให้ต่อกับของพวกนี้ก็จะดี
จากที่อ่านมาเชื่อว่าในอนาคตคงจะมีเครื่องมือที่เข้ามาช่วยแก้ปัญหาพวกนี้แหละ ที่เป็น standard มากขึ้น โลกของ software เกิดมานานมากแล้ว ดูจากเทรนด์แล้ว เดี๋ยวโลกของ data ก็ค่อย ๆ ตามไป ที่เห็นได้ชัด ๆ เลยคือแนวคิด software-defined assets ที่ Dagster ทำอยู่ 