Giới thiệu về đội ngũ CI/CD

Bài viết này được dịch từ bài gốc tiếng Anh tại Mercari Engineering Blog.

Bài viết này là một phần của loạt blog Developer Productivity Engineering Camp, được thực hiện bởi Yuji Kazama từ đội ngũ CI/CD.

Giới thiệu

Xin chào, tôi là Yuji Kazama, Engineering Manager của đội ngũ Continuous Integration(CI)/Continuous Delivery(CD). Đội ngũ CI/CD là một trong những đội trong Developer Productivity Engineering Camp. Trong bài viết này, tôi sẽ giới thiệu sơ lược về đội ngũ bằng cách trả lời những câu hỏi sau:

• Đội ngũ đang cố gắng đạt được điều gì? (Sứ mệnh)
• Đội ngũ có kế hoạch thực hiện sứ mệnh của mình như thế nào? (Chiến lược)

Sứ mệnh

Sứ mệnh của chúng tôi là:
“Mang đến cho các nhà phát triển trải nghiệm phát triển hiệu quả nhất thông qua CI/CD”

Khách hàng chính của đội ngũ chúng tôi là các nhà phát triển nội bộ trong toàn bộ Mercari Group. Tại sao đội ngũ của chúng tôi tồn tại vì những khách hàng này? Để trả lời câu hỏi này, hãy để tôi giải thích về bối cảnh của chúng tôi.

Khi ứng dụng của chúng tôi còn là monolithic, khi ứng dụng ngày càng trở nên phức tạp hơn, nhiều vấn đề đã được quan sát thấy. Từ góc độ CI/CD, các quy trình test và release trở nên khó khăn hơn. Việc phát hành trở nên chậm chạp vì chúng tôi cần phải chờ đợi các thay đổi trong toàn bộ dịch vụ được merge, test và deploy. Hơn nữa, nếu một bản cập nhật có lỗi được triển khai, nó có thể khiến toàn bộ dịch vụ bị ngừng hoạt động.

Để giải quyết những vấn đề trên, chúng tôi quyết định di chuyển từ kiến trúc monolithic sang microservices. Sau khi di chuyển, chúng tôi không thể test theo cách mà chúng tôi đã làm trong thời kỳ monolithic nữa. Ví dụ, một microservice cần gọi các dịch vụ khác thông qua các cuộc gọi mạng từ xa thay vì các cuộc gọi hàm cục bộ. Điều này có nghĩa là chúng tôi phải xử lý các điểm lỗi bổ sung cho những test này. Việc thử lại cuộc gọi đến các dịch vụ khác có thể gây ra DDoS trên chúng, vì vậy chúng tôi phải quan tâm đến việc cung cấp cơ chế bảo vệ thích hợp mà cũng cần được test.

Vì lý do lịch sử, có một số khác biệt giữa môi trường phát triển và môi trường production của chúng tôi. Ví dụ, một dịch vụ có thể được host trong các data center khác nhau giữa môi trường phát triển và production. Cơ sở hạ tầng khác nhau và việc cung cấp khác nhau đã khiến việc test trở nên khó khăn hơn.

Năm ngoái, chúng tôi đã gặp phải một sự cố bảo mật lớn do vấn đề supply chain. Bất kỳ phần mềm nào cũng có thể đưa các lỗ hổng vào supply chain. Khi hệ thống trở nên phức tạp hơn, việc có các kiểm tra và thực hành tốt nhất để đảm bảo tính toàn vẹn của artifact là rất quan trọng.

Để giải quyết những vấn đề này, chúng tôi cần dựa vào một nền tảng CI/CD. Đội ngũ của chúng tôi tồn tại để cung cấp điều này, nhằm đạt được tốc độ phát hành cao và độ tin cậy cao. Chúng tôi có thể giảm thiểu rủi ro và làm cho việc test và deploy dễ dàng hơn cho các nhà phát triển nội bộ.

Chiến lược

Chiến lược là cách đội ngũ có kế hoạch thực hiện sứ mệnh của mình. Sau đây là những chiến lược mà đội ngũ chúng tôi tuân theo:

• Đưa ra quyết định dựa trên dữ liệu
• Cung cấp các công cụ và cơ sở hạ tầng hữu ích
• Nuôi dưỡng văn hóa testing lành mạnh

Đưa ra quyết định dựa trên dữ liệu

Một pipeline CI/CD được thiết kế tốt cho phép các đội phát triển có vòng phản hồi nhanh và phát hành phần mềm với sự tin tưởng. Chúng ta không thể cải thiện những gì chúng ta không đo lường được. Chúng ta phải định nghĩa các chỉ số có thể đo lường được để chúng ta có thể thực hiện những bước tiến cụ thể hướng tới một sản phẩm tốt hơn.

Trong đội, chúng tôi đã định nghĩa các chỉ số CI/CD ở mức cao để cho chúng tôi biết nơi có những vấn đề có tác động tiêu cực đến năng suất phát triển.

Tuy nhiên, việc giám sát là không đủ để duy trì năng suất. Chúng ta cần các cảnh báo— các thông tin tự động được gửi đến các nhà phát triển và chúng tôi— về kết quả giám sát của chúng tôi mà cần có hành động. Ngoài ra, việc xem xét thường xuyên các quy trình và đầu ra hiện tại cần được thực hiện để đảm bảo việc sử dụng của chúng tiếp tục hiệu quả.

Cung cấp các công cụ và cơ sở hạ tầng hữu ích

Chúng tôi cung cấp các công cụ được sử dụng trong quy trình phát triển thông qua CI/CD vì chúng là trung tâm của những nỗ lực thực hiện sứ mệnh của chúng tôi. Chúng tôi cần xem xét việc sử dụng các công cụ dễ dàng như thế nào và các công cụ hữu ích như thế nào trong việc hoàn thành mục tiêu của các nhà phát triển nội bộ.

Cơ sở hạ tầng test là một thành phần quan trọng cho việc phát triển phần mềm có năng suất cao. Nó phải ổn định và dễ sử dụng phù hợp với các yêu cầu khác nhau từ các nhà phát triển và kỹ sư QA. Cơ sở hạ tầng Delivery (Deployment) cũng rất quan trọng cho việc phát triển phần mềm có năng suất cao. Nó phải ổn định, dễ sử dụng, và cũng an toàn theo mặc định để các nhà phát triển có thể thiết lập và sử dụng các pipeline deployment của họ trên đó mà không gặp rắc rối.

Nuôi dưỡng văn hóa testing lành mạnh

Mục tiêu cơ bản của chúng tôi là tự động phát hiện các thay đổi có vấn đề càng sớm càng tốt để phát hành sản phẩm thường xuyên. Tuy nhiên, chúng ta không thể chạy tất cả các test trên mỗi commit. Việc này quá tốn kém cho các nhà phát triển khi bị chặn trên mỗi commit bởi các lỗi phát sinh từ tính không ổn định hoặc flakiness của test mà không liên quan gì đến các thay đổi code của họ. Chúng ta cần định nghĩa test nào để chạy trong các workflow phát triển và production của chúng ta. Các loại testing mà chúng ta cần quan tâm bao gồm:

• Functional testing
• Security testing
• Performance, load và stress testing
• Deployment configuration testing
• Canary testing
• Chaos engineering

Càng thường xuyên và nhanh chóng chúng ta cần thực hiện các thay đổi đối với dịch vụ của mình, chúng ta càng cần một cách nhanh chóng để test chúng. Một văn hóa automated testing lành mạnh khuyến khích các nhà phát triển chia sẻ công việc viết test. Văn hóa như vậy cũng đảm bảo rằng các test được chạy thường xuyên. Việc nhấn mạnh vào việc sửa chữa các test bị hỏng một cách nhanh chóng duy trì sự tin tưởng cao vào quy trình và để làm được điều đó, chúng ta cần thúc đẩy automation testing và thực hành tốt nhất với tư cách là những người truyền bá.

Kết luận

Trong bài viết này, tôi đã giới thiệu sơ lược về đội ngũ. Chúng tôi sẽ xuất bản một số bài viết về các hoạt động của đội. Hãy mong đợi chúng!

Mercari đang tìm kiếm các kỹ sư. Nền tảng được mô tả ở trên chưa được hiện thực hóa hoàn toàn, nhưng nếu bạn muốn làm việc với chúng tôi, trong một công ty nhằm tạo ra một nền tảng như vậy, vui lòng ứng tuyển vào vị trí mà bạn quan tâm!

• Engineering Manager, Platform Group
• Software Engineer, Platform Group

---

Thông tin bài viết:

• Tác giả: KazamaYuji
• Ngày xuất bản: 2022/01/28
• Danh mục: Infrastructure
• Tags: microservices