Jeśli wykonujesz projekt solo - czy użyłbyś narzędzi CI do budowania z repozytorium? Korzystałem z Hudsona i tempomatu w środowisku zespołowym, w którym budowanie jest niezbędne, gdy tylko ktoś coś sprawdzi.
Myślę, że wartość kontroli wersji jest nadal oczywista, ale czy muszę budować po każdym zatwierdzeniu, widząc, że właśnie zbudowałbym na mojej lokalnej maszynie i nikt inny się nie zobowiązuje?
Odpowiedzi:
Cóż, planuję użyć narzędzia ciągłej integracji w projekcie i jestem unikalnym programistą. Potrzeba przychodzi, ponieważ
Poza przygotowaniem do pracy na różnych platformach i w zespole nie widzę takiej potrzeby. Najważniejsze jest mieć oprogramowanie do kontroli źródła i mieć kilka repozytoriów do przechowywania kopii zapasowych. Pomoże Ci to skonfigurować narzędzia do budowania wokół niego, gdy zajdzie taka potrzeba.
Jeśli chodzi o czas kompilacji, używam Mercurial i konfiguruję repozytorium integracji, które nie jest repozytorium pracy zespołowej. Pchaj zmiany w repozytorium pracy zespołowej, aż poczuję, że nadszedł czas, aby system integracji spróbował zbudować. Następnie przechodzę z repozytorium pracy zespołowej do repozytorium integracji, co uruchomi kompilację. Następnie dodam również skrypt, który będzie pobierał repozytorium pracy zespołowej w repozytorium integracji raz dziennie.
Zakładam, że pracuję prawie cały dzień nad moim projektem, ale nie zawsze jest to prawdą. Musisz ustawić czas kompilacji zależny od tego, jak często potrzebujesz kompilacji. W firmie produkującej gry, w której wcześniej pracowałem, korzystaliśmy z CruiseControle, która co godzinę budowała pełną wersję. W razie potrzeby moglibyśmy również wymusić kompilację.
W przypadku projektu domowego jeden raz dziennie może być już „często”. Głównym wymaganiem byłoby umożliwienie użytkownikowi wymuszenia uruchomienia kompilacji.
Po krótkiej kontemplacji Sugerowałbym, że może to być nawet bardziej istotne dla deweloper solowy niż dla drużyny.
Na najbardziej podstawowym poziomie serwer CI pokazuje, że możesz zbudować aplikację od podstaw z zatwierdzonego źródła - w połączeniu z przyzwoitym zestawem testów powinien wykazać, że możesz budować i uruchamiać od zera.
Ponieważ jedną z rzeczy, które staram się zrobić, jest upewnienie się, że moja kompilacja zawiera pakiet do wdrożenia, wiesz również, że możesz dostać coś do wdrożenia (czyste i ze znanego stanu / wersji).
W rzeczywistości teraz, kiedy robisz File | New Project, powinieneś prawdopodobnie utworzyć lub dodać do swojego repozytorium oraz skonfigurować skrypt kompilacji CI i konfigurację wdrażania (nawet jeśli jest to tylko spakowanie stosu rzeczy do wdrożenia xcopy)
Dodatek (2016) - obecnie mój system CI będzie również integralną częścią mojego procesu wdrażania, więc jego wartość wzrosła i absolutnie nie uruchomię bez niego żadnego dostarczalnego projektu. Zautomatyzowane wdrażanie za pomocą przycisku eliminuje stres związany z procesem i w pewien sposób kształtuje lub tworzy serwer kompilacji.
Kiedy jestem jedynym, który się zobowiązuje, po prostu buduję i testuję, zanim faktycznie popełniam. Zwykle używam celu makefile, takiego jak:
make sense
To konfiguruje, buduje, uruchamia wszystkie testy (świadomy valgrind), uruchamia włókna itp. Ponieważ wiem, że będę jedynym, który pcha, tak naprawdę nie potrzebuję mocy czegoś takiego jak Hudson.
Dodatkowo, w środowisku, w którym kilka oddziałów zasila główne repozytorium, jeśli wszyscy wykonają polecenie pull zawsze przed zatwierdzeniem lub wypchnięciem, serwer CI może być trochę przesadzony. Dobrze napisana zasada, że autor cokolwiek zepsuł ostatnią kompilację, kupuje pizzę w piątek, zwykle zapewnia sprawne działanie :)
Jeśli dojdzie do sytuacji, w której projekt jest wyraźnie podzielony na podsystemy, które mają swoich liderów, naprawdę musisz rozważyć użycie czegoś takiego jak Hudson. Ktoś może przetestować lokalnie, przegrać wyścig z innym podsystemem i ostatecznie popchnąć coś toksycznego.
Ponadto, jeśli utrzymujesz widelec szybko zmieniającego się projektu (na przykład własny zestaw łatek do jądra Linuksa), powinieneś naprawdę rozważyć użycie czegoś takiego jak Hudson, nawet jeśli jesteś „solo” w tym projekcie. Jest to szczególnie prawdziwe, jeśli rozgałęziasz / przestawiasz bezpośrednio z głównej linii.
make: don't know how to make sense. Stop. Argh!
Nie powiedziałbym, że to po prostu fajny bonus, powiedziałbym, że jest niezbędny dla wysokiej jakości inżynierii oprogramowania dla naszych solowych artystów. Większość z nas pozwoli nieco obniżyć swoje standardy jakości, jeśli spieszy im się, jeśli uznają, że łatwo to później naprawić. Jeśli popełnisz oprogramowanie w tym stanie, zasadniczo masz bezwartościową bazę kodu zapisaną w twojej kontroli źródła.
Jeśli przestrzegasz poprawnie (to znaczy, nie pomijasz testów i upewniasz się, że kompiluje się przy każdym zatwierdzeniu) CI zmusza cię do przestrzegania wyższego standardu jakości niż w przypadku, gdybyś po prostu i tak go zatwierdził.
Ważne jest, jeśli chcesz skrócić czas oczekiwania, aby sprawdzić, czy wszystko idzie dobrze. Chociaż możesz sprawić, by IDE skompilowało dla ciebie rzeczy, gdy tylko zapiszesz, nie uruchamia to automatycznie testów jednostkowych, więc mam serwer CI, aby uruchomił testy jednostkowe i raporty pokrycia przypadków testowych oraz inną analizę jakości mojego kodu, jak tylko to możliwe. Pcham to.
Jedyne, co muszę zrobić, to przesunąć moje bieżące zmiany do kontroli wersji i mogę wrócić do kodowania. I podczas gdy myślę o kodowaniu, system CI jest zajęty robieniem długich, skomplikowanych raportów dotyczących jakości, które będę oglądał od czasu do czasu, gdy mój mózg się uspokoi.
Mam osobną maszynę VMWare na tym samym laptopie, która wykonuje kompilacje kodu, który wypycham. Aby to zrobić, po prostu otrzymuję obraz VMWare pod klucz Linux i instaluję jenkins za pomocą apt-get i dokonuję kilku drobnych zmian w konfiguracji.