Jakie narzędzia zalecają automatyczne tworzenie aplikacji?

Question

Jeszcze kilka lat temu programiści faktycznie tworzyli kompilacje, które trafiały do ​​klientów. Była to oczywiście katastrofa z powodów zbyt licznych, by ją wymienić.

Następnie, gdy zaczęliśmy uczyć się błędów naszych sposobów, szukaliśmy sposobu automatycznego zbudowania całej aplikacji na dedykowanej maszynie do budowania. Kultura w tamtym czasie była bardzo niechętna przynoszeniu narzędzi zewnętrznych, więc zbudowaliśmy własny system autobuild, pisząc aplikację VB.

To działało przez jakiś czas, dopóki struktura projektu nie zaczęła się zmieniać, dodano nowe projekty i musieliśmy zbudować aplikację na różne sposoby. Wtedy pojawiły się słabości naszego ręcznie zwiniętego autobuildera i, z biegiem czasu, coraz bardziej uciążliwe. Choroba ta posunęła się do punktu, w którym QA (która jest właścicielem naszego procesu budowania) nie może nawet utrzymać autobuildera, ponieważ wymaga coraz więcej umiejętności programistycznych. Za każdym razem, gdy dodajemy projekt lub zmieniamy coś w istniejącym projekcie, zużywa on więcej czasu dla programistów tylko po to, by działał. Były dni, kiedy nie byliśmy w stanie wyprodukować kompilacji, ponieważ system był zepsuty.

Jestem teraz w sytuacji, w której mogę zmienić ten proces, i zamierzam zepsuć cały system i umieścić coś innego w jego miejscu. Moje cele to:

• Posiadam system autobuildów, który może działać bez interwencji człowieka w określonym czasie każdego dnia. Powinien być w stanie zebrać cały kod źródłowy, skompilować wszystkie aplikacje, stworzyć konfiguracje, umieścić gotowe produkty w udziale sieciowym i ewentualnie uruchomić automatyczny system testowy do uruchomienia (używamy QTP).
• System autobuild powinien być wystarczająco elastyczny, aby łatwo przystosować się do zmian w projekcie bez konieczności poważnego remontu.
• Powinien być na tyle prosty, aby kontrola jakości mogła należeć do systemu i nie wymagać od deweloperów wprowadzania zmian w sposobie tworzenia kompilacji.

Jakie są twoje wrażenia? Czy możesz polecić system autobuild? Czy powinienem mieć inne cele?

Answer 1

Zdecydowanie zajrzyj do MSBuild, jeśli korzystasz ze stosu Microsoft.

Joel zawsze opowiada o tym, jak świetny jest model FinalBuilder, więc warto go również obejrzeć.

Answer 2

Obecnie używam CruiseControl zintegrowanego z Antem do sterowania projektami. Pozwala to na elastyczność harmonogramów kompilacji i oznacza, że ​​można zautomatyzować cały proces budowy dość łatwo za pomocą skryptów Ant. Ponadto, podczas okresów napraw wady można ustawić CruiseControl, aby obserwował przekazywanie danych źródłowych zamiast okresów czasu i budować, gdy wystąpią. Dzięki temu programiści mogą szybko uzyskać informacje zwrotne na temat usterek.

Answer 3

Od narzędzi dostarczonych z MS Visual Studio możesz chcieć użyć MSBuild. Dodatkowe zestawy narzędzi dla MSBuild Community dają nawet możliwość kasowania kodu z Subversion i wyjścia zip.

Używamy go z powodzeniem w naszej firmie. Projekty składają się z kilku rozwiązań z ponad 100 podprojektami. Działa jak marzenie.

Answer 4

Visual Build Pro jest ładne, jeśli twoje maszyny do budowania są Windows. Myślę, że spełniłoby to wymóg posiadania około QA posiadania systemu. Ale nie zrozum mnie źle, to całkiem potężne.

Answer 5

Po prostu przenieśliśmy z ręcznie zwiniętego zestawu skryptów Perla do konfiguracji Buildbot. Znalazłem to, ponieważ to jest Google's using for Chrome.

Możesz wykonywać nocne czynności lub zintegrować je z kontrolą źródła, aby wykonać wyizolowaną testową wersję, gdy ktoś robi checkin lub wiele innych rzeczy. Jest również równoległy; możesz mieć więcej niż jedną maszynę w budowaniu farmy, albo do zadań specjalistycznych, albo po prostu do obsługi większego ładunku.

Cały system jest napisany w języku Python, więc jest niezależny od platformy, co jest ważne, jeśli trzeba budować na więcej niż jednej platformie. Może zrobić wszystko, co możesz zrobić z linii poleceń; mamy to wywołanie MSBuild dla komponentów trybu użytkownika, DDK build dla fragmentów trybu jądra i uruchomionych produktów dla testów jednostkowych.

Po wyjęciu z pudełka obsługuje most OSS source control tools, ale jeśli używasz TFS lub czegoś innego, możesz potrzebować zmodyfikować pakiet instalowany na maszynach podrzędnych.

Answer 6

Myślę, że jesteś na dobrej drodze.

Ktokolwiek zajmuje się procesem automatycznej kompilacji, musi mieć fundamentalną wiedzę na temat tego, w jaki sposób twoje rozwiązanie pasuje do siebie. Nie musi to oznaczać umiejętności pisania kodu lub rozwiązań architektów, ale będą wymagać solidnego zrozumienia sposobu kompilacji rozwiązania, samych pakietów itp.

Może być konieczne podzielenie odpowiedzialności za kompilacje między osobami lub zespołami w celu osiągnięcia to. Powiedziałbym, że codzienna kompilacja to "odpowiedzialność za zespół".

Zajmę się tworzeniem podstawowej konfiguracji kompilacji, która może być rozszerzona na kompilacje "specjalnego użytku" (poza samą budową wersji wydania), np. umiędzynarodowione komunikaty, FxCop/jakość Narzędzia config, budować + uruchamianie testów jednostkowych, ciągła integracja buduje, nagromadzenie config do pracy na stanowiskach programistycznych, itp

Zamiast tego będę zmierzać do osiągnięcia następujących celów:

Automatyczne wersjonowanie, podpisywanie itp

zdolność do wytwarzania wyjście opisowy (logowanie), aby pomóc debugowania łamie

w tej kwestii - należy prawidłowo obsłużyć błędy, uchwycić jak najwięcej informacji i rejestrować je prawidłowo

, składają NCY - To powinno działać w ten sam sposób za każdym razem, aby produkować powtarzalnych wyników

Run w czystym środowisku ograniczonym dostępie

Dobrze skomentował/udokumentowane tak, że może być zrozumiane przez nowych pracowników, itp

Możliwość generowania informacje o wersji, kompilacja metryk, generowanie raportów (jeśli ta opcja jest dostępna)

Możliwość wdrożenia w wielu środowiskach

Obsługa różnych sposobów uzyskiwania kodu źródłowego ze sterowania źródłowego, np. przez zestaw zmian, etykietę, datę, itp.

Jeśli chodzi o zalecenia dotyczące narzędzi, użyłem FinalBuilder, Visual Build Pro, MSBuild/Team Build, nAnt, CruiseControl i CIFactory plus oraz dobrych staroświeckich plików wsadowych.

Każdy ma swoje zalety i wady, nie zamierzam wydawać zaleceń, poza stwierdzeniem, że produkty z przyzwoitym wsparciem dla UI były nieco łatwiejsze w obsłudze, ale czasami były znacznie mniej wydajne. Jeśli pracujesz z VIsual Studio, MSBuild jest bardzo potężny, ale ma nieco stromą krzywą uczenia się.

Answer 7

Używam FinalBuilder i FinalBuilder Server do nocnych kompilacji. Czasami jest to trochę kłopotliwe, ale jeśli myślisz, że to całkiem proste, możesz tworzyć rozszerzalne projekty, które mogą zbudować typ projektu X, zbuduj bazę danych ze skryptów zmian i wdrożyć ją na serwerze testowym.

Może również obsługiwać wszystkie rodzaje dziwnych i wspaniałych rzeczy, takich jak napinanie nocnej kompilacji i przesyłanie jej na serwer FTP lub automatyczne tworzenie obrazów ISO.

Answer 8

Do tego celu używamy CruiseControl.NET i UppercuT (który używa NAnt). UppercuT używa konwencji do budowania, dzięki czemu naprawdę łatwo jest zacząć od kogoś, odpowiadając na trzy pytania (jakie jest nazywane rozwiązanie? Jaka jest ścieżka do kontroli źródła? Jak nazywa się twoja firma?) I budujesz.

http://code.google.com/p/uppercut/

Kilka dobrych wyjaśnień tutaj: UppercuT

Answer 9

Używamy buildbota Hudson dla dla dużych aplikacji internetowych Java budynku z mrówek skryptów kompilacji. Hudson jest całkiem słodki dla naszych celów. Ma konfigurację master/slave, więc budowanie może być wykonywane jednocześnie (na czasomierzu lub na żądanie). Węzły slave mogą być dowolnymi kombinacjami OS/hardware, pod warunkiem, że posiadają potrzebne narzędzia do budowania już na nim i są w sieci (i nie będą się zawieszać co 10 minut).

Pełny interfejs sieciowy, w tym wyjście konsoli na żywo, dzienniki zmian, artefakty z kompilacji są dostępne w całej sieci, w tym poprzednie wersje (jeśli się powiodą). Niesamowity sos!