Poprawa procesu budowania

Question

Lub, faktycznie, ustanowienie procesu kompilacji, gdy na początku nie ma wiele z nich.

Obecnie jest to sytuacja, z którą ma do czynienia moja grupa. Zajmujemy się przede wszystkim tworzeniem aplikacji internetowych (ale nie rozwijamy obecnie komputerów). Wdrożenia oprogramowania są brzydkie i nieporęczne nawet w przypadku naszych skromnych aplikacji, a w ciągu dwóch lat, kiedy byłem częścią tego zespołu (i firmy), pojawiło się zbyt wiele problemów. Nadszedł czas, aby coś z tym zrobić, a wynik jest taki, że będziemy mogli zabić dwa ptaki testowe Joela jednym kamieniem (codzienne kompilacje i jednoetapowe kompilacje, z których żadna nie istnieje w jakiejkolwiek formie).

To, o co tu chodzi, to ogólny wgląd w to, o czym muszę myśleć, od ludzi, którzy pracowali nad oprogramowaniem dłużej niż ja i mają też większe mózgi. Jestem pewien, że większość osób będzie publikować w wersji beta.

Istotne Narzędzia: wizualne budowanie Source Safe 6.0 (wiem, ale nie mogę nic na temat tego, czy używamy Source Safe w tym czasie zrobić To może być kolejna bitwa walczę.).

Wstępnie, mam projekt Visual Build, który to robi:

1. Pobierz źródło i miejsce w katalogu lokalnym, w tym niezbędne biblioteki DLL potrzebne do projektu.
2. Pobierz pliki konfiguracyjne i zmień nazwę w razie potrzeby (przechowujemy je w specjalnym podkatalogu, który nie jest częścią rzeczywistej aplikacji i są one nazwane odpowiednio do użycia).
3. budowy przy użyciu Visual Studio
4. prekompilację za pomocą wiersza poleceń, kopiując do tego, co będzie „budować” Spisie
5. Kopiuj do miejsca przeznaczenia.
6. Uzyskaj niezbędne zasoby dodatkowe - głównie dokumenty, obrazy i raporty powiązane z projektem (i umieszczone w katalogu od kroku 5). Jest wiele takich rzeczy i nie chciałem ich wcześniej włączać. Jednak będę kopiować tylko zmienione elementy, więc może to nie ma znaczenia. Nie byłem pewien, czy naprawdę chciałem dołączyć te rzeczy we wcześniejszych krokach.

Nadal muszę nakłonić niektóre wylogowanie z Kompilacji wizualnej do tego wszystkiego, ale nie jestem w miejscu, w którym muszę to jeszcze zrobić.

Czy ktoś ma jakieś rady lub sugestie do zrobienia? W tej chwili nie używamy projektu wdrożenia. Usunąłoby to niektóre z niezbędnych kroków w tej kompilacji, jak sądzę (jak zamiana web.config).

Answer 1

Podczas wykonywania projektu, który nigdy nie miał automatycznego procesu kompilacji, łatwiej jest go wykonać etapami. Nie próbuj połknąć za dużo za jednym razem, w przeciwnym razie może wydawać się przytłaczająca.

1. Najpierw skompiluj swój kod za pomocą jednego kroku za pomocą automatycznego programu do kompilacji (np. Nant/msbuild). Nie zamierzam debatować, który z nich jest lepszy. Znajdź taką, która Ci odpowiada i ją wykorzystaj. Miej skrypty budowania na żywo z projektem w kontroli źródła.
2. Dowiedz się, jak uruchomić automatyczną kompilację. Niezależnie od tego, czy łączy się z CruiseControl, czy wykonuje nocne zadanie kompilacji przy użyciu Zaplanowanych zadań. CruiseControl lub TeamCity to prawdopodobnie najlepszy wybór, ponieważ zawierają wiele narzędzi, dzięki którym ten krok jest łatwiejszy. CruiseControl jest bezpłatny, a TeamCity jest bezpłatny do punktu, za który możesz zapłacić za niego, w zależności od tego, jak duży jest projekt.
3. Ok, w tym momencie będziesz całkiem wygodny z narzędziami. Teraz możesz dodać więcej zadań w zależności od tego, co chcesz zrobić w celu testowania, wdrażania i itp.

Mam nadzieję, że to pomoże.

Answer 2

Mam zestaw skryptów Powershell, które robią to wszystko dla mnie.

Skrypt 1: Kompilacja - ten jest prosty, w większości jest obsługiwany przez wywołanie do msbuild, a także tworzy moje skrypty bazy danych.

Skrypt 2: Pakiet - ten bierze różne argumenty, aby spakować wydanie dla różnych środowisk, takich jak test i podzbiory środowiska produkcyjnego, które składa się z wielu maszyn.

Script 3: Deploy - To jest prowadzony na każdym urządzeniu z poziomu folderu utworzonego przez skrypt Package (skrypt Deploy jest kopiowany jako część opakowania)

ze skryptu deploy, robię poczytalność sprawdza takie rzeczy, jak nazwa komputera, aby nie doszło do przypadkowego wdrożenia w niewłaściwym miejscu.

przypadku plików web.config, używam funkcji

<appSettings file="Local.config"> 

mieć przesłonięcia, które są już na maszynach produkcyjnych, a oni są tylko do odczytu, więc nie przypadkowo nadpisać. Pliki Local.config nie są rejestrowane i nie muszę przełączać plików w czasie kompilacji.

[Edytuj] Odpowiednik pliku appSettings = dla sekcji config jest configSource = „Local.config”

Answer 3

Pracuję tylko na kilka projektów Net (robiłem głównie Java), ale jedną rzeczą, którą polecam jest użycie narzędzia takiego jak NAnt. Mam prawdziwy problem ze sprzężeniem mojej kompilacji z IDE, co kończy się tym, że ciężko jest ustawić serwery kompilacyjne w dół, ponieważ musisz wykonać pełną instalację VS na dowolnym polu, z którego chcesz zbudować. przyszłość.

Mimo to każda zautomatyzowana kompilacja jest lepsza niż brak automatycznej kompilacji.

Answer 4

Przestawiliśmy z używania skryptu perla na MSBuild dwa lata temu i nie oglądaliśmy się za siebie. Budowanie wizualnych rozwiązań studyjnych można wykonać, po prostu określając je w głównym pliku xml.

Do niczego bardziej skomplikowanego (Getting swój kod źródłowy, wykonującym testy jednostkowe, budowanie instalacji pakietów, wdrażania stron internetowych) można po prostu stworzyć nową klasę w .NET powstałymi Zadanie który zastępuje funkcję Execute, a następnie odniesienie to z pliku xml kompilacji.

Jest całkiem dobre wprowadzenie tutaj: introduction

Answer 5

Nasz proces kompilacji jest grono wychowanków skryptów Perl, które ewoluowały w ciągu dekady lub tak, nic nadzwyczajnego, ale dostaje zadanie. Jeden skrypt otrzymuje najnowszy kod źródłowy, inny go kompiluje, trzeci tworzy go w lokalizacji sieciowej. Robimy rozwój aplikacji desktopowych, więc nasz proces przemieszczania również buduje pakiety instalacyjne do testowania i ostatecznie wysyłane do klientów.

Proponuję rozbicie go na poszczególne etapy, ponieważ będą chwile, w których chcesz się przebudować, ale nie otrzymasz najnowszych, lub po prostu trzeba ponownie wprowadzić zmiany. Nasze skrypty mogą również obsługiwać budowanie z różnych oddziałów, więc rozważ także to, niezależnie od tego, jakie rozwiązanie opracujesz.

W końcu mamy dedykowaną maszynę do kompilacji, która co noc odbudowuje gałęzie i działy konserwacji i wysyła wiadomości e-mail z problemami lub pomyślnie zakończona.

Answer 6

Nasz system kompilacji to plik Makefile (lub dwa). Robienie tego działa dobrze, ponieważ musi działać w obu oknach (jako zadanie kompilacji pod VS) i pod Linuksem (jako normalne zadanie "make bla"). Naprawdę fajną rzeczą jest to, że kompilacja pobiera faktyczną listę plików z pliku .csproj, buduje (inny) plik Makefile i uruchamia to. W procesach plik make faktycznie nazywa się self.

Jeśli ta myśl nie przeraża czytelnika, wtedy (albo są wariaci), prawdopodobnie mogą sprawić, że zrobi się + "twój ulubiony maniak", żeby dla nich pracować.

Answer 7

Jedna rzecz, którą chciałbym zasugerować, upewnij się, że skrypt budowy (i projekt instalatora, jeśli jest to istotne w twoim przypadku) jest w kontroli źródła. Zwykle mam bardzo prosty skrypt, który po prostu wypisuje \ pobiera najnowszy "główny" skrypt budujący, a następnie uruchamia go.

Mówię to b/c Widzę zespoły, które po prostu uruchamiają najnowszą wersję skryptu kompilacji na serwerze, ale albo nigdy nie umieszczają jej w kontroli kodu źródłowego, albo kiedy to robią, sprawdzają tylko losowo. Jeśli sprawisz, że proces kompilacji będzie "pobierał" z kontroli kodu źródłowego, wymusisz na nim najnowszy i najlepszy skrypt kompilacji.

Answer 8

Używamy UppercuT. UppercuT wykorzystuje NAnt do budowy i jest niezwykle łatwy w użyciu.

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

Kilka dobrych wyjaśnień tutaj: UppercuT