Tại sao một người nên sử dụng một hệ thống xây dựng trên hệ thống được bao gồm như là một phần của một IDE?

Question

Tôi đã nghe nhiều người nói rằng nếu quá trình xây dựng của bạn đang nhấp vào nút xây dựng, quá trình xây dựng của bạn bị hỏng. Thông thường, điều này đi kèm với lời khuyên để sử dụng những thứ như make, cmake, nmake, MSBuild, v.v. Chính xác những công cụ này cung cấp biện pháp nào để duy trì tệp cấu hình riêng biệt theo cách thủ công?

EDIT: Tôi quan tâm nhất đến các câu trả lời có thể áp dụng cho một nhà phát triển làm việc trên một dự án dòng C++ ~ 20k, nhưng tôi cũng quan tâm đến trường hợp chung.

EDIT2: Có vẻ như không có câu trả lời hay nào cho câu hỏi này, vì vậy tôi đã tiếp tục và thực hiện nó CW. Đáp lại những người đang nói về Tích hợp liên tục, vâng, tôi hiểu hoàn toàn khi bạn có nhiều nhà phát triển trong một dự án có CI là tốt đẹp. Tuy nhiên, đó là một lợi thế của CI, không phải của việc duy trì các kịch bản xây dựng riêng biệt. Chúng là trực giao: Ví dụ, Team Foundation Build là một giải pháp CI sử dụng các tệp dự án của Visual Studio như cấu hình của nó.

Answer 1

Ngoài nhu cầu tích hợp liên tục mà mọi người khác đã giải quyết, bạn cũng có thể chỉ muốn tự động hóa một số khía cạnh khác của quá trình xây dựng của mình.Có thể nó đơn giản như tăng số phiên bản trên bản dựng sản phẩm hoặc chạy thử nghiệm đơn vị của bạn hoặc đặt lại và xác minh môi trường thử nghiệm của bạn hoặc chạy FxCop hoặc tập lệnh tùy chỉnh tự động xem xét mã để tuân thủ các tiêu chuẩn của công ty. Một kịch bản xây dựng chỉ là một cách để tự động hóa một cái gì đó ngoài việc biên dịch mã đơn giản của bạn. Tuy nhiên, hầu hết những thứ này cũng có thể được thực hiện thông qua các hành động biên dịch trước/biên dịch mà gần như mọi IDE hiện đại đều cho phép bạn thiết lập.

Thật vậy, trừ khi bạn có nhiều nhà phát triển cam kết với hệ thống kiểm soát nguồn của bạn hoặc có rất nhiều hệ thống hoặc ứng dụng dựa vào thư viện được chia sẻ và cần phải thực hiện CI, sử dụng tập lệnh xây dựng có thể quá mức so với các lựa chọn thay thế đơn giản hơn. Nhưng nếu bạn đang ở trong một trong những tình huống nói trên, máy chủ xây dựng chuyên dụng kéo từ điều khiển nguồn và xây dựng tự động phải là một phần thiết yếu trong kho vũ khí của đội bạn và cách dễ nhất để thiết lập là sử dụng make, MSBuild, Ant , v.v.

Answer 2

Nếu bạn có một quá trình xây dựng tích hợp liên tục, tiếp theo, nó sẽ được điều khiển bởi một tập lệnh Ant hoặc theo kiểu thực hiện. Quá trình CI của bạn sẽ kiểm tra mã kiểm soát phiên bản khi các thay đổi được phát hiện trên một máy xây dựng riêng biệt, biên dịch, thử nghiệm, gói, triển khai và tạo báo cáo tóm tắt.

Answer 3

Giả sử bạn có 5 người làm việc trên cùng một bộ mã. Mỗi người trong số 5 người đó đang thực hiện cập nhật cho cùng một tập hợp các tệp. Bây giờ bạn có thể nhấp vào nút xây dựng và bạn biết rằng bạn đang làm việc mã, nhưng những gì về khi bạn tích hợp nó với tất cả mọi người khác. Chỉ có bạn sẽ biết rằng nếu bạn nhận được của người khác và cố gắng. Điều này rất dễ dàng mỗi lần trong một thời gian, nhưng nó nhanh chóng trở nên mệt mỏi để làm điều này hơn và hơn nữa.

Với máy chủ xây dựng tự động thực hiện, nó sẽ kiểm tra xem mã có biên dịch cho mọi người mọi lúc không. Mọi người luôn biết nếu có điều gì đó sai với bản dựng, và vấn đề là gì, và không ai phải làm bất kỳ công việc nào để tìm ra nó. Những điều nhỏ nhặt thêm lên, có thể mất vài phút để kéo xuống mã mới nhất và cố gắng biên dịch nó, nhưng làm điều đó 10-20 lần một ngày nhanh chóng trở thành một sự lãng phí thời gian, đặc biệt nếu bạn có nhiều người làm việc đó. Chắc chắn bạn có thể có được bằng cách không có nó, nhưng nó là dễ dàng hơn nhiều để cho một quá trình tự động làm điều tương tự hơn và hơn nữa, sau đó có một người thực sự làm điều đó.

Đây cũng là một điều thú vị nữa. Quá trình của chúng tôi được thiết lập để kiểm tra tất cả các kịch bản sql là tốt. Không thể làm điều đó bằng cách nhấn nút xây dựng. Nó tải lại ảnh chụp nhanh của tất cả các cơ sở dữ liệu cần thiết để áp dụng các bản vá và chạy chúng để đảm bảo rằng tất cả chúng hoạt động và chạy theo thứ tự mà chúng được yêu cầu. Máy chủ xây dựng cũng đủ thông minh để chạy tất cả các bài kiểm tra đơn vị/kiểm tra tự động hóa và trả lại kết quả. Đảm bảo rằng nó có thể biên dịch là tốt, nhưng với một máy chủ tự động hóa, nó có thể xử lý nhiều bước tự động mà sẽ mất một người có thể một giờ để làm.

Thực hiện bước này xa hơn, nếu bạn có quy trình triển khai tự động cùng với máy chủ xây dựng, việc triển khai sẽ tự động. Bất kỳ ai có thể nhấn một nút để chạy quy trình và triển khai có thể chuyển mã sang qa hoặc sản xuất. Điều này có nghĩa là một lập trình viên không phải mất nhiều thời gian để thực hiện nó theo cách thủ công, đó là lỗi dễ xảy ra. Khi chúng tôi không có quy trình, nó luôn là một crap shoot có hay không mọi thứ sẽ được cài đặt chính xác, và nói chung nó là một quản trị mạng hoặc một lập trình viên phải làm điều đó, bởi vì họ phải biết cách cấu hình IIS và di chuyển các tập tin. Bây giờ ngay cả người qa cơ sở nhất của chúng tôi cũng có thể làm mới máy chủ, vì tất cả những gì họ cần biết là nhấn nút nào.

Answer 4

các hệ thống xây dựng IDE mà tôi đã sử dụng đều có thể sử dụng được từ những thứ như công cụ Tự động xây dựng/CI vì vậy không cần phải có tập lệnh xây dựng riêng biệt như vậy.

Tuy nhiên trên đầu trang của hệ thống xây dựng đó, bạn cần phải tự động kiểm tra, phiên bản, gắn thẻ kiểm soát nguồn và triển khai (và bất kỳ thứ gì khác bạn cần để phát hành sản phẩm của mình).

Vì vậy, bạn tạo các tập lệnh mở rộng quá trình tạo IDE và thực hiện các tính năng bổ sung.

Answer 5

Một lý do thực tế tại sao các mô tả IDE được quản lý không phải lúc nào cũng lý tưởng để thực hiện với điều khiển phiên bản và nhu cầu tích hợp với các thay đổi của các nhà phát triển khác (ví dụ: hợp nhất).

Nếu IDE của bạn sử dụng một tệp phẳng, có thể rất khó (nếu không phải là không thể) để hợp nhất hai tệp dự án thành một tệp. Nó có thể được sử dụng một định dạng dựa trên văn bản, như XML, nhưng XML nó nổi tiếng cứng với các công cụ khác biệt/hợp nhất tiêu chuẩn. Chỉ cần thực tế là mọi người đang sử dụng GUI để thực hiện các chỉnh sửa giúp bạn có nhiều khả năng kết thúc với những thay đổi không cần thiết trong các tệp dự án.

Với các tập lệnh xây dựng nhỏ hơn, phân tán (tệp CMake, Makefiles, v.v.), có thể dễ dàng điều chỉnh các thay đổi đối với cấu trúc dự án giống như bạn hợp nhất hai tệp nguồn. Một số người thích thế hệ dự án IDE (sử dụng CMake chẳng hạn) vì lý do này, ngay cả khi mọi người đang làm việc với cùng một công cụ trên cùng một nền tảng.

Answer 6

Một lý do để sử dụng hệ thống xây dựng mà tôi ngạc nhiên không ai khác đề cập đến là tính linh hoạt. Trong quá khứ, tôi cũng sử dụng hệ thống xây dựng dựng sẵn của IDE để biên dịch mã của mình. Tuy nhiên, tôi đã gặp phải một vấn đề lớn, khi IDE tôi đang sử dụng đã bị ngưng. Khả năng biên dịch mã của tôi được gắn với IDE của tôi, vì vậy tôi buộc phải làm lại toàn bộ hệ thống xây dựng của mình. Lần thứ hai, mặc dù, tôi đã không phạm sai lầm tương tự. Tôi đã triển khai hệ thống xây dựng của mình thông qua makefiles để tôi có thể chuyển đổi các trình biên dịch và các IDE theo ý muốn mà không cần phải triển khai lại hệ thống xây dựng nữa.

Tôi gặp sự cố tương tự tại nơi làm việc. Chúng tôi đã có một tiện ích trong nhà được xây dựng như một dự án Visual Studio. Đó là một tiện ích khá đơn giản và không cần cập nhật trong nhiều năm, nhưng gần đây chúng tôi đã tìm thấy một lỗi hiếm gặp cần sửa chữa. Để mất tinh thần của chúng tôi, chúng tôi phát hiện ra rằng tiện ích được xây dựng bằng cách sử dụng một phiên bản của Visual Studio mà là 5-6 phiên bản cũ hơn những gì chúng tôi hiện đang có. VS mới sẽ không đọc tập tin dự án phiên bản cũ một cách chính xác, và chúng tôi đã phải tạo lại dự án từ đầu. Mặc dù chúng tôi vẫn đang sử dụng cùng một IDE, sự khác biệt phiên bản đã phá vỡ hệ thống xây dựng của chúng tôi.

Khi bạn sử dụng hệ thống xây dựng riêng biệt, bạn hoàn toàn kiểm soát được. Việc thay đổi các IDE hoặc các phiên bản IDE sẽ không làm hỏng bất cứ thứ gì.Nếu hệ thống xây dựng của bạn dựa trên công cụ mã nguồn mở như make, bạn cũng không phải lo lắng về công cụ xây dựng của bạn bị gián đoạn hoặc bị từ chối vì bạn luôn có thể tạo lại chúng từ nguồn (cộng với lỗi sửa) nếu cần. Dựa trên hệ thống xây dựng của IDE, bạn có một điểm thất bại (đặc biệt là trên các nền tảng như Visual Studio cũng tích hợp trình biên dịch ), và trong tâm trí tôi đã đủ lý do để tách riêng hệ thống xây dựng và IDE của tôi.

Ở cấp độ triết học hơn, tôi tin tưởng rằng không phải là điều tốt để tự động hóa thứ gì đó mà bạn không hiểu. Bạn nên sử dụng tự động hóa để làm cho mình hiệu quả hơn, nhưng chỉ khi bạn hiểu rõ những gì đang diễn ra dưới mui xe (để bạn không bị kẹt khi tự động ngắt, nếu không có lý do nào khác). Tôi đã sử dụng hệ thống xây dựng dựng sẵn của IDE khi lần đầu tiên tôi bắt đầu lập trình vì nó dễ dàng và tự động. Sau đó tôi bắt đầu nhận thức rõ hơn rằng tôi đã không thực sự hiểu những gì đã xảy ra khi tôi nhấp vào nút "biên dịch". Tôi đã đọc một chút và bắt đầu tập hợp một kịch bản xây dựng đơn giản từ đầu, so sánh đầu ra của tôi với kịch bản của hệ thống xây dựng của IDE. Sau một thời gian tôi nhận ra rằng bây giờ tôi có sức mạnh để làm đủ mọi thứ khó khăn hoặc không thể thông qua IDE. Tùy chỉnh các tùy chọn dòng lệnh của trình biên dịch ngoài những gì IDE cung cấp, tôi đã có thể tạo ra một đầu ra nhỏ hơn, nhanh hơn một chút. Quan trọng hơn, tôi đã trở thành một lập trình viên tốt hơn bằng cách có kiến ​​thức thực sự về toàn bộ quá trình phát triển từ viết mã xuống tất cả các con đường thông qua việc tạo ra ngôn ngữ máy. Việc hiểu và kiểm soát toàn bộ quy trình từ đầu đến cuối cho phép tôi tối ưu hóa và tùy chỉnh tất cả nó theo nhu cầu của bất kỳ dự án nào mà tôi hiện đang làm việc.