Z jakich narzędzi rozwoju i tworzenia cykli życia korzystasz?

Question

Pracuję nad przeniesieniem mojego obecnego projektu z około 20 programistów do nowoczesnego środowiska programistycznego i kompilacji. Obecnie korzystamy z systemu kontroli źródła opartego na RCS i powiązanego systemu śledzenia problemów, zarówno z aplikacjami Motif. Nie ma formalnego procesu tworzenia produkcji, tylko działa.

Jestem zainteresowany:

• Development Tools
• Kontrola wersji
• Issue Tracking
• Dependency Zarządzanie
• Configuration Management
• Automated Building
• Automated Testing
• Continuous Integration
• Artifact Zarządzanie
• Zarządzanie Release
• Zarządzanie Wdrożenie
• Wymagania Tracing
• Co dalej?

Jestem zainteresowany nie tylko narzędziami, z których korzystasz, ale także ich integracją, łatwością konfiguracji i użytkowania oraz tym, jak je lubią zarówno programiści, jak i kierownictwo. Nasz projekt to połączenie języka Java, C++ i VHDL, ale nadal chciałbym usłyszeć od ludzi z innymi językami. Idę obecnie ścieżką zaćmienia, subwersji, trac, maven, hudson i nexus.

Co więcej, czy istnieje lepszy termin niż "Cykl budowy produktu", który obejmuje nie tylko budynek, ale także przepływ kodu od momentu, w którym twórca go tworzy, do czasu jego zbudowania, przetestowania iw systemie produkcyjnym? "Build Lifecycle" wydaje się być ograniczony, ale "Project Lifecycle" jest już zajęty.

Answer 1

• Development Tools JetBrains IntelliJ IDEA
• Kontrola wersji Subversion
• Issue Tracking Atlassian Jira
• Zależność Zarządzanie Maven
• Configuration Management TeamCity
• Automated Building TeamCity
• Automated Testing JUnit (?)
• Continuous Integration TeamCity
• Artifact Zarządzanie Maven
• Release Zarządzanie człowiek rozumny
• Zarządzanie Wdrożenie Maven/Homo Sapien
• Wymagania Tracing myślenie życzeniowe
• One-Off Automatyka Bash
• Twórca-do-Developer Documentation MediaWiki

Answer 2

Nienawidzę Mavena mniej niż nienawidzę mrówki, a dla Javy trzeba wybrać jedno z tych złych. Jeśli dopiero zaczynasz, wybierz Mavena, zwłaszcza, że ​​już wiesz, że twój "cykl życia kompilacji" obejmuje 12 różnych i złożonych dyscyplin! Będziesz musiał wybrać konwencje dla nich wszystkich. Ratuj sobie kłopoty i idź z konwencjami, które Maven już ustanowił.

Do ciągłej integracji i ogólnej automatyzacji kompilacji lubię Hudson.

Answer 3

W ciągu ostatnich dwóch lat stopniowo przechodziliśmy od strategii "każdy projekt ma swój własny zestaw narzędzi" do rozwiązania Trac + SVN + SCons i jesteśmy z tego całkiem zadowoleni.

Przejście na SCons było trochę pracy, ale naprawdę się opłaciło. Mamy heterogeniczne środowisko, głównie C/C++ dla różnych wbudowanych platform, modułów jądra, niektórych aplikacji desktopowych i różnych modułów Pythona jako kodu kleju. SCons naprawdę świeci, gdy chcesz dodać wsparcie dla własnych kompilatorów i niszowych narzędzi i musisz dostosować system kompilacji do swoich wymagań. Wcześniej musieliśmy używać innego GUI dla prawie każdej platformy wbudowanej - teraz, gdy SCons bezpośrednio wywołuje kompilatory, cykl pracy nieznacznie się poprawił.

Nasi programiści używali Emacsa lub Vima i nikt nie chciał przełączać się na nic innego, więc (na szczęście) tak się stało. Nie jestem obeznany z wdrażaniem, więc nie mogę o tym mówić.

Answer 4

Jesteśmy sklepem MS przy użyciu VS2008. Używamy Subversion z Tortoise do SCC i wersjonowania, a nasze repozytorium jest hostowane online, aby nasz distibuted team mógł z niego korzystać. Do budowy używamy Hudson i CI, znacznie lepiej niż Nant lub MSBuild. Śledzenie problemów to Bugzilla. Zautomatyzowane testowanie to NUnit

Do narzędzi, których należy unikać, należy Team Foundation Server i Sharepoint, również nieprzydatne do użytku w świecie rzeczywistym.

BTW Czy ktoś zna dobre narzędzie Scrum, które może generować wykresy wypalania, idealnie pasujące do Basecamp?

Answer 5

Jeśli pracujesz z .NET, ciężko jest pokonać Team Foundation Server w celu integracji z Visual Studio. Zawiera narzędzia programistyczne, kontrolę wersji, śledzenie problemów, zarządzanie konfiguracją, automatyczne testowanie, testowanie jednostek, zautomatyzowane budowanie, zarządzanie artefaktami i wszystko, co opisałeś.

Oczywiście system TFS jest drogi, często nieintuicyjny i brakuje niektórych funkcji w porównaniu do innych narzędzi, z których korzystałem. Jeśli masz licencję MSDN, możesz bezpłatnie korzystać z TFS for Workgroups (do 5 użytkowników IIRC).

Answer 6

używamy także szereg narzędzi, ale jesteśmy przenoszenie coraz więcej do Zed Builds & Błędy. Nasze podstawowe środowisko programistyczne to Eclipse + Java, ale robimy także Visual Studio (wszystkie 'em) i co najmniej 5 różnych buildów platform uniksowych.

Oto pełna lista:

• Development Tools - Eclipse
• Version Control - Subversion
• Issue Tracking - Zed Builds & Bugs
• Zależność Management - Ant
• Configuration Management - Zed Builds & Bugs
• Automatyzuj d Building - Zed Builds & Bugs
• Automated Testing - JUnit
• Continuous Integration - Zed Builds & Bugs
• Artifact Management - Zed Builds & Bugs
• Zarządzanie Release - Zed Builds & Bugs
• Zarządzanie Deployment - Zed Builds & Bugs
• Wymagania Tracing - Zed Builds & Bugs
• One -off Automation - Zed Builds & Bugs
• Twórca-do-Developer - Zed Builds & Bugs

Answer 7

użyć svn i TAC na niektóre oof moich projektów i svn i FogBugz na innych. Bardzo dobrze się integrują.

Nadal używam skryptów wiersza poleceń dla kompilacji, ponieważ robią one wszystko, czego potrzebuję - w tym grepping dla błędów i wyników e-mailingu, ale dni tej instalacji są ponumerowane. Zajmuję się wieloplatformowymi narzędziami do kompilacji.

Używam Inno dla uwolnień Win32. Brak produktów wysyłkowych na inną platformę - nie wiesz, jak je wdrożyć.

Nie rozwiązać wiele innych przedmiotów można wymienić inne niż na jakiejś dokumentacji pomocniczej oraz w kodzie i śledzenie problemów.

Answer 8

Team Foundation Server i Visual Studio.

Pamiętam, kiedy moim ideałem był wizualny debugger C firmy Sun, a kontrola źródła kopiowała wszystkie pliki źródłowe do nowego nazwanego katalogu i umieszczała go na serwerze, który miał być zarchiwizowany.

Tylko nie było