Xây dựng tự động hóa và triển khai tự động hóa so với tích hợp liên tục

Tôi muốn trở nên hiệu quả hơn và tôi muốn sử dụng các công cụ ops hiệu quả.

Với suy nghĩ này, tôi muốn tìm hiểu thêm về tích hợp liên tục, nhưng dường như có nhiều điều khác nhau liên quan đến nó.

Tôi thực sự đang làm việc với bộ đồ Jetbrains trong công việc của mình (IntelliJ, WebStorm ...), vì vậy tôi muốn tiếp tục sử dụng chúng và tôi muốn sử dụng TeamCity dường như là một công cụ tuyệt vời với nhiều plugin để tích hợp liên tục.

Vấn đề của tôi là tôi không biết sự khác biệt giữa:

• xây dựng tự động hóa (TeamCity là loại phần mềm này): Tôi biết rằng chúng ta có thể xây dựng ứng dụng của mình với kho lưu trữ VCS từ xa và thật tuyệt vời, nhưng mục đích chính của điều đó là gì? Những loại thông tin quan trọng trong khi làm điều này? Trên thực tế, tôi đã biết liệu phần mềm của tôi có được xây dựng hay không cục bộ và các đồng đội của tôi cũng vậy. Vì vậy, mục đích của việc sử dụng nó mà không triển khai tự động hóa là gì?

• triển khai tự động hóa (TeamCity dường như không làm điều đó một cách dễ dàng)

• tích hợp liên tục (dường như là sự kết hợp của hai điều trên)
• phân phối liên tục (chính xác là gì? tại sao nó khác với tích hợp liên tục?)

Bạn có thể giúp tôi hiểu thêm một chút về điều này?

Wikipedia cung cấp tóm tắt khá tốt của hầu hết các điều khoản này. Đây là nhận của tôi về họ:

• Xây dựng tự động hóa là tự động hóa cách phần mềm được xây dựng thay vì gọi trình biên dịch theo cách thủ công. Điều này sẽ được thực hiện thông qua các công cụ như Make hoặc Ant .

• Tự động hóa triển khai đang lấy phần mềm được xây dựng của bạn và triển khai hoặc cài đặt nó trên hệ thống thử nghiệm hoặc sản xuất.

• Tích hợp liên tục có nghĩa là có một quy trình tự động xây dựng phần mềm của bạn liên tục khi các nhà phát triển kiểm tra mã và chạy thử nghiệm đơn vị để đảm bảo mã vẫn hoạt động. Ví dụ: cứ sau 15 đến 30 phút, một máy chủ có thể thức dậy, quét VCS để đăng ký mới, sau đó cập nhật và xây dựng dự án nếu có bất kỳ thay đổi nào được thực hiện. Ngoài việc thực hiện các bước biên dịch, đây cũng là một cơ hội tuyệt vời để chạy thử nghiệm đơn vị tự động và kiểm tra chất lượng mã .

• Phân phối liên tục là sự kết hợp của tất cả các khái niệm trước đây, nơi các bản dựng phần mềm cũng được triển khai cho một hệ thống thử nghiệm, tùy chọn với các thử nghiệm được thực hiện và các báo cáo được tạo.

Ít nhất, bạn cần phải có tự động hóa xây dựng, tức là một kịch bản xây dựng nào đó. Điều đó cho phép bạn nhấp vào một nút hoặc phát hành một lệnh để xây dựng dự án của bạn. Lợi ích của việc này là giảm lỗi từ các bước chạy thủ công. Các môi trường xây dựng phức tạp có thể liên quan đến việc tạo mã (nghĩ DAO từ cấu hình, mã giao diện như JAXB ), biên dịch mã, đóng gói mã, tùy chỉnh siêu dữ liệu, v.v ... Với rất nhiều thứ bạn cần có một danh sách kiểm tra: tại sao không tạo danh sách kiểm tra tập lệnh xây dựng của bạn và sử dụng một công cụ để chạy nó? Nó làm giảm lỗi và cung cấp sự nhất quán.

Tiếp theo là CI: điều này thực sự tốt để có nhưng không bắt buộc. Nó giúp xác định vấn đề xây dựng sớm. Nếu bạn có nhiều nhà phát triển kiểm tra mã trong suốt cả ngày và có lẽ không đồng bộ hóa không gian làm việc của riêng họ liên tục, có nguy cơ những thay đổi của họ sẽ can thiệp lẫn nhau. Tôi đang đề cập cụ thể đến lỗi mã tĩnh, không phải xung đột kiểm soát phiên bản. Một máy chủ xây dựng CI sẽ giảm thiểu rủi ro này.

Cuối cùng chúng ta có các bước triển khai. Ý tưởng ở đây là để tiết kiệm thời gian và giảm lỗi từ việc triển khai phần mềm thủ công. Giống như tự động hóa xây dựng, có hàng trăm cách để triển khai phần mềm. Cá nhân tôi đã ở lại muộn tại văn phòng để khắc phục các sự cố triển khai thủ công trong nhiều trường hợp khi chúng tôi cần một hệ thống chức năng cho khách hàng đến tại chỗ vào ngày mai. Tự động hóa nhiều hệ thống gây ra nhiều rủi ro hơn: thay vì một hệ thống có thể gặp sự cố hoặc có lỗi lạ, giờ đây chúng tôi có nhiều hệ thốnghệ thống có thể đi sai. Tuy nhiên, rủi ro đó thấp hơn nhiều so với việc ai đó thiếu một bước trong danh sách kiểm tra hoặc đưa ra lệnh sai và làm rối loạn việc triển khai. Nếu may mắn, bạn chỉ cần khôi phục bản sao lưu DB và bắt đầu lại, nếu bạn không may gặp lỗi có thể khiến hệ thống hoạt động không chính xác. Có phải là một lỗi phần mềm? Kỹ thuật viên không đặt cấu hình chính xác? Điều này cần có thời gian để chẩn đoán, thời gian mà bạn có thể không có và thời gian không cần phải sử dụng nếu bạn tự động hóa quy trình.

• Tích hợp liên tục là thực tiễn hợp nhất tất cả các thay đổi của nhà phát triển thành một tuyến chính được chia sẻ nhiều lần trong ngày. Cách làm này hiện nay rất phổ biến đến nỗi nó có vẻ không đáng kể, tuy nhiên theo truyền thống, các nhóm sẽ làm việc trên phần mềm trong nhiều tuần hoặc thậm chí vài tháng. Kết quả là "Địa ngục tích hợp" khi các luồng công việc riêng biệt được hợp nhất với nhau. Tích hợp liên tục thường được sử dụng với các bản dựng tự động của dòng chính được chia sẻ để sớm tìm thấy các phần chính, nhưng phần nhiều về các cam kết thường xuyên và quy trình làm việc của nhà phát triển hơn là về các tín đồ.

• Bản dựng tự động rất có giá trị để chọn các vấn đề có thể khiến bản dựng vượt qua cục bộ, nhưng không thành công trên máy chủ bản dựng (ví dụ: bạn quên kiểm tra tệp, các phụ thuộc trên máy chủ bản dựng không khớp). Có máy chủ xây dựng phát hiện những vấn đề này có nghĩa là bạn có thể khắc phục chúng trước khi đồng đội của bạn làm.

• Phân phối liên tục liên quan đến việc liên tục triển khai, chạy và kiểm tra phần mềm của bạn. Mặc dù các bản dựng tự động đảm bảo phần mềm của bạn thực sự xây dựng (và các bài kiểm tra đơn vị vượt qua), điều đó không có nghĩa là các tập lệnh triển khai của bạn vẫn hoạt động hoặc phần mềm của bạn thực sự chạy từ đầu đến cuối. Mục tiêu của Giao hàng liên tục là có một loạt các kiểm tra đảm bảo tuyến chính luôn ở trạng thái phù hợp để triển khai vào sản xuất.

• Triển khai liên tục là bước hợp lý tiếp theo - tự động triển khai mọi cam kết đi qua thành công đường ống phân phối liên tục. Có một số lợi ích cho việc thực hành này, nhưng đối với tôi, ý tưởng chính ở đây là những cam kết nhỏ, thường xuyên sẽ ít rủi ro hơn.

Tôi khuyên bạn nên đọc cuốn sách này để biết thêm thông tin:

• Phân phối liên tục: Phần mềm đáng tin cậy phát hành thông qua xây dựng, thử nghiệm và tự động triển khai

Teamcity giống như nhiều công cụ xây dựng chỉ là một ứng dụng trung tâm cho phép bạn chạy nhiều tác vụ khác nhau. Điều này bao gồm thực hiện các bản dựng như bản dựng CI, bản dựng phát hành đầy đủ và nó cho phép bạn thực hiện các bản triển khai. Nếu bạn đang sử dụng teamcity để gọi ant hoặc nant để chạy msbuild trên tệp giải pháp, bạn cũng có thể gọi các tập lệnh nant sẽ thực hiện triển khai. Nó có thể yêu cầu một chút kịch bản nhưng nó không khó.

Chúng tôi sử dụng teamcity và tre cho toàn bộ CI, CI của cơ sở dữ liệu và triển khai vào môi trường INTegration. Sau đó, chúng tôi sử dụng teamcity cho các bản dựng phát hành đầy đủ và tự động tạo các tập lệnh di chuyển db. Chúng được kiểm tra vào SVN thông qua các công việc teamcity gọi ra các kịch bản cần thiết. Đối với các triển khai, bạn đoán nó, chúng tôi sử dụng teamcity để gọi ra cần thiết để thực hiện các nhiệm vụ triển khai. Điều này hoạt động tốt vì tác nhân teamcity nói chuyện với máy chủ teamcity và tác nhân có thể tồn tại trên một trong các máy chủ ở vị trí DMZ giúp di chuyển mã vượt qua tường lửa, v.v. Vì vậy, teamcity hoặc tre là tất cả những gì bạn cần để xử lý toàn bộ kịch bản .