2008-10-23 10 views
5

Giả sử rằng tôi thiết lập một automatic nightly build. Tôi nên lưu các đồ tạo tác nào của công trình xây dựng?Những đồ tạo tác nào để lưu cho bản dựng hàng đêm?

Ví dụ:

  • mã nguồn Input
  • đầu ra nhị phân

Ngoài ra, bao lâu tôi nên cứu họ, và ở đâu?

Câu trả lời của bạn có thay đổi không nếu tôi thực hiện tích hợp liên tục?

+1

Bạn chỉ cần có thể xác định mã nguồn của mình một cách đáng tin cậy. Tùy thuộc vào VCS của bạn, điều đó có thể có nghĩa là sử dụng các bản sao, nhưng một đặc điểm kỹ thuật của mã nguồn có thể là đủ. Ngoài ra, trong những ngày bạn có thể mua 2TB ổ đĩa với giá 200 đô la, có thể bạn vẫn giữ nguyên nguồn (đã nén, ngay cả bây giờ). –

+0

2TB đĩa với giá 200 đô la? Bạn có nghĩa là mua hai ổ đĩa 1TB với giá 100 đô la, hoặc bạn có nghĩ rằng bạn có thể được giảm giá 30% tại newegg không? http://www.newegg.com/Product/Product.aspx?Item=N82E16822136344 –

Trả lời

6

Dưới đây là một số hiện vật/thông tin mà tôi đang sử dụng để giữ tại mỗi build:

  • Tên thẻ của ảnh chụp bạn đang xây dựng (tag và làm một kiểm tra sạch trước bạn xây dựng)
  • việc xây dựng các kịch bản themselfs hoặc số phiên bản của họ (nếu bạn đối xử với họ như là một dự án riêng biệt với điều khiển phiên bản riêng của mình)
  • kết quả của việc xây dựng kịch bản: bản ghi và sản phẩm cuối cùng
  • một ảnh chụp của môi trường của bạn: 0.123.
    • phiên bản trình biên dịch
    • phiên bản công cụ xây dựng
    • thư viện và dll/libs phiên bản
    • phiên bản cơ sở dữ liệu (client & server)
    • phiên bản ide
    • kịch bản phiên bản phiên dịch
    • phiên bản hệ điều hành
    • phiên bản điều khiển nguồn (máy khách và máy chủ)
    • phiên bản của các công cụ khác được sử dụng trong quy trình và mọi thứ khác mà có thể ảnh hưởng đến nội dung của các sản phẩm xây dựng của bạn. Tôi thường làm điều này với một kịch bản truy vấn tất cả các thông tin này và ghi nó vào một tệp văn bản cần được lưu trữ với các tạo phẩm xây dựng khác.

Hãy tự hỏi mình câu hỏi này: "nếu có điều gì phá hủy hoàn toàn môi trường/phát triển xây dựng của tôi những thông tin tôi sẽ cần phải tạo ra một cái mới vì vậy tôi có thể làm lại build của tôi # 6547 và kết thúc với kết quả chính xác cùng Tôi đã có lần đầu tiên? "

Câu trả lời của bạn là những gì bạn nên giữ ở mỗi bản dựng và nó sẽ là tập hợp con hoặc phần phụ của những thứ tôi đã đề cập.

Bạn có thể lưu trữ mọi thứ trong SCM của mình (tôi muốn giới thiệu một kho lưu trữ riêng), nhưng trong trường hợp này, câu hỏi của bạn về thời gian bạn nên giữ cho các mục không phù hợp. Hoặc bạn nên lưu nó vào các thư mục nén hoặc ghi một đĩa cd/dvd với kết quả xây dựng và các tạo phẩm. Dù bạn chọn gì, hãy có một bản sao lưu.

Bạn nên lưu trữ chúng miễn là bạn có thể cần đến chúng. Bao lâu, sẽ phụ thuộc vào tốc độ nhóm phát triển của bạn và chu kỳ phát hành của bạn.

Và không, tôi không nghĩ rằng nó thay đổi nếu bạn tích hợp liên tục.

3

Chúng tôi lưu các tệp nhị phân, bị tước bỏ và bỏ khóa (vì vậy chúng tôi có cùng một nhị phân, một lần và không có biểu tượng gỡ lỗi). Hơn nữa chúng tôi xây dựng tất cả mọi thứ hai lần, một lần với đầu ra gỡ lỗi được kích hoạt và một lần mà không (một lần nữa, tước và unstripped, do đó, mỗi kết quả xây dựng trong 4 nhị phân). Việc xây dựng được lưu trữ vào một thư mục theo số sửa đổi SVN. Bằng cách đó, chúng tôi luôn có thể giữ lại nguồn từ kho lưu trữ SVN bằng cách chỉ cần kiểm tra bản sửa đổi này (theo cách đó nguồn cũng được lưu trữ).

17

Bạn không nên lưu bất kỳ thứ gì vì mục đích lưu. bạn nên lưu nó bởi vì bạn cần nó (tức là, QA sử dụng các bản dựng hàng đêm để kiểm tra). Tại thời điểm đó, "bao lâu để lưu nó" trở thành tuy nhiên dài QA muốn họ.

tôi sẽ không "lưu" mã nguồn quá nhiều như gắn thẻ/gắn nhãn. Tôi không biết điều khiển nguồn bạn đang sử dụng, nhưng gắn thẻ là tầm thường (hiệu suất & không gian đĩa) cho bất kỳ hệ thống kiểm soát nguồn chất lượng nào. Sau khi xây dựng của bạn được gắn thẻ, trừ khi bạn cần nhị phân, có thực sự không phải là bất kỳ lợi ích để chỉ có chúng xung quanh bởi vì bạn chỉ có thể tái biên dịch khi cần thiết từ nguồn.

Hầu hết các công cụ CI đều cho phép bạn gắn thẻ trên từng công trình xây dựng thành công. Điều này có thể trở thành vấn đề đối với một số hệ thống vì bạn có thể dễ dàng có hơn 100 thẻ mỗi ngày. Đối với những trường hợp như vậy, tôi khuyên bạn nên chạy một bản dựng hàng đêm và chỉ gắn thẻ đó.

0

Lưu như khi đăng ký kiểm soát mã nguồn hoặc chỉ trên đĩa? Lưu không có gì để kiểm soát mã nguồn. Tất cả các tệp dẫn xuất sẽ được hiển thị trong hệ thống tệp và có sẵn cho nhà phát triển. Không kiểm tra các tệp nhị phân, mã được tạo từ các tệp XML, thông báo phân tích, vv Một bước đóng gói riêng biệt sẽ làm cho các sản phẩm cuối này có sẵn. Khi bạn có số thay đổi, bạn luôn có thể tạo lại bản dựng nếu giả thiết tất nhiên mọi thứ bạn cần làm là xây dựng hoàn toàn trong cây và có sẵn cho tất cả các bản dựng bằng cách đồng bộ hóa.

+0

Tôi đã từng nghĩ điều này, nhưng sau khi làm việc cho một khách hàng đã giữ tất cả các tệp nhị phân và các tạo phẩm được tạo khác trong hệ thống kiểm soát phiên bản, tôi khuyên bạn nên đặt tất cả trong hệ thống kiểm soát phiên bản. Nó thực sự dễ dàng để lấy * tất cả mọi thứ * cho một phiên bản cụ thể và gỡ lỗi nó với fuss tối thiểu. –

4

Ngoài các tệp nhị phân như mọi người khác đã đề cập, tôi khuyên bạn nên thiết lập một số symbol serversource server và đảm bảo bạn có được thông tin chính xác và thông tin đó. Nó sẽ hỗ trợ gỡ lỗi rất nhiều.

5

Đây không phải là câu trả lời trực tiếp cho câu hỏi của bạn, nhưng đừng quên kiểm soát phiên bản thiết lập bản dựng hàng đêm. Khi cấu trúc dự án thay đổi, bạn có thể phải thay đổi quá trình xây dựng, điều này sẽ phá vỡ các phiên bản cũ hơn từ thời điểm đó.

0

Tôi sẽ lưu các tệp nhị phân được xây dựng của bạn chính xác miễn là chúng có cơ hội đi vào sản xuất hoặc được một số nhóm khác sử dụng (như nhóm QA). Một khi một cái gì đó đã để lại sản xuất, những gì bạn làm với nó có thể thay đổi rất nhiều. Đối với rất nhiều đội, họ sẽ giữ chỉ là xây dựng trước đây gần đây nhất của họ xung quanh (cho rollback) và nếu không loại bỏ xây dựng của họ.

Những người khác có yêu cầu pháp lý để giữ bất kỳ thứ gì được đưa vào sản xuất trong khoảng 7 năm (ngân hàng).Nếu bạn là một công ty sản phẩm, tôi sẽ lưu giữ bất kỳ nhị phân nào mà khách hàng có thể đã cài đặt trong trường hợp một nhân viên hỗ trợ kỹ thuật muốn cài đặt cùng một phiên bản.

3

Một ai ngạc nhiên khi tôi đã học về thời gian gần đây: Nếu bạn đang ở trong một môi trường mà có thể được kiểm toán, bạn sẽ muốn lưu tất cả các sản phẩm của xây dựng của bạn, sản lượng kịch bản, trình biên dịch ra vv

Đó là cách duy nhất bạn có thể xác minh cài đặt trình biên dịch của mình, tạo các bước, v.v.

Ngoài ra, lưu chúng bao lâu và nơi lưu chúng?

Lưu chúng cho đến khi bạn biết rằng bản dựng sẽ không được sản xuất, miễn là bạn có các bit được biên dịch xung quanh.

Một nơi hợp lý để lưu chúng là hệ thống SCM của bạn. Một lựa chọn khác là sử dụng một công cụ sẽ tự động lưu chúng cho bạn, như AnthillPro và ilk của nó.

1

Chúng tôi đang làm một cái gì đó gần với "nhúng" phát triển ở đây, và tôi có thể cho bạn biết những gì chúng ta tiết kiệm:

  • số SVN sửa đổi, dấu thời gian, cũng như máy nó được xây dựng trên và bởi (cũng được ghi vào các tệp nhị phân xây dựng)
  • nhật ký xây dựng đầy đủ, cho biết đó là bản dựng đầy đủ hay không, bất kỳ đầu ra thú vị (STDERR) nào mà công cụ tạo dữ liệu được tạo ra, danh sách các tệp được biên dịch và cảnh báo trình biên dịch (nén rất tốt, là văn bản)
  • các tệp nhị phân thực tế (cho bất kỳ nơi nào từ 1-8 cấu hình xây dựng)
  • các tệp được tạo ra như một tác dụng phụ của liên kết: tệp lệnh liên kết, bản đồ địa chỉ và loại tệp "tệp kê khai" cho biết nội dung được ghi vào tệp nhị phân cuối cùng (CRC và kích thước cho mỗi tệp), cũng như cơ sở dữ liệu gỡ lỗi (.pdb equivalent)

Chúng tôi cũng gửi kết quả chạy một số công cụ trên các tệp "tác dụng phụ" tới người dùng quan tâm. Chúng tôi không thực sự lưu trữ những vì chúng ta có thể tái tạo chúng sau này, nhưng các báo cáo này bao gồm:

  • tổng và đồng bằng kích thước hệ thống tập tin, chia nhỏ theo loại tập tin và/hoặc thư mục tổng
  • và đồng bằng của phần mã kích cỡ (.text, .data, .rodata, .bss, .sinit, v.v.)

Khi chúng tôi có các xét nghiệm đơn vị hoặc thử nghiệm chức năng (ví dụ: kiểm tra khói) đang chạy, kết quả này sẽ hiển thị trong nhật ký dựng.

Chúng tôi chưa đưa ra bất kỳ điều gì - được đưa ra, mục tiêu xây dựng của chúng tôi thường kết thúc ở ~ 16 hoặc 32 MiB cho mỗi cấu hình và chúng khá khả thi.

Chúng tôi giữ các bản sao không nén của các tệp nhị phân trong khoảng 1 tuần để dễ truy cập; sau đó chúng tôi chỉ giữ phiên bản được nén nhẹ. Khoảng mỗi tháng một lần, chúng tôi có một tập lệnh trích xuất từng tệp .zip mà quá trình xây dựng tạo và 7-zips toàn bộ tháng tạo kết quả đầu ra cùng nhau (chỉ tận dụng các khác biệt nhỏ cho mỗi bản dựng).

Một ngày trung bình có thể có một hoặc hai bản dựng cho mỗi dự án ... Máy chủ xây dựng sẽ thức dậy sau mỗi 5 phút để kiểm tra các khác biệt và bản dựng có liên quan. Một đầy đủ .7z trên một dự án rất tích cực cho một tháng có thể là 7-10GiB, nhưng nó chắc chắn là giá cả phải chăng.

Đối với hầu hết các phần, chúng tôi đã có thể chẩn đoán mọi thứ theo cách này. Thỉnh thoảng có một trục trặc trên các hệ thống xây dựng và một tập tin không thực sự là một sửa đổi nó được cho là khi một xây dựng xảy ra, nhưng thường có đủ bằng chứng về điều này trong các bản ghi. Đôi khi chúng tôi phải tìm ra một công cụ hiểu định dạng cơ sở dữ liệu gỡ lỗi và cấp cho nó một vài địa chỉ để chẩn đoán sự cố (chúng tôi có ngăn xếp tự động được tích hợp vào sản phẩm). Nhưng thông thường tất cả các thông tin cần thiết là có.

Chúng tôi chưa phải giải nén các lưu trữ .7z, chưa kể. Nhưng chúng tôi có thông tin ở đó và tôi có một số ý tưởng thú vị về cách khai thác các bit dữ liệu hữu ích từ đó.

+0

Tôi thích câu trả lời của bạn; cảm ơn vì đã viết nó. –

1

Lưu nội dung không thể sao chép dễ dàng. Tôi làm việc trên FPGAs, nơi chỉ có đội FPGA có các công cụ và một số lõi (thư viện) của thiết kế được cấp phép để biên dịch trên chỉ có một máy. Vì vậy, chúng tôi lưu bitstream đầu ra. Nhưng hãy thử kiểm tra chúng hơn một cái khác thay vì với dấu ngày/giờ/phiên bản.

+0

Tôi phải tra cứu nó. FPGA = Field Gate Gate Gate. http://en.wikipedia.org/wiki/FPGA –