Bạn đang sử dụng công cụ phát triển và xây dựng vòng đời nào?

Question

Tôi đang làm việc để chuyển dự án hiện tại của khoảng 20 nhà phát triển sang môi trường phát triển và xây dựng hiện đại. Chúng tôi hiện đang sử dụng hệ thống kiểm soát nguồn dựa trên RCS và hệ thống theo dõi vấn đề liên quan, cả hai đều có giao diện người dùng Motif. Không có quy trình xây dựng sản xuất chính thức, nó chỉ là bất cứ công trình nào.

Tôi quan tâm đến:

• Công cụ phát triển
• Version Control
• Issue Tracking
• phụ thuộc quản lý
• Configuration Management
• Building Automated
• Kiểm thử tự động
• Continuous Integration
• Quản lý Artifact
• Quản lý phát hành
• triển khai Quản lý
• Yêu cầu Tracing
• gì khác?

Tôi quan tâm không chỉ những công cụ bạn sử dụng, mà còn tích hợp với nhau, cách thiết lập và sử dụng dễ dàng như thế nào và cách cả nhà phát triển và quản lý thích chúng. Dự án của chúng tôi là sự kết hợp của Java, C++ và VHDL, nhưng tôi vẫn muốn nghe từ những người có các ngôn ngữ khác. Tôi hiện đang đi xuống con đường của nhật thực, lật đổ, trac, maven, hudson, và nexus.

Ngoài ra, có một thuật ngữ tốt hơn "Xây dựng vòng đời" bao gồm không chỉ xây dựng, mà là dòng mã khi nhà phát triển tạo ra khi xây dựng, thử nghiệm và trong hệ thống sản xuất? "Vòng đời xây dựng" có vẻ hạn chế, nhưng "Vòng đời dự án" đã được sử dụng.

Answer 1

• Công cụ phát triển JetBrains IntelliJ IDEA
• Version Control Subversion
• Theo dõi Atlassian Jira
• phụ thuộc quản lý Maven
• quản lý cấu hình TeamCity
0 Issue
• Automated Building TeamCity
• Automated Testing JUnit (?)
• Tích hợp liên tục TeamCity
• Artifact Quản lý Maven
• phát hành Quản lý người
• triển khai Quản lý Maven/Homo Sapien
• Yêu cầu Tracing Wishful nghĩ
• One-Tắt Tự động hóa Bash
• Developer-to-Developer Documentation MediaWiki

Answer 2

Tôi ghét Maven ít hơn tôi ghét Ant, và đối với Java, bạn cần phải chọn một trong những tệ nạn đó. Nếu bạn mới bắt đầu, hãy chọn Maven, đặc biệt là vì bạn đã nhận ra rằng "vòng đời xây dựng" của bạn bao gồm 12 ngành khác nhau và phức tạp! Bạn sẽ phải chọn các quy ước cho tất cả chúng. Tiết kiệm cho mình những rắc rối và đi với các công ước Maven đã được thành lập.

Để tích hợp liên tục và tự động hóa xây dựng chung, tôi thích Hudson.

Answer 3

Trong hai năm qua, chúng tôi dần dần chuyển từ chiến lược "mọi dự án-có-riêng-công cụ" thành giải pháp Trac + SVN + SCons và khá hài lòng với điều đó.

Chuyển sang SCON là một chút công việc nhưng thực sự được đền đáp. Chúng tôi có một môi trường không đồng nhất, chủ yếu là C/C++ cho các nền tảng nhúng khác nhau, mô-đun hạt nhân, một số ứng dụng máy tính để bàn và các mô-đun Python khác nhau như mã keo. SCons thực sự tỏa sáng khi bạn muốn thêm hỗ trợ cho trình biên dịch của riêng bạn và các công cụ thích hợp và cần phải thích ứng với hệ thống xây dựng theo yêu cầu của bạn. Trước đây, chúng tôi đã phải sử dụng một GUI khác cho hầu hết mọi nền tảng nhúng - giờ đây SCons trực tiếp gọi các trình biên dịch, chu trình làm việc đã được cải thiện một chút.

Nhà phát triển của chúng tôi hoặc sử dụng Emacs hoặc Vim và không ai muốn chuyển sang bất kỳ điều gì khác, vì vậy chúng tôi (may mắn thay) đã gắn bó với điều đó. Tôi không quen với việc triển khai nên tôi không thể nói về điều đó.

Answer 4

Chúng tôi là một cửa hàng MS sử dụng VS2008. Chúng tôi sử dụng Subversion với Tortoise cho SCC và phiên bản và kho lưu trữ của chúng tôi được lưu trữ trực tuyến để nhóm phân biệt của chúng tôi có thể sử dụng nó. Đối với xây dựng chúng tôi đang sử dụng Hudson và CI, tốt hơn nhiều so với Nant hoặc MSBuild. Theo dõi vấn đề là Bugzilla. Thử nghiệm tự động là NUnit

Các công cụ cần tránh bao gồm Team Foundation Server và Sharepoint, quá clunky để sử dụng trong thế giới thực.

BTW Có ai biết một công cụ Scrum tốt, có thể tạo ra biểu đồ ghi đĩa, lý tưởng liên kết với Basecamp không?

Answer 5

Nếu bạn làm việc với .NET, thật khó để đánh bại Team Foundation Server để tích hợp với Visual Studio. Nó chứa các công cụ phát triển, kiểm soát phiên bản, theo dõi vấn đề, quản lý cấu hình, kiểm tra tự động, kiểm tra đơn vị, xây dựng tự động, quản lý tạo tác và mọi thứ khác mà bạn đã mô tả.

Tất nhiên, TFS là tốn kém, đôi khi không trực quan và thiếu một số tính năng so với các công cụ khác mà tôi đã sử dụng. Nếu bạn có một giấy phép MSDN, bạn có thể sử dụng TFS cho nhóm làm việc (lên đến 5 người dùng IIRC) miễn phí, mặc dù.

Answer 6

Chúng tôi cũng sử dụng một số công cụ, nhưng chúng tôi di chuyển nhiều hơn và nhiều hơn nữa để xây dựng Zed & Lỗi. Môi trường dev chính của chúng ta là Eclipse + Java, nhưng chúng ta cũng làm Visual Studio (tất cả các em), và ít nhất 5 nền tảng Unix khác nhau được xây dựng.

Dưới đây là danh sách đầy đủ:

• Công cụ phát triển - Eclipse
• Version Control - Subversion
• Issue Tracking - Zed Builds & Bugs
• phụ thuộc Management - Ant
• quản lý cấu hình - Zed Builds & Bugs
• Tự động hóa d Building - Zed Builds & Bugs
• Kiểm thử tự động - JUnit
• Continuous Integration - Zed Builds & Bugs
• Artifact Management - Zed Builds & Bugs
• Quản lý phát hành - Zed Builds & Bugs
• triển khai Quản lý - Zed Builds & Bugs
• Yêu cầu Tracing - Zed Builds & Bugs
• Một -Tự động tự động hóa - Zed Builds & Bugs
• Developer-to-Developer - Zed Builds & Bugs

Answer 7

tôi sử dụng svn và tac trên một số oof dự án và svn và fogbugz vào người khác của tôi. Chúng tích hợp rất tốt.

Tôi vẫn đang sử dụng tập lệnh dòng lệnh cho các bản dựng khi chúng làm mọi thứ tôi cần - bao gồm cả việc dò tìm lỗi và gửi kết quả gửi email nhưng ngày của thiết lập đó được đánh số. Tôi đang tìm kiếm các công cụ xây dựng đa nền tảng.

Tôi sử dụng Inno cho bản phát hành win32. Chưa có sản phẩm giao hàng nào cho nền tảng khác - không chắc chắn cách chúng tôi triển khai các sản phẩm đó.

Chúng tôi không đề cập đến nhiều mục khác mà bạn đề cập khác ngoài một số tài liệu phụ trợ và trong mã và theo dõi vấn đề.

Answer 8

Team Foundation Server và Visual Studio.

Tôi nhớ khi ide của tôi là trình gỡ lỗi C trực quan của Sun và kiểm soát nguồn đã sao chép tất cả các tệp nguồn vào một thư mục có tên mới và đặt nó trên máy chủ được cho là sao lưu.

Chỉ nó không