Trách nhiệm của Build Script và Build Server


12

Tôi cần một số giải thích về trách nhiệm của Build Script và Build Server.

Tôi đọc một số bài viết trên Net về tích hợp và xây dựng liên tục. Kể cả

Và tôi đã có một cuộc trò chuyện với cố vấn của tôi về quá trình xây dựng phần mềm của chúng tôi. Bởi vì anh ấy rất có kinh nghiệm, tôi tin tưởng vào những tuyên bố của anh ấy, nhưng tôi đã bị nhầm lẫn.

Theo tôi hiểu, từ nghiên cứu của tôi (và xin vui lòng sửa cho tôi ở đây, vì đó là những gì tôi đang hỏi về) lý tưởng nên như sau:

  • mỗi dự án đều có kịch bản xây dựng
  • kịch bản này xây dựng dự án
  • kịch bản này đảm bảo các phụ thuộc được xây dựng trước đó

Vì các phụ thuộc có thể là dự án khác, với tập lệnh xây dựng riêng của chúng, một hệ thống phân cấp giống như cây. Có thể có một kịch bản xây dựng hàng đầu xây dựng tất cả các dự án và ứng dụng.

Tuy nhiên, trách nhiệm của Build Server là:

  • kiểm tra kho lưu trữ
  • kích hoạt xây dựng
  • kiểm tra kích hoạt và các công cụ QA khác
  • làm cho cổ vật có sẵn

Điều này có thể được kích hoạt bằng tay, hàng đêm hoặc bất cứ khi nào kho lưu trữ thay đổi


Mục tiêu của cố vấn của tôi là, theo tôi hiểu, đó là một tập lệnh xây dựng là cách không linh hoạt và không thể duy trì được (Bên cạnh thực tế là sẽ mất rất nhiều thời gian để tạo một tập lệnh cho cơ sở mã kế thừa của chúng tôi). Ngoài ra, Build Server nên duy trì các phụ thuộc, ví dụ để sử dụng các phụ thuộc cũ hơn khi tạo chúng mới không thành công. Và đặc biệt Antvì đây là chủ đề cụ thể, không thể xây dựng tất cả các loại công nghệ khác nhau được sử dụng trong cơ sở mã và không thể duy trì các phụ thuộc.

Bạn có thể vui lòng xây dựng các mục tiêu, và làm rõ trách nhiệm?


4
Nhiều như đây là một câu hỏi hay, và sẽ được trả lời (tôi sẽ nói sau khi tôi có thời gian và nó chưa được trả lời): bạn thực sự nên quay lại và làm rõ từ cố vấn của mình. Bị bối rối sau khi nói chuyện với ai đó sẽ đánh giá hiệu suất của bạn là một công thức cho thảm họa và một dấu hiệu cho thấy họ không liên lạc đầy đủ với bạn (hoặc bạn không chủ động lắng nghe, nhưng dường như đó không phải là trường hợp đây).
Steven Evers

2
@ Angelo.Hannes Tôi nghĩ rằng bạn đã đạt được tất cả các điểm chính. Bạn có thể làm rõ cụ thể hơn những gì bạn đang bối rối về?
M. Dudley

@SteveEvers Vâng, cũng như vừa đọc một số giới thiệu về chủ đề này, trước tiên tôi muốn mở rộng kiến ​​thức về nó. Sau đó tôi chắc chắn sẽ chọn chủ đề này một lần nữa. Vì vậy, tôi thực sự sẽ đánh giá cao một câu trả lời của bạn.
Angelo.Hannes

@ M.Dudley Như tôi đã nói, tôi không chắc trách nhiệm đó đi đâu. Và liệu một kịch bản xây dựng cho toàn bộ phần mềm có phải là hướng đi đúng đắn hay không.
Angelo.Hannes

Câu trả lời:


14

Những điều này là trực giao:

Các xây dựng kịch bản là cơ chế đó, khi gọi trên cây nguồn tươi check-out, mang lại một xây dựng hoàn thành các mục tiêu và phụ thuộc theo yêu cầu. Nó chỉ đơn giản có thể là 'tạo ra tất cả' nếu bạn có một tệp thực hiện hoặc một lệnh gọi phù hợp của MSBuild, Ant, Maven hoặc Scons. Nếu bạn có một hệ thống phân cấp phụ thuộc phức tạp hoặc các dự án liên quan, 'tập lệnh xây dựng' của bạn có thể là một tệp cấp cao nhất lần lượt gọi từng tệp, kiểm tra sự thành công khi bạn đi.

Tập lệnh xây dựng chỉ là một tập lệnh có thể có nhiều - có thể kiểm tra, xây dựng, kiểm tra, gói - nhưng bạn có thể có một cơ chế tất cả trong một được điều khiển bởi các thông số dòng lệnh - tùy thuộc vào môi trường của bạn.

Máy chủ xây dựng , hay máy chủ tích hợp liên tục , là cơ chế tự động hóa chịu trách nhiệm lên lịch / kích hoạt, giám sát và báo cáo thanh toán -> xây dựng -> kiểm tra -> gói -> giai đoạn -> triển khai đường ống. Bạn có thể sử dụng cron / Trình lập lịch tác vụ nếu bạn không có gì phức tạp hơn để xử lý, nhưng có nhiều công cụ tuyệt vời hiện nay như Jenkins, Cruise Control, TeamCity, v.v.

Điều quan trọng là bạn có thể gọi một bản dựng mà không cần sử dụng máy chủ CI, trong trường hợp nó bận / ngoại tuyến / không thể truy cập / nếu không có sẵn, do đó, logic để có được bản dựng / kiểm tra / bất cứ điều gì được thực hiện bên ngoài Hệ thống CI, nhưng bất khả xâm phạm bởi nó, được tham số hóa bởi nhánh / kiểu xây dựng / phiên bản / kiến ​​trúc, v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.