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

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ć?

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 .

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.

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.

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ć.

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.

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.

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.

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.

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.

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.

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.

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.

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ć.