Xây dựng Hàng đêm: Tại sao tôi nên làm điều đó?

Question

Tại sao tôi nên làm Xây dựng Hàng đêm?

Answer 1

Xây dựng ban đêm không phải lúc nào cũng cần thiết - Tôi nghĩ chúng chỉ thực sự hữu ích cho các dự án lớn. Nhưng nếu bạn đang ở trong một dự án lớn, xây dựng hàng đêm là cách tốt để kiểm tra mọi thứ đang hoạt động - bạn có thể chạy tất cả các bài kiểm tra (bài kiểm tra đơn vị, bài kiểm tra tích hợp), xây dựng tất cả mã của bạn - ngắn gọn, xác minh rằng không có gì bị hỏng trong dự án của bạn.

Nếu bạn có dự án nhỏ hơn, thời gian xây dựng và thử nghiệm của bạn sẽ ngắn hơn, do đó, bạn có thể đủ khả năng để thực hiện các công việc thường xuyên hơn.

Answer 2

Vâng ... tôi đoán điều đó phụ thuộc rất nhiều vào dự án của bạn, tất nhiên. Nếu đó chỉ là dự án sở thích của bạn, không có bản phát hành, không phụ thuộc và không có ai ngoài bạn gửi mã, nó có thể là quá mức cần thiết.

Nếu, mặt khác, có một nhóm các nhà phát triển tất cả gửi mã, xây dựng hàng đêm tự động sẽ giúp bạn đảm bảo chất lượng của mã trong kho lưu trữ. Nếu ai đó làm điều gì đó "phá vỡ xây dựng" cho tất cả những người khác, nó sẽ nhanh chóng được chú ý. Có thể phá vỡ xây dựng mà không cần chú ý, ví dụ bằng cách quên thêm một tệp mới vào kho lưu trữ, và các bản dựng hàng đêm ở một vị trí tập trung sẽ phát hiện ra chúng một cách nhanh chóng.

Có tất nhiên những lợi ích khác có thể có, tôi chắc chắn những người khác sẽ cung cấp chúng. :)

Answer 3

Nó cũng phụ thuộc vào kích thước và cấu trúc của (các) nhóm làm việc trong dự án của bạn. Nếu có các nhóm khác nhau dựa vào API của nhau, thì có thể có nhiều ý nghĩa để có các bản dựng hàng đêm để tích hợp thường xuyên. Nếu bạn đang hacking đi với chỉ một hoặc hai đồng đội có thể hoặc có thể không có giá trị nó.

Answer 4

Tôi nghĩ chúng rất quan trọng đặc biệt đối với các dự án có nhiều hơn 1 người. Nhóm nghiên cứu cần phải biết càng sớm càng tốt nếu ai đó:

• kiểm tra trong một tập tin xấu
• không kiểm tra trong một file
• ...

Answer 5

Bạn nên làm đêm xây dựng để đảm bảo rằng codebase của bạn vẫn khỏe mạnh.

Một tác dụng phụ của việc xây dựng hàng đêm là nó buộc nhóm tạo và duy trì tập lệnh xây dựng hoàn toàn tự động. Điều này giúp đảm bảo rằng quá trình xây dựng của bạn được ghi lại và có thể lặp lại.

Automated xây dựng là tốt ở việc tìm kiếm các vấn đề sau:

• Ai đó kiểm tra trong một cái gì đó mà phá vỡ thứ.
• Ai đó quên kiểm tra tệp cần thiết hoặc thay đổi.
• Tập lệnh xây dựng của bạn không còn hoạt động nữa.
• Máy xây dựng của bạn bị hỏng.

Thực hiện đêm này đảm bảo rằng bạn gặp phải các vấn đề như vậy trong vòng 24 giờ kể từ khi chúng xảy ra. Đó là thích hợp hơn để tìm kiếm tất cả các vấn đề 24 giờ trước khi bạn có nghĩa vụ phải cung cấp phần mềm.

Bạn cũng nên, tất nhiên, có các kiểm tra đơn vị tự động được chạy cho mỗi bản dựng hàng đêm.

Answer 6

Xây dựng ban đêm chỉ cần thiết cho các dự án lớn đáng kể (khi mất quá nhiều thời gian để xây dựng thường xuyên trong ngày). Nếu bạn có một dự án nhỏ mà không mất nhiều thời gian để xây dựng, bạn có thể xây dựng nó khi bạn nhận được các phần chức năng của mã được thực hiện để bạn biết rằng bạn đã không gây rối bất cứ điều gì lên trong các procees. Tuy nhiên, với các dự án lớn này là không thể vì thế điều quan trọng là để xây dựng dự án chỉ để cho bạn biết rằng tất cả mọi thứ vẫn còn để

Answer 7

làm việc cá nhân tôi đã tìm thấy tích hợp liên tục là tốt hơn so với đêm xây dựng:
http://en.wikipedia.org/wiki/Continuous_integration

Tôi thậm chí sử dụng nó trên một dự án người đàn ông, nó tuyệt vời như thế nào nhanh chóng, bạn có thể phơi bày các vấn đề và chăm sóc chúng ngay tại đó.

Answer 8

Bạn không thực sự, những gì bạn cần là Tích hợp liên tục và thử nghiệm tự động (bước xa hơn so với xây dựng hàng đêm).

Nếu bạn nghi ngờ bạn nên đọc this article by Martin Fowler about Continuous Integration. Để tóm tắt, bạn muốn xây dựng và kiểm tra càng sớm càng tốt để phát hiện lỗi ngay lập tức để chúng có thể được khắc phục trong khi những gì bạn đang cố gắng đạt được khi bạn gây ra chúng vẫn còn mới mẻ trong tâm trí của bạn.

Answer 9

Tôi thực sự khuyên bạn nên làm các bản dựng mỗi khi bạn đăng ký. Nói cách khác, tôi khuyên bạn nên thiết lập một hệ thống Tích hợp liên tục.

Ưu điểm của hệ thống như vậy và các chi tiết khác có thể được tìm thấy in Fowler's article và on the Wikipedia entry ở những nơi khác.

Theo kinh nghiệm cá nhân của tôi, đó là vấn đề kiểm soát chất lượng: mỗi lần mã (hoặc kiểm tra, có thể được xem như là một dạng yêu cầu) đều được sửa đổi, các lỗi có thể bị xâm nhập. xây dựng sản phẩm vì nó sẽ được vận chuyển và thực hiện tất cả các thử nghiệm có sẵn. Việc này thường được thực hiện, các lỗi ít có khả năng sẽ được phép tạo thành một thuộc địa. Do đó, các chu kỳ hàng ngày (hàng đêm) hoặc liên tục được ưu tiên. Ngoài ra, cho dù bạn giới hạn quyền truy cập o dự án của bạn cho nhà phát triển hay nhóm người dùng lớn hơn, bản dựng hàng đêm cho phép mọi người tham gia 'phiên bản mới nhất', giảm thiểu nỗi đau khi kết hợp đóng góp của chính họ vào mã.

Answer 10

Bất kỳ xây dựng tự động hóa là tốt hơn so với không xây dựng tự động :-)

Cá nhân, tôi thích hàng ngày xây dựng - cách mà nếu xây dựng không làm việc thì tất cả mọi người xung quanh để làm cho nó cố định. Trong thực tế, nếu có thể thì xây dựng Continuous Integration là cách để đi (tức là xây dựng trên mọi check-in) vì nó giảm thiểu số lượng thay đổi giữa build và do đó giúp dễ dàng biết ai đã phá vỡ xây dựng và cũng dễ dàng sửa chữa bản dựng.

Answer 11

Có nhiều lý do, một số sẽ có nhiều áp dụng hơn những người khác

• Nếu dự án của bạn đã được làm việc trên bởi hai hoặc nhiều người
• Đó là một cách tốt để lấy phiên bản mới nhất của mã mà bạn không được làm việc trên
• một build đêm cung cấp một lát trong thời điểm hiện trạng của mã
• một xây dựng hàng đêm sẽ cung cấp cho bạn một xây dựng ổn định nếu bạn cần phải gửi mã để người

Answer 12

Xây dựng ban đêm lý tưởng để thực hiện phân tích mã tĩnh (xem qalab và các dự án thu thập số liệu thống kê từ nếu bạn đang ở trong thế giới java). Thật không may, đây là điều hiếm khi được thực hiện.

Answer 13

Bạn muốn tạo các bản dựng trên lịch biểu thông thường để bắt gặp sự cố với tích hợp mã giữa các nhà phát triển. Lý do bạn muốn làm điều này hàng đêm, trái ngược với hàng tuần hoặc theo lịch trình dài hơn, là bạn càng chờ đợi để khám phá các loại vấn đề này thì càng khó giải quyết chúng hơn. Việc thực hành xây dựng trên mọi kiểm tra trong (Continuous Integration) chỉ là thực hiện quy trình xây dựng hàng đêm đến một cực đoan hợp lý.

Lợi ích phụ của việc có quy trình xây dựng lặp lại cũng rất quan trọng trong thời gian dài. Nếu bạn làm việc trên một đội ngũ có nhiều dự án đang diễn ra, thì tại một thời điểm nào đó bạn sẽ cần phải có thể dễ dàng tạo lại một bản dựng cũ, có lẽ để tạo bản vá. :(

Bạn càng tự động hóa quá trình xây dựng, bạn càng tiết kiệm được nhiều thời gian hơn cho mỗi lần xây dựng tiếp theo. . :)

Answer 14

Tôi đã làm công trình xây dựng (trong số những thứ khác) trong 16 năm. Tôi là một người tin tưởng mạnh mẽ trong việc xây dựng sớm, xây dựng thường xuyên, hội nhập liên tục. Vì vậy, điều đầu tiên tôi làm với một dự án là thiết lập cách nó sẽ được xây dựng (Java: Ant hoặc Maven; .NET: NAnt hoặc MSBuild) và cách nó sẽ được quản lý (Subversion hoặc một số điều khiển phiên bản khác). Sau đó, tôi sẽ thêm Tích hợp liên tục (CruiseControl hoặc CruiseControl.NET) tùy thuộc vào nền tảng, sau đó để cho các nhà phát triển khác mất.

Khi dự án phát triển và nhu cầu báo cáo và tài liệu tăng lên, cuối cùng, các bản dựng sẽ mất nhiều thời gian hơn để chạy. Tại thời điểm đó, tôi sẽ chia các bản dựng thành các bản dựng liên tục (chạy trên checkin) chỉ biên dịch và chạy các bài kiểm tra đơn vị và các bản dựng hàng ngày để xây dựng mọi thứ, chạy tất cả các báo cáo và xây dựng bất kỳ tài liệu được tạo nào. Tôi cũng có thể thêm công cụ phân phối gắn thẻ kho lưu trữ và thực hiện bất kỳ gói bổ sung nào cho việc phân phối khách hàng. Tôi sẽ sử dụng các mục tiêu xây dựng chi tiết để quản lý chi tiết, để bất kỳ nhà phát triển nào cũng có thể xây dựng bất kỳ phần nào của hệ thống - máy chủ Tích hợp liên tục sử dụng các bước xây dựng giống hệt như bất kỳ nhà phát triển nào. Quan trọng nhất, chúng tôi không bao giờ cung cấp một bản dựng để thử nghiệm hoặc một khách hàng không được xây dựng bằng cách sử dụng máy chủ xây dựng.

Đó là những gì tôi làm - đây là lý do tại sao tôi làm điều đó (và tại sao bạn cũng nên như vậy):

Giả sử bạn có một ứng dụng điển hình, với nhiều dự án và một số nhà phát triển. Trong khi các nhà phát triển có thể bắt đầu với một môi trường phát triển chung, nhất quán (cùng một hệ điều hành, cùng một bản vá, cùng một công cụ, cùng một trình biên dịch), trong suốt thời gian môi trường của chúng sẽ phân kỳ. Một số nhà phát triển sẽ áp dụng tôn giáo tất cả các bản vá bảo mật và nâng cấp, những người khác sẽ không.Một số nhà phát triển sẽ thêm các công cụ mới (có thể tốt hơn), những công cụ khác thì không. Một số sẽ nhớ cập nhật không gian làm việc hoàn chỉnh của họ trước khi xây dựng; những người khác sẽ chỉ cập nhật một phần của dự án mà họ đang phát triển. Một số nhà phát triển sẽ thêm mã nguồn và tệp dữ liệu vào dự án, nhưng quên thêm chúng vào điều khiển nguồn. Những người khác sẽ viết các bài kiểm tra đơn vị phụ thuộc vào các điều kiện cụ thể của môi trường của họ. Kết quả là, bạn sẽ nhanh chóng thấy được "Vâng, nó xây dựng/hoạt động trên máy của tôi" lý do.

Bằng cách có một máy chủ riêng biệt, ổn định, nhất quán, nổi tiếng để xây dựng ứng dụng của bạn, bạn sẽ dễ dàng khám phá các loại sự cố này và bằng cách chạy các bản dựng từ mọi cam kết, bạn sẽ có thể xác định được sự cố len lỏi vào hệ thống. Quan trọng hơn, bởi vì bạn sử dụng một máy chủ riêng biệt để xây dựng và đóng gói ứng dụng của bạn, nó sẽ luôn luôn gói mọi thứ theo cùng một cách, mọi lúc. Không có gì tệ hơn là việc một nhà phát triển gửi một bản dựng tùy chỉnh cho một khách hàng, làm cho nó hoạt động, và sau đó không có ý tưởng làm thế nào để tái tạo các tùy chỉnh.

Answer 15

Tùy thuộc vào độ phức tạp của tích hợp liên tục sản phẩm của bạn có thể hoặc không thể chạy một bộ thử nghiệm đầy đủ.

Hãy tưởng tượng Cisco thử nghiệm một bộ định tuyến với 1000 lần thiết lập khác nhau để kiểm tra. Để chạy một bộ thử nghiệm đầy đủ trên một số sản phẩm cần có thời gian. Đôi khi tuần. Vì vậy, bạn cần xây dựng cho các mục đích khác nhau. Xây dựng hàng đêm có thể là cơ sở cho một bộ thử nghiệm toàn diện hơn.

Answer 16

Khi tôi thấy câu hỏi này, trước tiên tôi đã tìm kiếm câu trả lời Joel Spolsky's. Bit thất vọng, vì vậy tôi dự định thêm nó ở đây.

Hy vọng mọi người đều biết về số Joel Test on Careers.

Từ blog của mình trên The Joel Test: 12 Steps to Better Code

3. Bạn làm hàng ngày được xây dựng?

Khi bạn đang sử dụng kiểm soát nguồn, đôi khi một lập trình viên vô tình kiểm tra thứ gì đó phá vỡ bản dựng. Ví dụ: họ đã thêm tệp nguồn mới và mọi thứ biên dịch tốt trên máy của họ, nhưng họ quên thêm tệp nguồn vào mã kho lưu trữ. Vì vậy, họ khóa máy của họ và về nhà, lãng quên và hạnh phúc. Nhưng không ai khác có thể làm việc, vì vậy họ phải về nhà quá, không vui.

Phá vỡ công trình xây dựng rất tệ (và phổ biến) giúp xây dựng các tòa nhà hàng ngày để đảm bảo không bị vỡ. Trên các đội lớn, một cách tốt để đảm bảo rằng các sự cố được khắc phục ngay lập tức là để thực hiện việc xây dựng hàng ngày vào mỗi buổi chiều, ví dụ như giờ ăn trưa. Mọi người thực hiện nhiều lần đăng ký nhất có thể trước bữa trưa. Khi họ quay lại, việc xây dựng được thực hiện. Nếu nó hoạt động, tuyệt vời! Mọi người kiểm tra phiên bản mới nhất của nguồn và tiếp tục hoạt động. Nếu quá trình xây dựng không thành công, bạn sửa lỗi đó, nhưng mọi người có thể tiếp tục làm việc với phiên bản trước đó, không gián đoạn của nguồn.

Trên đội Excel chúng tôi đã có một quy tắc mà bất cứ ai đã phá xây dựng, như "trừng phạt" của họ, chịu trách nhiệm giữ trẻ các bản xây dựng cho đến khi một người nào đó khác đã phá vỡ nó. Đây là một động lực tốt để không phá vỡ công trình xây dựng và cách tốt nhất để xoay vòng mọi người thông qua quá trình xây dựng để mọi người tìm hiểu cách hoạt động của nó.

Mặc dù tôi không có cơ hội để tạo các bản dựng hàng ngày, tôi là một người hâm mộ tuyệt vời của nó.

Vẫn chưa thuyết phục? Hãy xem bản tóm tắt tại đây trong Daily Builds Are Your Friend!!