2011-12-02 25 views
7

Sản phẩm phần mềm của chúng tôi được tạo thành từ nhiều phần. Giả sử nó được làm bằng một phần trình điều khiển nhân, một dll người dùng và một phần mềm GUI. Trong quá trình phát triển, chúng tôi đang biên dịch và sử dụng tất cả chúng trong các phiên bản mới nhất, nhưng nó không giống nhau khi nói đến bản phát hành.Những công cụ nào tồn tại để giúp thu thập các yếu tố phần mềm khác nhau vào bản phát hành phần mềm hoàn chỉnh?

Thật vậy, phần hạt nhân phải được đóng băng sớm hơn phần kia. Sau đó, dll được đông lạnh, để có được thử nghiệm rộng rãi, và cuối cùng đông lạnh là GUI. Khi các tiến bộ của QA, chúng ta cần tạo các phiên bản mới hơn của bản phát hành đầy đủ với một GUI cố định, nhưng vẫn sử dụng trình điều khiển hạt nhân đã bao gồm trước đó và dll.

Tôi đã tự hỏi nếu có một công cụ tồn tại, điều đó sẽ quản lý phiên bản nào của từng phần phần mềm được sử dụng để tạo bản phát hành?

Công cụ này có thể tích hợp vào chuỗi công cụ, để xây dựng phiên bản của từng phần mềm được chọn và tập hợp chúng vào bộ cài đặt Windows hoặc gói Linux.

Chỉnh sửa: Chúng ta đang làm gì bây giờ?

Hiện tại, chúng tôi đang sử dụng SVN với công cụ xây dựng như công cụ CI cho Linux/gcc và Windows/VStudio. Chúng tôi đang ở chế độ nơi toàn bộ kho lưu trữ được phân nhánh/được gắn thẻ khi cần. Nhưng điều này làm tổn thương và làm cho quá trình phát hành trở nên đau đớn vì bây giờ có nhiều phần mềm tương đối độc lập hơn.

Chúng tôi đang nghĩ đến việc thay đổi bố cục kho lưu trữ để có một số dự án được phân nhánh/gắn thẻ độc lập. Điều này sẽ phù hợp hơn với chu kỳ phát triển và phát hành phần mềm. Nhưng sau đó, chúng tôi hoàn toàn sẽ cần một công cụ như vậy.

Sự cố liên quan đến việc có các phần mềm khác nhau, mỗi phần có các phiên bản được phân nhánh/gắn thẻ riêng, được tập hợp thành bản phát hành phần mềm đầy đủ.

Chỉnh sửa: Điều cần thiết.

Cuối cùng, tôi hiểu những gì tôi cần là trình quản lý gói cho Windows. Trình quản lý gói theo nghĩa của RPM hoặc trình quản lý DEB trên Linux.

Có ai biết về người quản lý gói trên Windows không?

+0

Tôi đã thấy điều này được xử lý thông qua kiểm soát phiên bản với phân nhánh thích hợp, công cụ tích hợp liên tục và xây dựng tập lệnh. Bạn hiện đang sử dụng cái gì để xây dựng hệ thống của mình? –

+0

@ThomasOwens: Đã trả lời khi chỉnh sửa câu hỏi. –

+0

Cảm ơn. Hãy để tôi suy nghĩ về điều này một chút. Tôi sẽ cố gắng trả lời khi tôi có câu trả lời và một vài chu kỳ rảnh rỗi. –

Trả lời

0

Một công cụ tôi đã chơi với là maven, nó rất thú vị trong cách nó đưa ra các vòng đời khác nhau. Bạn có thể sử dụng không chỉ cho các dự án java nhưng .net cũng như và có rất nhiều plugin ra khỏi đó, cũng như các kho lưu trữ tốt (tôi đang sử dụng một từ sonatype).

0

Tôi nghĩ rằng cụm từ bạn đang tìm kiếm là Software Configuration Management. Có một tài liệu khá đắt về nó ở đây: http://www.sei.cmu.edu/reports/87cm004.pdf.

+0

Cảm ơn, tôi đã xem cái này, nhưng nó có vẻ quá rộng. Ví dụ SCM bao gồm kiểm soát nguồn. Từ những gì tôi đang nghĩ về bây giờ, tôi cần một cái gì đó đằng sau kiểm soát nguồn. –

0

Điều rõ ràng nhất bạn có là vấn đề phụ thuộc giữa các phần khác nhau của phần mềm (như Kernel 1.0, Driver A 1.1, v.v.). Điều này sẽ cho tôi ấn tượng rằng bạn phải suy nghĩ về công cụ xây dựng của bạn nếu nó có khả năng quản lý các phụ thuộc mà không có âm thanh như thế. Vì vậy, bạn nên có một cái nhìn để Maven (đã đề cập), SCons (Tôi không chắc chắn) hoặc các công cụ khác như Ant kết hợp với Ivy. Bạn cần xác định một số loại đường cơ sở mô tả các mô-đun nào trong đó phiên bản làm việc cùng nhau và có thể được phát hành. Đây là siêu thông tin cần được xử lý bởi công cụ xây dựng. Bạn có thể tạo ra một cái gì đó của riêng bạn ... nhưng tôi không khuyên bạn nên làm như vậy.

0

Chúng tôi có một hệ thống nơi "thân cây" là những gì đang được sản xuất. Chúng tôi tạo một nhánh cho bản phát hành tiếp theo, khi nhà phát triển thực hiện các thay đổi của mình cho một vấn đề, anh ta kiểm tra chúng trong trình quản lý phát hành của chúng tôi và liên kết những tệp đã thay đổi với số phát hành hoặc ID lỗi đó.

Khi chúng tôi xây dựng, chúng tôi có thể giữ lại tất cả các thay đổi cho vấn đề mua chỉ không bao gồm vấn đề đó trong bản dựng của chúng tôi. Khi chúng ta thu gọn nhánh, chúng ta có thể thấy tất cả các tệp đã thay đổi nhưng không được bao gồm trong bản dựng cuối cùng - chúng tôi loại trừ chúng khỏi sự sụp đổ.

Phần tốt đẹp khác của hệ thống này là phải mất tất cả các tập lệnh SQL và kết hợp chúng (thông minh) thành 1 tệp SQL lớn được sử dụng để quảng bá bản phát hành cho Kiểm tra, QA và sau đó Prod.

có thể tìm thêm HERE.

2

Để xử lý nguồn của bạn, bạn chắc chắn muốn được phân nhánh thành phần riêng lẻ của bạn. Các tệp nhị phân được xử lý qua package manager. Các phương pháp hay nhất cho điều đó sẽ thay đổi dựa trên hệ điều hành đích của bạn. Công ty của tôi thực hiện phần mềm nhúng, vì vậy chúng tôi quản lý phần mềm đó với các tập lệnh tùy chỉnh mà chúng tôi đã thiết kế. Trên Linux, bạn muốn tạo các gói .deb hoặc .rpm. Here's hướng dẫn cho Ubuntu. Tôi không quen thuộc với Windows, nhưng InstallShield là một lựa chọn phổ biến trong phần mềm tôi đã cài đặt.

Tất cả chúng đều phải có cơ chế để chỉ định phạm vi phiên bản phụ thuộc. Bạn có thể yêu cầu phiên bản chính xác, phiên bản nhất định hoặc phiên bản mới hơn hoặc bất kỳ thứ gì giữa hai phiên bản. Sau đó, bạn có một gói "cha mẹ" không có tệp nhị phân, nhưng chỉ định rõ các phiên bản của các gói thành phần. Điều đó sẽ cho phép bạn nâng cấp một thành phần trong khi vẫn giữ lại các tệp nhị phân cho các thành phần khác. Nếu bạn muốn giữ tất cả trong một gói, có rất ít lý do để không xây dựng lại toàn bộ thứ từ nguồn. Nếu kịch bản xây dựng của bạn là phiên bản được kiểm soát, các tệp nhị phân của bạn sẽ giống nhau.

+0

Điều đó thực sự tốt. Cảm ơn. Bây giờ, chỉ cần tưởng tượng rằng tôi muốn sử dụng chính xác 'hạt nhân 0,1' * nhị phân * được tạo ra cho 'SR-0.1' thành' SR-0.2'. –

+0

Hiểu sai câu hỏi. Xem chỉnh sửa của tôi. –

+0

Cảm ơn rất nhiều. Tôi đã sản xuất các gói deb và rpm, nhưng các công cụ Linux được tạo ra sau các tệp nhị phân Windows và đó là các tệp nhị phân Windows được thử nghiệm rộng rãi trước đó. Điểm khó khăn của chúng tôi là gói Windows chứa các tệp nhị phân từ nguồn và các tài liệu có thể sẵn sàng sau, sau khi thử nghiệm nhị phân. Do đó chúng ta phải tạo các gói mới với các tệp nhị phân cũ. Một chút phức tạp, tôi biết. –

0

Chúng tôi sử dụng Buckminster để quản lý mức tích hợp triển khai phần mềm.

Chúng tôi có kho khác nhau mã (nội gitsvn kho, và tham chiếu đến thư viện bên ngoài và kho, chẳng hạn như PyDev) và nó kéo chúng lại với nhau độc đáo, triển khai chỉ các thành phần cần thiết cho bất kỳ xây dựng nhất định.

Từ đó Tech Overview page:

Buckminster là một khuôn khổ thể hóa Nghị quyết & thành phần. Mục đích của nó là để có được các thành phần phần mềm cho bạn và thực hiện chúng trong một bối cảnh lựa chọn, điển hình là một không gian làm việc hoặc hệ thống tệp. Điều này áp dụng cho dù bạn đang xem những gì có sẵn trên máy cục bộ của bạn, trong tổ chức phát triển của bạn hoặc trong đám mây nguồn mở công cộng. Buckminster loại bỏ sự mơ hồ khỏi các mô tả thành phần, cho phép chia sẻ thành phần và tăng năng suất khi áp dụng trong phát triển, xây dựng, lắp ráp và triển khai các kịch bản.

Buckminster là một siêu khuôn khổ mở rộng, bao gồm ngôn ngữ siêu dữ liệu thành phần và thời gian chạy, có thể thực thi hoặc không đầu hoặc như một trình cắm thêm trong IDE Eclipse. Mặc dù Buckminster có thể được sử dụng để giải quyết việc xây dựng chung, lắp ráp các vấn đề triển khai &, nhưng nó không phải là một hệ thống quản lý thành phần hoặc xây dựng. Buckminster có thể tái sử dụng các khoản đầu tư hiện có trong một loạt các công cụ quản lý và xây dựng - Maven, ANT, CVS, SVN, PDE, vv - và được thiết kế để hạn chế tối đa các dịch vụ mà các công cụ bên ngoài có thể cung cấp.

Sử dụng Buckminster tôi có thể triển khai, trong một bước, bất kỳ phiên bản chính của phần mềm của chúng tôi, cùng với cấu hình cụ thể cho bất kỳ một trong những khách hàng của tôi.

Buckminster cũng tích hợp độc đáo với các máy chủ tích hợp liên tục Jenkins (nee Hudson) của chúng tôi.

Cuối cùng, Buickminster là làm cho nó có thể cho chúng tôi để di chuyển kho nguồn chủ yếu của chúng tôi từ một svn kho nguyên khối với một số hơn độ tinh hạt git kho một cách an toàn, quản lý cách. Phiên bản này, chúng tôi đã chuyển một thành phần chính của phần mềm của chúng tôi từ svn thành repositor của riêng mình git và trong khi có một số vấn đề tái tích hợp, chúng có thể quản lý được.

Bằng cách thực hiện chuyển đổi từng hệ thống, chúng tôi giảm đáng kể nguy cơ phá vỡ toàn bộ hệ thống khi di chuyển và phải hoàn nguyên khi sử dụng svn hoặc bị hỏng hệ thống triển khai.

Các vấn đề liên quan