Webinar Kinh nghiệm triển khai CI/CD tại Magestore

Nhìn lại DevOps là gì?

DevOps là bộ thực hành (gồm cả quy trình - process và tools) nhằm  giúp làm giảm thời gian của quá trình đưa những thay đổi từ môi trường nội bộ (local) lên môi trường production một cách nhanh nhất mà vẫn đảm bảo chất lượng.

Thường DevOps hiện được áp dụng trong các sản phẩm phân tán và các sản phẩm hướng microservices. Tại sao vậy? Tại vì mỗi service rất nhỏ và đều được đóng gói. Khi release thì chỉ release từng phần nhỏ mà không ảnh hưởng đến toàn bộ sản phẩm.

Những khó khăn, thách thức mà team từng gặp phải trong dự án Retalo

Cách đây 3 năm, các anh em ở trong giai đoạn khởi nguyên, những phần Git, CI/CD còn rất là mới.  Git ngày đấy, các anh em developer tự code, tự commit, tự merge code.

Nhưng khi tách ra làm 2 team frontend và backend thì lại có nhiều vấn đề.

Do đặc thù của nền tảng dùng lúc đó (Odoo) khi đưa 1 module lên site thì cần làm site đó down xuống, restart lại. Nếu trong quá trình restart mà có bug xảy ra thì system sẽ chết. Do đó, team tạo ra nhiều môi trường: local, dev, test, staging, production.

• Vấn đề đầu tiên team gặp phải là conflict code. Team dành nhiều thời gian để giải quyết các conflict giữa việc đẩy code của các anh em, làm như thế nào cho code chạy đủ
  

• Thứ hai, sự khác biệt giữa các môi trường từ production, staging, test, dev khác nhau một trời một vực.  Người thì dùng hệ điều hành Linux, Ubuntu, người thì lại dùng Window với Mac khi đưa code lên thì rất loạn.  
• Thứ ba, khi deploy code, ngày đó chỉ copy paste lên server. Một ngày công sức cho phần deploy rất lớn.

Nhiều vấn đề loanh quanh luẩn quẩn, chồng lên nhau. Dev thì cãi nhau vì push code đè lên nhau. Tester thì lại ngồi kêu gào dev sao lâu thế, mãi không code xong đẩy lên.

Thế là ngày đó, khi team nhận ra vấn đề thì bảo nhau ngồi brainstorm các tools để giải quyết vấn đề.

• Nghiên cứu thử dùng Jenkins được 1 tuần nhưng đề xuất và không được áp dụng được vào team.
• Triển khai Automation Test. Có đề xuất Unit Test nhưng không đồng lòng. Lại tiếp tục chuyển sang làm Selenium test. Làm luồng cho celenium test thì tốn nhiều sức và mất thời gian. Team thấy khó lại bỏ qua.
• Hồi đó, team cũng có mấy cụm máy dư, anh em bắt đầu tận dụng để làm server test. Nhưng vấn đề phát sinh là môi trường phát triển khác nhau giữa các dev. Trong cụm server test đã có sự khác nhau nên tester không biết vào máy nào là tiêu chuẩn để test.

• Về infrastructure, team cũng thử nghiên cứu Infrastructure as code nhưng thấy mất thời gian và không bám đuổi đến cùng.
  

Vấn đề thực sự là gì?

Vậy thì cuối cùng làm sao để luồng từ dev local lên production nhanh?

Vấn đề thực sự là do người DevOps lẫn lộn giữa các môi trường.

Thế là team quyết định mang một phần infrastructure đẩy lên Amazon web services.

Team code ở dưới local, đẩy code lên Github. Còn bot ở giữa sẽ chịu trách nhiệm bắt event của Github. Cứ khi nào dev push code nên thì bot này sẽ nhận trigger từ Github và sẽ pull code về môi trường của nó.

Mô hình này giải quyết được vấn đề ở chỗ đẩy code từ dev lên staging. Khi Dev đẩy code lên staging nhanh, tester kiểm thử không kịp.

Mô hình CI/CD lúc đó cực kỳ đơn giản. CD thì 1 tuần release  1 lần.

Ví dụ về đoạn script tự viết tay bởi anh Walter dùng để syn thay đổi giữa 2 môi trường với nhau.

Anh Walter đã viết toàn bộ lệnh này bằng Flask và áp dụng cái này cho tới hết project.

Sau đó công ty có biến chuyển, tái cấu trúc lại công ty theo hướng Agile và anh Walter chuyển sang team Business Operations.

Giai đoạn chuyển sang Business Operations

Team bắt đầu mindset về Agile, mọi việc cần có phải process và được thống nhất giữa mọi người trong team. Khi đấy team rút ngắn chỉ còn 2 nhánh cơ bản: Master & Develop.

Vấn đề còn tồn đọng?

1. Không có Unit test. Team mới chỉ giải quyết được vấn đề đẩy nhanh time-to-market. Nhưng chưa giải quyết được vấn đề high-quality. Tester vẫn test manual và developer thì bảo không có thời gian viết Unit Test.
2. Con bot để deploy code trên AWS vẫn dùng ở server gầm bàn. Nếu tòa nhà mất điện thì server gần bàn chết. Cũng đã nghĩ ra hướng giải quyết, đặt auto-restart server. Bot tự khởi động lại khi chết.
3. Môi trường dev và staging, production vẫn có sự khác nhau nhất định dù team đã cố gắng giảm thiểu gaps giữa các môi trường

Văn hóa Remote bắt đầu

Thời kỳ remote của Magestore bắt đầu, team Magestore chuyển toàn bộ infrastructure của Magestore lên AWS. Team thống nhất được toàn bộ môi trường thông qua docker.

Để con bot ổn định, team chuyển toàn bộ Business Operation sang Gitlab, sử dụng CI/CD mặc định của Gitlab là Gitlab Runner. Sử dụng nền tảng hạ tầng của AWS, dẫn đến dịch vụ của Magestore uptime gần như 100%.

Team giải quyết vấn đề sai khác môi trường bằng cách sử dụng Docker. Định nghĩa ra 1 cái template thống nhất từ môi trường production cho đến local.

Sử dụng luôn docker compose. Do Odoo hỗ trợ Remote debug, nên có thể sử dụng remote vào docker compose để có thể làm như dưới môi trường local.

Tiếp đó, team thống kê toàn bộ tri thức lại. Để từng người trong team có thể sử dụng được CI/CD nên các anh em cần lưu lại tri thức, viết các bài chia sẻ về mặt kỹ thuật để giúp đỡ nhau trong việc tìm kiếm thông tin, tri thức hỗ trợ phần triển khai CI/CD.

Configure Gitlab runner cho việc deploy tự động và restart servers.

Thực hiện việc điều phối code của chính các thành viên trong team.

Tạo ra các notification, hiển thị về channel của team trên Slack.

Trong tương lai thì còn cần làm gì?

Trong tương lai gần, team Business Operations có thể enhance nhiều core unit tests hơn; customize template cho local self-testing. Các thành viên mới có thể tham gia với ít công sức hơn.

Kết luận

Rốt cục CI/CD không chỉ là áp dụng tools, mà phần lớn là thiết lập quy trình, đi thương thuyết với các thành viên trong công ty để thống nhất quy trình. Khi đã thống nhất rồi thì phần triển khai CI/CD được chỉ là vấn đề thời gian.  

Mời các bạn xem video của webinar để hiểu cụ thể hơn bài chia sẻ của speaker Walter về topic này.