Nếu công ty của bạn chỉ mới giới thiệu các công cụ DevOps hoặc CI/CD, bạn có thể làm quen với những lỗi phổ biến nhất để không lặp lại chúng và không giẫm phải cái cào của người khác.
Đội đã dịch bài viết .
Không chuẩn bị để thay đổi văn hóa và quy trình
Nếu bạn nhìn vào biểu đồ tuần hoàn , rõ ràng là trong thực tiễn DevOps, thử nghiệm là một hoạt động liên tục, một phần cơ bản của mỗi lần triển khai.
Biểu đồ chu kỳ vô hạn DevOps
Kiểm tra và đảm bảo chất lượng trong quá trình phát triển và phân phối là một phần thiết yếu trong mọi việc mà nhà phát triển thực hiện. Điều này đòi hỏi sự thay đổi tư duy để kết hợp thử nghiệm vào mọi nhiệm vụ.
Kiểm thử trở thành một phần công việc hàng ngày của mọi thành viên trong nhóm. Việc chuyển sang thử nghiệm liên tục không hề dễ dàng, bạn cần phải chuẩn bị sẵn sàng cho việc đó.
Thiếu phản hồi
Hiệu quả của DevOps phụ thuộc vào phản hồi liên tục. Không thể cải tiến liên tục nếu không có chỗ cho sự hợp tác và giao tiếp.
Các công ty không tổ chức các cuộc họp hồi cứu sẽ gặp khó khăn trong việc triển khai văn hóa phản hồi liên tục trong CI/CD. Các cuộc họp hồi tưởng được tổ chức vào cuối mỗi lần lặp lại, trong đó các thành viên trong nhóm thảo luận về những gì đã diễn ra tốt đẹp và những gì chưa tốt. Các cuộc họp hồi tưởng là nền tảng của Scrum/Agile nhưng chúng cũng cần thiết cho DevOps.
Điều này là do các cuộc họp hồi tưởng đã thấm nhuần thói quen trao đổi phản hồi và ý kiến. Một trong những điểm quan trọng nhất khi bắt đầu là tổ chức các cuộc họp cổ điển định kỳ để chúng trở nên dễ hiểu và quen thuộc với toàn nhóm.
Khi nói đến chất lượng phần mềm, tất cả các thành viên trong nhóm có trách nhiệm duy trì nó. Ví dụ: các nhà phát triển có thể viết các bài kiểm thử đơn vị và cũng có thể viết mã chú ý đến khả năng kiểm thử, giúp giảm thiểu rủi ro ngay từ đầu.
Một cách đơn giản để phản ánh sự thay đổi trong suy nghĩ về kiểm thử là gọi người kiểm thử không phải là QA mà là người kiểm thử phần mềm hoặc kỹ sư chất lượng. Sự thay đổi này có vẻ quá đơn giản hoặc thậm chí là ngu ngốc. Nhưng việc gọi ai đó là "người đảm bảo chất lượng phần mềm" là sai lầm về việc ai chịu trách nhiệm về chất lượng của sản phẩm. Trong thực hành Agile, CI/CD và DevOps, mọi người đều chịu trách nhiệm về chất lượng phần mềm.
Một điểm quan trọng khác là hiểu ý nghĩa của chất lượng đối với toàn bộ nhóm và từng thành viên, tổ chức và các bên liên quan.
Hiểu lầm về việc hoàn thành giai đoạn
Nếu chất lượng là một quá trình liên tục và tổng quát thì cần có sự hiểu biết chung về việc hoàn thành các giai đoạn. Làm sao bạn biết khi nào một giai đoạn kết thúc? Điều gì xảy ra khi một bước được đánh dấu là đã hoàn thành trên Trello hoặc bảng Kanban khác?
Định nghĩa Hoàn thành (DoD) là một công cụ mạnh mẽ trong bối cảnh CD DevOps/CI. Nó giúp hiểu rõ hơn về các tiêu chuẩn chất lượng về những gì và cách thức nhóm xây dựng.
Nhóm phát triển phải quyết định "Xong" nghĩa là gì. Họ cần phải ngồi xuống và lập danh sách các đặc điểm phải đáp ứng trong từng giai đoạn để nó được coi là hoàn chỉnh.
DoD làm cho quy trình trở nên minh bạch hơn và giúp triển khai CI/CD dễ dàng hơn nếu tất cả các thành viên trong nhóm hiểu và đồng ý.
Thiếu mục tiêu thực tế, được xác định rõ ràng
Đây là một trong những lời khuyên được trích dẫn thường xuyên nhất, nhưng nó cần được lặp lại. Để thành công trong bất kỳ nỗ lực lớn nào, bao gồm CI/CD hoặc DevOps, bạn cần đặt ra các mục tiêu thực tế và đo lường hiệu suất so với chúng. Bạn đang cố gắng đạt được điều gì với CI/CD? Điều này có cho phép phát hành nhanh hơn với chất lượng tốt hơn không?
Bất kỳ mục tiêu nào được đặt ra không chỉ phải minh bạch, thực tế mà còn phải phù hợp với hoạt động hiện tại của công ty. Ví dụ: tần suất khách hàng của bạn cần các bản vá hoặc phiên bản mới? Không cần phải làm quá tải các quy trình và phát hành nhanh hơn nếu không mang lại lợi ích bổ sung cho người dùng.
Ngoài ra, không phải lúc nào bạn cũng cần triển khai cả CD và CI. Ví dụ: các công ty được quản lý chặt chẽ như ngân hàng và phòng khám y tế chỉ có thể hoạt động với CI.
CI đóng vai trò là điểm khởi đầu tốt cho bất kỳ công ty nào triển khai DevOps. Khi nó được triển khai, cách tiếp cận của các công ty trong việc cung cấp phần mềm sẽ thay đổi đáng kể. Khi CI đã thành thạo, bạn có thể nghĩ đến việc cải thiện toàn bộ quy trình, tăng tốc độ triển khai và các thay đổi khác.
Đối với nhiều tổ chức, chỉ CI là đủ và CD chỉ nên được triển khai nếu nó mang lại giá trị.
Thiếu bảng điều khiển và số liệu phù hợp
Sau khi bạn đặt mục tiêu, nhóm phát triển có thể tạo trang tổng quan để đo lường KPI. Trước khi phát triển, cần đánh giá các thông số sẽ được theo dõi.
Các báo cáo và ứng dụng khác nhau sẽ hữu ích cho các thành viên khác nhau trong nhóm. Scrum Master quan tâm nhiều hơn đến địa vị và phạm vi tiếp cận. Trong khi quản lý cấp cao có thể quan tâm đến tỷ lệ kiệt sức của các chuyên gia.
Một số nhóm cũng sử dụng bảng thông tin với các chỉ báo màu đỏ, vàng và xanh lục để đánh giá trạng thái CI/CD nhằm hiểu xem họ có đang làm mọi thứ đúng hay không hoặc có lỗi hay không. Màu đỏ có nghĩa là bạn cần chú ý đến những gì đang xảy ra.
Tuy nhiên, nếu bảng thông tin không được chuẩn hóa, chúng có thể gây hiểu nhầm. Phân tích dữ liệu nào mọi người cần và sau đó tạo mô tả chuẩn hóa về ý nghĩa của dữ liệu đó. Tìm hiểu điều gì có ý nghĩa hơn đối với các bên liên quan: đồ họa, văn bản hoặc số.
Không có kiểm tra thủ công
Tự động hóa thử nghiệm đặt nền tảng cho quy trình CI/CD tốt. Nhưng kiểm thử tự động ở tất cả các giai đoạn không có nghĩa là bạn không nên tiến hành kiểm thử thủ công.
Để xây dựng quy trình CI/CD hiệu quả, bạn cũng cần kiểm tra thủ công. Sẽ luôn có một số khía cạnh của thử nghiệm đòi hỏi sự phân tích của con người.
Bạn nên cân nhắc việc tích hợp các nỗ lực thử nghiệm thủ công vào quy trình của mình. Sau khi hoàn tất quá trình kiểm tra thủ công một số trường hợp kiểm thử, bạn có thể chuyển sang giai đoạn triển khai.
Đừng cố gắng cải thiện bài kiểm tra
Một quy trình CI/CD hiệu quả yêu cầu quyền truy cập vào các công cụ phù hợp, có thể là quản lý hoặc tích hợp kiểm tra và giám sát liên tục.
Việc tạo ra một nền văn hóa mạnh mẽ, hướng tới chất lượng nhằm mục đích , giám sát các tương tác của khách hàng sau khi triển khai và theo dõi các cải tiến.
Dưới đây là một số lời khuyên thiết thực mà bạn có thể dễ dàng thực hiện:
- Đảm bảo bài kiểm tra của bạn dễ viết và đủ linh hoạt để không bị hỏng khi bạn cấu trúc lại mã.
- Các nhóm phát triển nên được tham gia vào quá trình thử nghiệm - xem danh sách các vấn đề và yêu cầu của người dùng quan trọng cần kiểm tra trong quy trình CI.
- Bạn có thể không có phạm vi kiểm tra đầy đủ nhưng hãy luôn đảm bảo rằng các luồng quan trọng đối với UX và trải nghiệm của khách hàng đều được kiểm tra.
Điểm cuối cùng nhưng không kém phần quan trọng
Quá trình chuyển đổi sang CI/CD thường được thực hiện từ dưới lên, nhưng cuối cùng, đó là một quá trình chuyển đổi đòi hỏi sự tham gia của lãnh đạo, thời gian và nguồn lực từ công ty. Xét cho cùng, CI/CD là một tập hợp các kỹ năng, quy trình, công cụ và tái cấu trúc văn hóa; những thay đổi như vậy chỉ có thể được thực hiện một cách có hệ thống.
Những gì khác để đọc về chủ đề này:
- .
- .
- .
Nguồn: www.habr.com