Czy istnieją poważne firmy, które nie używają kontroli wersji i ciągłej integracji? Dlaczego?

17

Mój kolega miał wrażenie, że nasz dział oprogramowania jest bardzo zaawansowany, ponieważ użyliśmy zarówno serwera kompilacji z ciągłą integracją, jak i oprogramowania do kontroli wersji. Nie zgadzało się to z moim punktem widzenia, ponieważ znam tylko jedną firmę, która stworzyła poważne oprogramowanie i której nie posiadałem. Moje doświadczenie ogranicza się jednak tylko do kilku firm.

Czy ktoś wie o prawdziwej firmie (większej niż 3 programistów) , która działa w branży oprogramowania i nie korzysta z tych narzędzi? Jeśli taka firma istnieje, czy istnieje jakiś dobry powód, aby tego nie robić?

daramarak
źródło
3
Ci nieznośni aktorzy oprogramowania.
Lekkość ściga się z Moniką
1
czy aktorzy oprogramowania różnią się od twórców oprogramowania?
Aditya P
„Nie jestem oprogramowaniem, ale gram w telewizji !!” - Aktorzy oprogramowania.
FrustratedWithFormsDesigner
1
Jest Jayne Seymour, jest poważną aktorką programistyczną .... lub przynajmniej grała w Solitare w Live and Let Die :)
Kevin D
3
Tam, gdzie pracowałem dziesięć lat temu, mieliśmy nocne kompilacje na wszystkich obsługiwanych systemach. Nigdy nie zbliżyli się do kompilacji. Zawsze.
David Thornley,

Odpowiedzi:

5

Nie jestem pewien, czy nazwałbyś ich poważnym aktem, ale MySpace są dość ubogie na tym froncie: patrz http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .

Steve
źródło
1
+1 Są przynajmniej w dużej lidze. Nie sądziłem, że to możliwe. Tak duża firma bez kontroli wersji. Domyśl.
daramarak
Zwariowany. Nie uwierzyłbym, ale ten blog i referencje z tego artykułu są wiarygodne.
Steve
Zrzuć winę na psa.
JeffO,
2
Strona internetowa dla nastolatków zakładających zespół w garażu jest napisana w stylu programisty pracującego z garażu. Ryciny
quant_dev
13

Byłbyś zaskoczony, widząc, co rzeczywistość może zrobić ze zdrowym rozsądkiem ;-)

Myślę, że wciąż istnieje wiele firm, które nie używają systemu kontroli wersji. Co ciekawe, we wszystkich przypadkach, które do tej pory widziałem, nie dlatego, że dobrowolnie sprzeciwiają się używaniu takich systemów, ale raczej dlatego, że nie wiedzą, że istnieje coś takiego jak SVN! Co do mnie: całkowicie się z tobą zgadzam i nie wyobrażam sobie sytuacji, w której nie chcę używać żadnej kontroli wersji. Do diabła, wrzucam nawet moje osobiste pliki (dokumenty słowne itp.) Z mojego domowego komputera do repozytorium GIT.

W przypadku systemu ciągłej integracji nieco częściej nie stosuje się ich w codziennych operacjach. Czasami również dlatego, że ludzie nie wiedzą, że taki system istnieje, ale widziałem również przypadki, w których - bardzo wątpliwe - usprawiedliwieniem nieużywania go jest to, że „nie jesteśmy wystarczająco skomplikowani” lub „działa bardzo dobrze bez ciągłej integracji, więc po co zawracać sobie głowę dodawaniem kolejnej technologii? ” Oczywiście nie jest to realistyczna ocena - ale odpowiedź na pierwotne pytanie: nie jest to wcale takie rzadkie.

perdian
źródło
11
Czy to możliwe, że przeciętny twórca oprogramowania nie słyszał o oprogramowaniu do kontroli wersji? Skąd te firmy zatrudniają ludzi? Ciemna strona księżyca?
daramarak
7
@daramarak: Wielu (jeśli nie większość) programistów nie czyta książek, nie przegląda blogów programistycznych i w ogóle nie komunikuje się z innymi programistami (spoza swojej firmy). Jeśli zaczniesz rozwijać się, ucząc się jednej z tych książek „ucz się języka Visual Basic w 21 dni”, prawdopodobnie nie usłyszysz o kontroli wersji. W rzeczywistości nie przypominam sobie nauki o kontroli wersji na uniwersytecie, zaledwie 10 lat temu.
Joeri Sebrechts,
@joeri - na szczęście nieprawda, gdzie pracuję, ale ogólnie mogę w to uwierzyć.
Steve,
@perdian - mówisz „sporo firm”, ale nie podajesz żadnych szczegółów… czy masz jakieś linki do artykułów, blogów itp. nazywanie i zawstydzanie? Nie twierdzę, że ci nie wierzę (tak naprawdę wierzę ci), ale dane są zawsze dobre ...
Steve
@ Steve Haigh - Nie, nie mam żadnych „twardych” dowodów. Widziałem kilka firm, które nie używają kontroli wersji CI (których nazwy zachowam dla siebie g ) i przy odrobinie ekstrapolacji zakładam, że jest ich znacznie więcej. Myślę, że o wiele łatwiej jest znaleźć firmy, które używają CI, po prostu patrząc na przykład na listę referencyjną na stronie Jenkins. Ale na odwrót? Niewiele osób reklamuje „Hej, nie używamy technologii X” ;-)
perdian
12

Prawie każda firma w mojej branży (bankowość) korzysta obecnie z kontroli wersji. Ale z pewnością możliwe jest udane opracowanie oprogramowania bez kontroli wersji. 20-30 lat temu. zrobiliśmy dokładnie to.

Powiedziałbym, że wiele banków, a może nawet większość, nie korzysta z serwera kompilacji z ciągłą integracją. Jeśli już dostarczasz oprogramowanie bez ciągłej integracji, dalsza droga jest całkowicie racjonalna.

RoadWarrior
źródło
3
Nie zgadzam się z tym, że „kontynuacja tej drogi” jest całkowicie racjonalna. Tak, dostarczenie oprogramowania w ciągu ostatnich X lat nie oznacza, że ​​nie będzie działać przez następne Y lat bez żadnych zmian. Jednak po wprowadzeniu CI do istniejących (i dość dojrzałych) programów, zawsze można na tym zyskać.
Perdian
1
@perdian: zawsze można coś zyskać na wielu inicjatywach. Musisz więc zrównoważyć CI ze wszystkim innym. Nie można po prostu twierdzić, że CI daje więcej korzyści niż wszystko inne. Musisz także zmierzyć koszty alternatywne.
RoadWarrior
1
@ SK-logic: RCS był wówczas całkowicie nieznany w brytyjskim sektorze bankowym. Opracowaliśmy też bardzo duże i solidne systemy bez kontroli źródła.
RoadWarrior
1
-1: „Prawie każda firma” to zbyt szerokie stwierdzenie, które jest błędne. W ubiegłym roku widziałem niektóre firmy, które nie używają żadnego narzędzia kontroli wersji, polegając na kopiach wersji we wspólnym katalogu. Tak, to sprawiło, że płakałem. Powiedzieli, że „svn jest zbyt trudny w użyciu”. O MÓJ BOŻE. Ale wciąż znajduję takie firmy. Nie uogólniaj, nie każdy w branży wie, czym jest system kontroli źródła, nie uczy się niczego online, ani nie wie, czym jest ciągła integracja. (Zgadzam się, że to piekło. Cieszę się, że już mnie tam nie ma).
Klaim
1
@ SK-logic - ... co stwierdził RoadWarrior, z wyjątkiem branży morskiej / energetycznej tutaj. Nie podam nazwisk, ale znam przynajmniej dwie firmy dominujące w ich sektorze (niektóre wyspecjalizowane programy), dla których, jak sądzę, nigdy nie korzystałem z VCS żadnego rodzaju (w twoim znaczeniu). Mieli sposoby na odróżnienie dobrego kodu od kodu w toku.
Gawron
7

Wystarczy wskazać kontrapunkt na odpowiedź @ RoadWarrior:

Pracuję dla banku. Ostatnie 3 lata spędziłem na wdrażaniu kontroli wersji i teraz udało mi się uzyskać około 20% naszej bazy kodu (która jest dość duża, mamy około 20 programistów i rozwijamy nasze systemy przez> 16 lat)

Dzięki moim kontaktom w branży (bankowość) znam mnóstwo innych instytucji finansowych, które nie mają tego, co rozsądna osoba nazwałaby kontrolą wersji.

Tak, nasza branża (tworzenie oprogramowania) jest o wiele bardziej smutna, niż większość chciałaby się przyznać.

Dan McGrath
źródło
Moje kondolencje. Wygląda na to, że przynajmniej w niektórych branżach brakuje narzędzi. Wydaje mi się, że to znowu historia dzieci szewców. Czy mogę zapytać, jak szalona osoba nazwałaby kontrolę wersji?
daramarak
6
Ręczne pobranie kopii kodu przed jego edycją. Np. MyProg -> MyProd.old4
Dan McGrath
Niestety, ta praktyka jest bardziej powszechna, niż ludzie myślą
Craig T
3

kontrola wersji: W mojej pierwszej pracy 25 lat temu nie było takiego systemu kontroli wersji, ale był to RSX11 na PDP-11. Był jednak bardzo wysoki poziom kontroli jakości z formalnymi przeglądami projektu i kodu (dotyczyło to przemysłu nuklearnego).

Od tego czasu w każdym zadaniu stosowano systemy kontroli wersji, w tym SCCS, PVCS, clearcase, cvs i perforce.

Z mojego doświadczenia wynika, że ​​kontrola wersji jest dość powszechna w poważnym tworzeniu oprogramowania.

ciągła integracja: jest to większy problem, szczególnie w miejscach, w których jest dużo starszego kodu, który prawdopodobnie nawet nie ma zbyt wiele w zakresie zautomatyzowanego testowania. Przeniesienie istniejącego kodu do środowiska CI wymaga bardzo dużej inwestycji i chociaż prawdopodobnie ostatecznie się to opłaca, trudno jest zmusić kierownictwo do zaangażowania się w taką inwestycję bez krótkoterminowego zysku.

Pracowałem w jednym miejscu (duży bank), w którym niektóre projekty były wyposażone w CI, i wdrożyliśmy w naszym projekcie rodzaj systemu CI, co znacznie ułatwiło sprawę, ale zajęło mi to około 6 miesięcy.

Chris Card
źródło
Czy w przypadku miejsc ze starszym kodem wykonywali automatyczne kompilacje, czy też mieli ręczny plan budowy / wdrożenia?
daramarak
3

Wyobrażam sobie, że MOST firmy nie używają tych rzeczy, ponieważ nie rozumieją korzyści, a ich programiści albo nie chcą się uczyć, albo boją się „pobudzić pulę”, robiąc rzeczy odmienne od tego, jak byli wykonane przed.

Wayne Molina
źródło
3
Absolutnie! Słyszałem odpowiedź (a może powinniśmy nazwać to kiepską wymówką) „do tej pory jej nie wykorzystaliśmy, a ponieważ zadziałała (jakoś), nie potrzebujemy jej”. Szkoda, jak odporni są ludzie na zmianę narzędzi.
Perdian
1
Nie mogę znieść takich ludzi; niestety jest to rodzaj „programisty”, z którym zbyt często się spotkałem w mojej karierze, i po prostu nie mogę sobie poradzić z ich ignorancją i zawsze staram się opuścić firmę, w której dominują tego typu programiści. Ryzykując, że zabrzmi to wręcz wrogo, tego rodzaju ludzie są rakiem tego zawodu.
Wayne Molina
2

Mimo że jestem teraz pracownikiem, byłem konsultantem do spraw baz danych. Przez te wiele lat byłem w około 800–1000 firmach, od matek i popów po Fortune 100.

Widziałem stosunkowo niewiele miejsc, w których trwała ciągła integracja, ale nie przypominam sobie, aby kiedykolwiek widziałem firmę, która nie używałaby kontroli wersji. Widziałem kilka, w których nie było scentralizowanego repozytorium kodu sterowanego wersją. Poszczególni programiści używali kontroli wersji na swoich komputerach lub trzymali kod kontroli wersji gdzieś poniżej swojego katalogu domowego na serwerze.

Nie wydaje mi się, aby którakolwiek z tych firm zajmowała się oprogramowaniem, ale z pewnością byli to programiści.

Mike Sherrill „Cat Recall”
źródło
1

Mój kolega miał wrażenie, że nasz dział oprogramowania był bardzo zaawansowany, ponieważ użyliśmy zarówno serwera kompilacji z ciągłą integracją, jak i oprogramowania do kontroli wersji.

Nie, nie chcę tego mówić, ale to prawda. Ostatnie dwa miejsca, w których pracowałem (oddział banku i firma finansowa), to ja wdrożyłem system kontroli wersji. Wiele miejsc (zwłaszcza sklepy inne niż oprogramowanie) nie rozumie, dlaczego jest to naprawdę konieczne do długoterminowego rozwoju. Zespół zwykle zaczyna się jako jedna lub dwie osoby, a następnie rośnie, choć boleśnie. Z jedną lub dwiema osobami możesz sobie bez tego poradzić (nie dobrze), ponieważ możesz być w niemal stałej komunikacji ze sobą.

Ciągłe budowanie to zupełnie inny przypadek. Gdybym miał zgadywać, postawiłbym na to, że prawie 90% miejsc, w których opracowywany jest program, nie ma rozwiązania CI. Chodzę na konferencje i większość ludzi dziwi się, że ma ją organizacja inna niż MS lub Google. Odkryłem, że kierownictwo nie chce wydawać niewielkiej sumy pieniędzy na uruchomienie, nawet jeśli może to zaoszczędzić dużo czasu.

Najważniejsze powody, dla których znalazłem to:

  1. Ludzie zarządzający awansowali w szeregach tej samej organizacji. Nigdy ich nie używali i nie potrzebowali, dlaczego mieliby się teraz zmieniać? Niektóre, które znalazłem, boją się zmian. Coś nowego jest przerażające i zapobiegnie odkurzaniu starego kompilatora i pomoże naszym młodszym w potrzebie. Innym razem (i częściej) mają budżety, które są zawsze napięte i muszą podejmować decyzje, gdzie wydawać pieniądze. Dla nas wdrożenie ich jest oczywistą potrzebą, ale to dlatego, że korzystaliśmy z nich wcześniej. Znamy korzyści, a oni nie.

  2. Menedżerowie to osoby niezwiązane z IT, a jedyne, co tu robią, to to, że chcesz wydawać pieniądze na coś, co nie było wcześniej potrzebne.

Większość argumentów, które słyszałem od ludzi, koncentruje się na najlepszych praktykach itp. I są one prawdziwe, ale większość deweloperów nie rozumie tego, że w tym scenariuszu musisz sformułować je pod kątem sytuacji finansowej. Dzięki tej ilości pieniędzy, którą zamierzasz wydać, zaoszczędzimy X czasu i potrzebujesz liczb, aby to zrobić. Nie zawsze jest to prawdą, ale takie było moje doświadczenie w przeszłości.

kemiller2002
źródło
Mogę sobie wyobrazić, że takie problemy powstają, gdy słaba komunikacja od dewelopera i kierownictwa w górę. Na szczęście nie wszystkie firmy są takie. Tam, gdzie pracuję, oczekuje się od nas (jeśli nie jesteśmy zobowiązani) poinformowania kierownictwa, czy coś może nas poprawić.
daramarak
1

Powiedziałbym, że wiele osób nie korzysta z kontroli źródła, ponieważ mogą samodzielnie kodować i są przyzwyczajeni do okresowego tworzenia kopii zapasowych bazy kodów na centralnym serwerze lub dysku twardym USB. Około rok temu zmusiłem się do używania SVN, ponieważ wiedziałem, że na dłuższą metę będzie to korzystne. Przyzwyczaiłem się do tego, ale teraz mam mnóstwo historii kodu, do której ciągle mogę się odwoływać. Żałuję, że nie wdrożyłem go cztery lata temu, kiedy zaczynałem.

Ciągła integracja? Używaj go tylko wtedy, gdy go potrzebujesz. Dla mnie jest tylko dwóch inżynierów oprogramowania, więc nie skorzystalibyśmy z ciągłej integracji, ponieważ sami pracujemy nad własnym oprogramowaniem.

Brian
źródło
1
Ciągła integracja ma na celu identyfikację błędów, gdy wystąpią. Potrzebują tego nawet dwaj programiści.
daramarak
1
@daramarak: Nie, jeśli dwóch inżynierów pracuje niezależnie nad dwoma oddzielnymi produktami, które nie są zintegrowane.
Brian,
1
CI jest jedną z tych rzeczy, bez których jestem gotów się obejść. Osobiście chciałbym mieć go w swojej pracy, ale nie stanie się to w najbliższym czasie. Mamy jednak automatyczne kompilacje 1-2 razy dziennie i to naprawdę wystarcza na nasze potrzeby.
Michael K,
1
Dzięki automatycznej kompilacji jesteś w połowie drogi. Wystarczy wiedzieć, że wszystko sprawdzane w kompilacji może być czasem radości ( „on kompiluje na moim komputerze”)
daramarak
1

Ha, myślisz, że jesteś zaawansowany, ponieważ masz SCM i system CI? Pozwól, że powiem ci, że to amatorska godzina, jeśli chodzi o to.

Wiele firm robi minimum, ponieważ to wszystko, czego naprawdę potrzebuje . Jeśli to działa, a otrzymasz dobre powtarzalne wydania bez większego wysiłku, to nie ma nic, co trzeba naprawić. Ostatnią rzeczą, którą chcesz zrobić w takich okolicznościach, to zacząć „naprawiać” rzeczy, szczególnie jeśli chodzi o odebranie zasobów administracyjnych od ich pracy, aby skonfigurować i administrować nowymi serwerami i kompilować systemy.

Jednak niektóre firmy wymagają nieco bardziej rygorystycznych systemów, które kiedyś nie tylko wykonują kompilację, ale kontrolują wymagania aż do wdrożenia poprzez plany testów i wyniki testów, biorąc pod uwagę przegląd kodu, procedury sprawdzania przepływu pracy i wyznaczone przez lidera zespołu zarządzanie pakietami prac. To prawdziwe zarządzanie konfiguracją i cholernie się cieszę, że nie musicie pracować w takim środowisku!

Pracowałem w kilku firmach i nie mogę wymyślić żadnej, która nie miałaby żadnej formy SCM. Niektóre z nich były bardziej wszechstronne niż inne, ale wszystkie miały system, który działał dla nich dobrze, nawet te, które korzystały z VSS.

gbjbaanb
źródło
lol ! podpisane: profesjonalista.
deadalnix
Zgadzam się, SCM i narzędzie do śledzenia błędów to odpowiednik rozwoju noszenia spodni do pracy. CI jest podstawową automatyzacją funkcji krytycznej. Podobnie jak automatyczne kopie zapasowe, ale dla wydań. Ach, spotkania CCB. Co tydzień jak w zegarku.
Tim Williscroft
1

Nawet z dwoma programistami, którzy pracują nad złożonymi aplikacjami i listą zadań, może nie być trudno nawzajem sobie wyobrazić zmiany.

Nawet nasze stare oprogramowanie do zarządzania wersjami pokazywało zmiany obok siebie i pozwalało na ich stosowanie w obu kierunkach. Bez tego zmiany nie zostałyby pominięte więcej niż jeden raz.

Widzę wiele korzyści płynących z CI, ale nie wyobrażam sobie, dlaczego żadna firma nie używałaby oprogramowania do kontroli wersji.

DHorse
źródło
1

Ostatnią pracą, nad którą pracowałem bez kontroli wersji, było w 2006 roku (jestem programistą, FWIW). Firma zatrudniała około 2 lub 3 programistów przed zatrudnieniem mnie, ale byłem pierwszym z 10 programistów zatrudnionych w ciągu zaledwie kilku miesięcy. Jedną z pierwszych rzeczy, które zrobiłem, kiedy zostałem zatrudniony, było wprowadzenie kontroli wersji (CVS, ponieważ nie wiedziałem wtedy, jak bardzo to jest do bani!), Ale wielu programistów zatrudnionych po mnie nie mogło zmusić go do pracy nad swoim deweloperem środowiska, więc go nie użyłem. Och, czy wspomniałem, że nie mają nawet lokalnych instancji uruchomionej aplikacji? Zhakowali kod na serwerze. I oczywiście żadnych automatycznych testów. Kulę się, gdy wracam myślami.

Wcześniej zajmowałem się programowaniem w systemie AS / 400 bez kontroli wersji. Nie wiem, czy przyzwoity VCS był w ogóle dostępny dla tego środowiska.

Teraz używam Gita do wszystkich moich jednoosobowych projektów, a także z moich ostatnich kilku zadań.

CI to inna sprawa. Wspaniale jest mieć i zachęcam, ale jest to mniej istotne niż kontrola wersji, przynajmniej w przypadku mniejszych projektów w językach interpretowanych. Jednak większość moich ostatnich prac miała serwery CI; oznacza to między innymi, że nikt nie może zapomnieć o uruchomieniu pełnego pakietu testowego przed wdrożeniem.

Marnen Laibow-Koser
źródło
„CI to inna sprawa. Wspaniale jest mieć i zachęcam, ale jest to mniej istotne niż kontrola wersji, przynajmniej w przypadku mniejszych projektów w językach interpretowanych ”. Zgoda. CI jest naprawdę konieczne tylko wtedy, gdy wykonujesz częste i / lub złożone kompilacje i zaczyna to zajmować dużo czasu, chcesz uruchomić zestaw testowy lub chcesz móc wystawiać wiele gałęzi itp. Jeśli to jest projekt PHP z tuzinem programistów, bez pakietu testowego, a raz w tygodniu przechodzisz na produkcję, prawdopodobnie zanim zaczniesz martwić się o CI, prawdopodobnie będziesz chciał skoncentrować się na dobrym przepływie pracy QA.
siliconrockstar,
Prawdopodobnie będziesz chciał skoncentrować się na dobrym zestawie testów, zanim zaczniesz martwić się o kontrolę jakości lub cokolwiek innego.
Marnen Laibow-Koser
Być może teoretycznie, ale jeśli używasz oprogramowania typu open source, chyba że jest ono dostarczane z pakietem testowym, jest to praktycznie niemożliwe. Raz nie pracowałem nad projektem PHP, który miał odpowiedni, pełny zakres testów, ale każdy projekt, nad którym pracowałem, miał pewien poziom jakości.
siliconrockstar
@siliconrockstar Mówiłem o posiadaniu dobrego zestawu testów dla własnego kodu; odpowiedni poziom testowania kodu biblioteki to zupełnie inna sprawa.
Marnen Laibow-Koser
@siliconrockstar Jeśli chodzi o wartość, większość projektów Rails, nad którymi pracowałem, była doskonale testowana przez programistów (wyjątki aktywnie próbowały ją ulepszyć); nie wszyscy mieli formalną kontrolę jakości. O wiele mniej konieczne jest posiadanie formalnej kontroli jakości z dobrymi testami, choć nadal jest to bardzo dobry pomysł. Jednak rozwój bez testów jest niezwykle ryzykowny, dlatego mówię, że ulepszanie testów powinno mieć pierwszeństwo przed czymkolwiek innym.
Marnen Laibow-Koser
0

Zdecydowanie wpadłem na kilka tu i tam, ale głównie małe firmy. Problem, który widzę częściej, to firmy, które faktycznie mają SCM, ale uważają wiele projektów za małe lub nieistotne, aby je śledzić.

JohnFx
źródło