5 cạm bẫy phổ biến của CI/CD — và cách phòng tránh

Bí quyết để thành công với DevOps là gì? Hãy bắt đầu với tích hợp liên tục và triển khai liên tục

Devops có thể là một trong những thuật ngữ mơ hồ nhất trong phát triển phần mềm, nhưng hầu hết chúng ta đồng ý rằng năm hoạt động định nghĩa nên devops là: tích hợp liên tục, phân phối liên tục, cơ sở hạ tầng đám mây, tự động hóa kiểm thử và quản lý cấu hình. Nếu làm năm điều này, có nghĩa là bạn đang làm việc với devops. Rõ ràng, cả năm điều này đều quan trọng để có được quyền, nhưng tất cả quá dễ dàng để có bị sai. Đặc biệt, việc tích hợp liên tục và phân phối liên tục (CI/CD) có thể là những devops khó nhất để trở nên thuần thục.

Tích hợp liên tục (CI) là một quá trình trong đó các nhà phát triển và người thử nghiệm hợp tác xác nhận mã mới. Theo truyền thống, các nhà phát triển đã viết mã và tích hợp nó mỗi tháng một lần để thử nghiệm. Đó là không hiệu quả — một sai lầm trong mã từ bốn tuần trước có thể buộc các nhà phát triển phải sửa đổi mã được viết cách đây một tuần. Để khắc phục vấn đề đó, CI phụ thuộc vào tự động hóa để tích hợp và kiểm tra mã liên tục. Các nhóm Scrum sử dụng CI cam kết mã hàng ngày ít nhất, trong khi đa số họ cam kết mã cho mọi thay đổi được giới thiệu.

Phân phối  liên tục (CD) là quá trình liên tục tạo ra các đồ tạo tác có thể tái tạo. Một số công ty phát hành cho người dùng một lần hoặc thậm chí nhiều lần trong ngày, trong khi các công ty khác phát hành phần mềm với tốc độ chậm hơn vì lý do thị trường. Dù bằng cách nào, khả năng phát hành được kiểm tra liên tục. Triển khai liên tục là có thể nhờ vào môi trường đám mây. Máy chủ được thiết lập sao cho bạn có thể triển khai để sản xuất mà không cần tắt máy và cập nhật thủ công máy chủ.

Do đó, CI / CD là một quá trình để phát triển liên tục, thử nghiệm và phân phối mã mới. Một số công ty như Facebook và Netflix sử dụng CI / CD để hoàn tất 10 bản phát hành trở lên mỗi tuần. Các công ty khác đấu tranh để đạt được tốc độ đó vì họ không chịu nổi một hoặc nhiều trong số năm cạm bẫy mà tôi sẽ thảo luận tiếp theo.

CI/CD pitfall # 1: Tự động hóa các quy trình sai trước

Cái bẫy này có xu hướng tấn công các tổ chức làm cho sự thay đổi từ sự phát triển thác nước đến nhà thờ. Các tổ chức mới có lợi thế là triển khai CI / CD từ đầu. Các công ty hiện tại phải hành trình dần dần từ hướng dẫn sử dụng đến phát triển tự động hóa cao. Việc chuyển đổi đầy đủ có thể mất vài tháng, có nghĩa là bạn cần phải lặp lại trong cách bạn áp dụng CI / CD.

Khi bạn hỏi, “Điều này cần phải được tự động ngay bây giờ?” Chạy qua danh sách kiểm tra sau đây:

1. Quy trình hoặc kịch bản lặp lại bao lâu một lần?
2. Quá trình này kéo dài bao lâu?
3. Những người và phụ thuộc tài nguyên nào tham gia vào quá trình này? Chúng có gây ra sự chậm trễ trong CI / CD không?
4. Quy trình có dễ bị lỗi không nếu nó không được tự động?
5. Sự cấp thiết trong quá trình tự động hóa là gì?

Sử dụng danh sách kiểm tra này, bạn có thể ưu tiên các bước thực hiện CI / CD. Đầu tiên và quan trọng nhất, tự động hóa quá trình biên dịch mã. Lý tưởng nhất, bạn sẽ tích hợp mã nhiều lần mỗi ngày (1). Thủ công, quá trình này mất vài phút đến một vài giờ (2). Đó là đầu ra quầy hàng cho đến khi trình biên dịch kết thúc nhiệm vụ (3). Nó cũng dễ bị lỗi của con người (4), và bởi vì CI / CD là một giấc mơ đường ống mà không tích hợp tự động, đây là cấp bách (5).

Chúng tôi có thể chạy cùng một danh sách kiểm tra khi thử nghiệm. Khi bạn chuyển sang CI / CD, bạn có thể tự hỏi: Chúng ta có nên tự động kiểm tra chức năng hoặc kiểm tra giao diện người dùng trước không? Cả hai sẽ được lặp lại ít nhất một lần mỗi ngày (1). Cả hai có thể mất hai đến ba giờ cho một ứng dụng cỡ trung bình (2). Nhưng chúng liên quan đến nhiều phụ thuộc (3). Nếu bạn tự động kiểm tra chức năng, bạn có thể không phải cập nhật tập lệnh tự động hóa thường xuyên. Giao diện người dùng, mặt khác, thường thay đổi và do đó yêu cầu thay đổi tập lệnh thường xuyên. Mặc dù cả hai đều dễ bị lỗi (4), bạn nên ưu tiên kiểm tra chức năng trước khi kiểm tra giao diện người dùng để tận dụng tối đa tài nguyên của bạn (5).

Hãy làm điều này một lần nữa với quá trình thiết lập môi trường. Kịch bản này chỉ được lặp lại thường xuyên nếu bạn đang sử dụng Spree hoặc gặp phải sự cố nặng (1). Đó là một quá trình khá tốn thời gian có thể mất vài giờ nếu không phải là ngày (2). Thành viên nhóm mới không thể làm bất cứ điều gì hữu ích mà không có môi trường, vì vậy rõ ràng có sự phụ thuộc và chậm trễ (3). Tôi sẽ không nói rằng quá trình này là dễ bị lỗi (4), vì vậy nó vẫn còn khẩn cấp (5)? Tôi nghiêng về phía có, nhưng tôi vẫn ưu tiên tích hợp và thử nghiệm chức năng trước.

Không có thứ như overautomating. Nếu bạn có tài nguyên không giới hạn, bạn sẽ tự động hóa mọi thứ có thể. Điều đó nói rằng, bạn không thể đạt được tự động kiểm tra tổng số. Đôi khi bạn có thể chia nhỏ các tác vụ thành các phân đoạn nhỏ hơn và tự động hóa các bản vá. Đôi khi bạn chỉ cần viết tài liệu một cách chi tiết và thực hiện nó theo cách thủ công.

CI/CD pitfall # 2: Nhầm lẫn triển khai liên tục với giao liên tục

Triển khai liên tục là khái niệm rằng mọi thay đổi được thực hiện trong cơ sở mã sẽ được triển khai gần như ngay lập tức để sản xuất nếu kết quả của đường ống thành công. Điều này là đáng sợ đối với hầu hết các tổ chức bởi vì những thay đổi sản phẩm nhanh chóng có thể khiến người dùng sợ hãi.

Các công ty tin rằng nếu họ không thực hành triển khai liên tục, họ không làm đĩa CD. Họ không phân biệt giữa triển khai liên tục và phân phối liên tục.

Phân phối liên tục là khái niệm rằng mọi thay đổi đối với cơ sở mã đều đi qua đường dẫn đến điểm triển khai cho các môi trường không sản xuất. Nhóm tìm và giải quyết các vấn đề ngay lập tức, không phải sau này khi họ có kế hoạch phát hành cơ sở mã.

Cơ sở mã luôn ở mức chất lượng an toàn để phát hành. Khi phát hành cơ sở mã để sản xuất là một quyết định kinh doanh.

Trong khi việc triển khai liên tục làm mất đi hầu hết các tổ chức, thì việc phân phối liên tục tạo ra tiếng vang với họ. Phân phối liên tục cho phép họ kiểm soát việc giới thiệu sản phẩm, chức năng và các yếu tố rủi ro. Đã có thời gian thử nghiệm alpha, cho khách hàng dùng thử beta, đối với những người dùng đầu tiên, v.v.

CI/CD pitfall #3: Thiếu số liệu và trang tổng quan có ý nghĩa

Trong triển khai CI/CD, nhóm scrum có thể tạo trang tổng quan trước khi các thành viên biết những gì họ cần theo dõi. Kết quả là, nhóm nghiên cứu rơi con mồi vào một sai lầm hợp lý: “Đây là những số liệu chúng tôi có, do đó, họ phải là quan trọng.” Thay vào đó, thực hiện một đánh giá tiến bộ beforedesigning một bảng điều khiển.

Các thành viên khác nhau của một tổ chức CNTT, và thậm chí các thành viên khác nhau của một nhóm scrum, có những ưu tiên khác nhau. Ví dụ, những người trong một trung tâm hoạt động mạng (NOC) yêu thích các chỉ số màu đỏ, vàng và xanh lục. Các bảng điều khiển ánh sáng giao thông như vậy cho phép nhân viên NOC phân biệt các vấn đề mà không đọc văn bản dày đặc hoặc đánh thuế khả năng phân tích của họ. Đèn giao thông giúp hàng trăm máy chủ có thể quản lý được.

Bạn cũng có thể bị cám dỗ sử dụng bảng điều khiển đèn giao thông cho CI/CD. Màu xanh lá cây, chúng tôi đang đi đúng hướng. Màu vàng, chúng tôi đang đi đúng hướng, nhưng chúng tôi có kế hoạch giải quyết vấn đề đó. Màu đỏ, chúng tôi đang theo dõi và có thể cần phải thay đổi mục tiêu của mình.

Bảng điều khiển đó có thể hữu ích cho một bậc thầy scrum, nhưng những gì về VP phát triển hoặc CTO? Nếu một nhóm scrum có 350 giờ làm việc phía trước trong hai tuần chạy nước rút, và 10 thành viên của nó chịu trách nhiệm trong 35 giờ mỗi người, họ sẽ nhận được một số lượng câu chuyện tương ứng. Quản lý cấp trên có thể ít quan tâm đến tình trạng của các điểm câu chuyện và tò mò hơn về tỷ lệ “burndown”: tốc độ hoàn thành nhiệm vụ. Các thành viên trong nhóm có mang tải trọng của họ không? Nhanh như thế nào? Chúng có cải thiện theo thời gian không?

Thật không may, tỷ lệ burndown có thể gây hiểu lầm nếu các bên liên quan khác nhau không hiểu thói quen thỏa thuận của nhóm scrum. Một số đội ghi điểm sớm khi họ đi. Những người khác đợi cho đến khi kết thúc chạy nước rút để đốt cháy các điểm mở. Trang tổng quan nên tính đến điều đó.

Nếu bạn có thể đánh giá dữ liệu nào mọi người muốn và thiết lập một câu chuyện tiêu chuẩn cho những dữ liệu đó có nghĩa là gì, thì bạn có thể thiết kế một bảng điều khiển hữu ích. Nhưng đừng ám ảnh quá nhiều về mặt chi phí. Hỏi xem các bên liên quan muốn nó trông như thế nào. Biểu đồ, văn bản hoặc số liệu có tốt nhất không?

Đây là những cân nhắc để điều tra trong một đánh giá tiến bộ. Chúng minh họa việc làm thế nào để tạo một bảng điều khiển CI/CD hữu ích và làm cho mọi người hạnh phúc. Thông thường, thành viên nhóm giọng hát nhiều nhất chiếm đoạt quy trình và những người khác cảm thấy thất vọng khi trang tổng quan chỉ đáp ứng các tùy chọn của một người. Lắng nghe tất cả mọi người.

CI/CD pitfall #4: Thiếu sự phối hợp giữa tích hợp liên tục và phân phối liên tục

Sự đổ vỡ này đưa chúng ta trở lại với định nghĩa đồng thuận của chúng ta về devops, mà giữ cho sự tích hợp liên tục và phân phối liên tục là hai mục khác nhau. CI cung cấp CD. Thực hiện một đường ống tích hợp liên tục phong nha và một hệ thống phân phối liên tục đầy đủ mất nhiều tháng và yêu cầu sự cộng tác. Đảm bảo chất lượng, nhóm devops, ops engineer, scrum masters — tất cả đều phải đóng góp. Có lẽ khía cạnh khó khăn nhất của CI/CD là yếu tố con người này chứ không phải là bất kỳ thách thức kỹ thuật nào mà chúng tôi đã thảo luận. Cũng giống như bạn không thể lập trình một mối quan hệ lành mạnh giữa hai người, bạn không thể tự động hóa cộng tác và giao tiếp.

Để đánh giá mức độ phối hợp này, hãy đánh giá quá trình CI/CD của bạn chống lại tốt nhất trong kinh doanh. Các công ty như Netflix có thể hoàn thành việc tích hợp, thử nghiệm và phân phối trong vòng 2 đến 3 giờ. Họ đã thiết lập một hệ thống chuyển mã từ tay này sang tay khác mà không do dự và thảo luận. Không, nó không tự động 100 phần trăm vì điều đó là không thể với công nghệ hiện tại.

CI/CD pitfall #5: Cân bằng tần suất chạy các công việc tích hợp liên tục và sử dụng tài nguyên

Công việc tích hợp liên tục được cho là được kích hoạt cho mọi thay đổi được giới thiệu trong mã. Các công việc thành công cho phép các thay đổi được thực hiện trong khi các thất bại từ chối các thay đổi. Điều này khuyến khích các nhà phát triển kiểm tra các đoạn mã nhỏ hơn, kích hoạt nhiều bản dựng trong một ngày. Tuy nhiên, các công việc tích hợp liên tục không cần thiết tiêu thụ tài nguyên, làm lãng phí thời gian và tiền bạc.

Bởi vì quá trình này liên quan đến việc sử dụng nhiều tài nguyên (CPU, sức mạnh, thời gian), nên phần mềm này được chia thành các thành phần nhỏ hơn để tạo các đường ống chạy nhanh hơn. Hoặc các công việc tích hợp liên tục nên được thiết kế để kiểm tra hàng loạt được kiểm tra cục bộ lần đầu tiên. Mục đích là để tìm sự cân bằng giữa tần suất thực hiện các công việc tích hợp liên tục và sử dụng tài nguyên.

Giữ mục tiêu trong tầm nhìn

Khi chúng ta tìm hiểu những cạm bẫy của CI/CD – hoàn chỉnh với tất cả thuật ngữ bí truyền của nó – thật dễ dàng để mất đi lý do tại sao điều này quan trọng. Cuối cùng, CI/CD là điều cần thiết vì nó đáp ứng các mục tiêu kinh doanh.

Giám đốc điều hành công nghệ biết rằng sự tiến hóa liên tục, sửa chữa nhanh chóng, và kết quả chất lượng tạo ra và giữ chân khách hàng. Họ biết rằng một bản phát hành không thành công mời một lời khen ngợi đến các đánh giá trên App Store, và lấy lại đánh giá cao là khó hơn là giữ chúng. Nhà phát triển có thể tạo ra trải nghiệm làm việc tốt hơn cho nhóm của bạn, nhưng đó không phải là lý do tại sao các công ty triển khai nhà phát triển.

Nói một cách đơn giản, những cạm bẫy của CI/CD đáng xem xét vì hàng tỷ đô la đang bị đe dọa. Mặc dù tôi không đề xuất bạn thêm một mã cổ phiếu hoặc trình theo dõi đánh giá của App Store vào trang tổng quan CI/CD của bạn, tôi khuyên bạn nên luôn nhận thức được điều này. Rất nhiều phụ thuộc vào minutiae của CI/CD.

Nguồn bài viết : https://www.infoworld.com