Trường hợp sử dụng – Xây dựng Hệ thống của các Hệ thống – tạo ra quy trình CI/CD toàn diện cho các ứng dụng kế thừa

Xin chào quý vị. Cảm ơn quý vị đã tham dự buổi chia sẻ này ngay trước giờ ăn trưa. Tôi rất vui vì không phải sau bữa trưa, vì có thể tôi sẽ gặp một khán giả khác trong khoảng một giờ nữa. Vậy nên, hy vọng quý vị đang sẵn sàng và háo hức học hỏi.

Tôi là Mark Maxey, làm việc tại Raytheon. Địa chỉ email của tôi là mark_r_maxey@raytheon.com. Quý vị có thể liên hệ với tôi qua email này hoặc chúng ta có thể trao đổi sau buổi chia sẻ. Trong quá trình trình bày, tôi sẽ dừng lại để quý vị có thể đặt câu hỏi hoặc đưa ra ý kiến. Xin vui lòng không ném cà chua thối hoặc bất kỳ vật gì khác.

Hôm nay, chúng ta sẽ thảo luận về một trường hợp sử dụng tại Raytheon, cụ thể là cách chúng tôi đã áp dụng Artifactory.

Để quý vị hiểu rõ hơn về Raytheon, chúng tôi là một tập đoàn với khoảng 100.000 nhân viên, có nhiều cơ sở trên khắp Hoa Kỳ. Chúng tôi sản xuất các sản phẩm như tên lửa Patriot, lò vi sóng, hệ thống mặt đất để điều khiển vệ tinh GPS và thời tiết, cũng như các thiết bị hiển thị trên mũ bảo hiểm mà Adrien đã đề cập vài ngày trước. Tuy nhiên, lĩnh vực tôi tham gia nhiều nhất là xây dựng hệ thống tích hợp.

Thông thường, chúng tôi kết hợp các hệ thống hiện có để nâng cấp hoặc tích hợp chúng với nhau, tạo ra các hệ thống mới. Phần lớn các hệ thống này không được tạo ra từ đầu; chúng tôi hiếm khi bắt đầu từ con số không. Thay vào đó, chúng tôi kết hợp các hệ thống hiện có để tạo ra giải pháp mới. Quá trình này thường gặp nhiều thách thức, đặc biệt khi phải làm việc với các ứng dụng cũ, công nghệ khác nhau, quy trình và pipeline khác nhau.

Hôm nay, tôi sẽ chia sẻ về một trường hợp sử dụng mà tôi đã làm việc gần đây.

Khi tham gia một dự án, tôi thường được yêu cầu tạo ra một thành phần cụ thể. Trước khi bắt đầu, tôi luôn thảo luận về các yêu cầu phi chức năng như tính sẵn sàng, độ tin cậy, tốc độ, năng suất, hiệu quả và chi phí. Đây là những yếu tố quan trọng mà tôi quan tâm. Tuy nhiên, trong ngành của tôi, chúng tôi thường phải đối mặt với các yêu cầu, lịch trình và ngân sách cố định, điều này tạo ra nhiều hạn chế ngay từ đầu.

Với những hạn chế này, chúng tôi không thể thay đổi kiến trúc cũ, thời gian giao hàng dài và nhiều người chưa quen với tích hợp và triển khai liên tục. Khi tham gia dự án, tôi chỉ có thể đưa ra ý tưởng và thuyết phục mọi người. Vậy, chúng ta làm gì trong những tình huống như vậy? Đó là nội dung tôi sẽ trình bày hôm nay.

Dưới đây là tóm tắt những gì chúng ta sẽ thảo luận: những gì chúng tôi đã làm, đang làm và sẽ làm trong tương lai. Trong quá trình này, tôi sẽ đề cập đến một số cải tiến liên quan đến Artifactory và những lĩnh vực mà Artifactory có thể xem xét hợp tác với chúng tôi trong tương lai.

Trước tiên, giống như nhiều tổ chức khác, chúng tôi không sử dụng một hệ thống kiểm soát phiên bản duy nhất. Chúng tôi sử dụng nhiều hệ thống kiểm soát phiên bản khác nhau trong cùng một dự án. Không chỉ trong một công ty, mà chúng tôi thường hợp tác với nhiều công ty khác nhau để tạo ra sản phẩm. Vậy, khi có nhiều hệ thống kiểm soát phiên bản và pipeline khác nhau, làm thế nào để chúng hoạt động cùng nhau? Chúng tôi xem Artifactory là nơi tích hợp. Chúng tôi không quan tâm bạn sử dụng hệ thống kiểm soát phiên bản nào, miễn là nó có thể lặp lại, đáng tin cậy và được gắn thẻ. Điều chúng tôi quan tâm là khi bạn hoàn thành công việc, bạn sẽ đưa sản phẩm vào Artifactory, nơi chúng tôi sẽ áp dụng các chính sách và ràng buộc.

Chúng tôi sử dụng Jenkins để thực hiện các bản build, vì Jenkins hoạt động tốt với nhiều hệ thống kiểm soát phiên bản khác nhau. Khi build từ các hệ thống kiểm soát phiên bản khác nhau, chúng tôi đưa tất cả output của một baseline vào một repository duy nhất. Điều này khác biệt so với cách làm truyền thống, nơi một repository chứa nhiều phiên bản, nhánh và baseline khác nhau, gây khó khăn trong việc quản lý.

Chúng tôi quyết định rằng mỗi repository đại diện cho một baseline và một nhánh. Bất kể hệ thống kiểm soát phiên bản hay tên nhánh là gì, chúng tôi cấu hình Jenkins để đưa tất cả output liên quan vào một repository duy nhất. Điều này mang lại lợi ích khi triển khai, vì chúng tôi chỉ cần trỏ đến một URL duy nhất, đại diện cho repository đó, và lấy phiên bản mới nhất mà không cần logic phức tạp để xác định nhánh hay phiên bản.

Thách thức đầu tiên là làm thế nào để đưa sản phẩm vào Artifactory, đặc biệt khi không phải tất cả công nghệ build đều hỗ trợ việc publish và resolve dependencies. Chúng tôi đã tìm ra giải pháp bằng cách sử dụng Gradle.

Trong ngắn hạn, chúng tôi tìm cách dễ dàng tích hợp vào các ứng dụng cũ mà không cần thay đổi nhiều. Chúng tôi muốn giới thiệu một cách nhẹ nhàng, cho phép các build hiện có được đưa vào Artifactory mà không gây xáo trộn.

Có một số cách để làm điều này. Cách đầu tiên là sử dụng Gradle như một công cụ tải xuống và tải lên repository. Chúng tôi sử dụng Gradle để quản lý dependencies, tải chúng về và đặt vào thư mục cụ thể. Sau đó, khi build truyền thống được thực hiện (có thể là perl scripts, makefiles, Ant, v.v.), chúng tôi không can thiệp vào quá trình build. Sau khi build hoàn thành, chúng tôi xác định output, đóng gói (ví dụ: rpms, zips) và đưa lên Artifactory.

Đối với các build sử dụng Ant, chúng tôi bọc chúng trong Gradle. Gradle có tích hợp tốt với Ant, cho phép