Czy powinniśmy udostępniać kod online?

Szukamy dobrego rozwiązania kontroli źródła i zarządzania projektami w moim miejscu pracy i zasugerowałem utworzenie organizacji GitHub i prywatnych repozytoriów. Uwielbiam GitHub z wielu powodów, ale nie chodzi o GitHub (w rzeczywistości moi koledzy przedstawią punkty na rzecz konkurencyjnych platform) - chodzi o przechowywanie naszego prywatnego kodu online .

Próbuję zrozumieć, czy to dobry pomysł, czy nie. Zdecydowanie wydaje się to korzystne, ponieważ eliminuje konieczność ponoszenia kosztów serwera (przynajmniej bezpośrednio), a także ułatwia wyszukiwanie kodu (wszystko jest w trybie online).

Jednak nasz zespół jest niezdecydowany i prowadzi mnie do pytania, co powinniśmy rozważyć, aby podjąć tę decyzję?

Jako profesjonalista

Jeśli biuro Twojej firmy spłonie, kod nadal znajduje się na serwerze.

Jeśli biuro twojej firmy nie spala się, ale serwer, na którym znajduje się twoje repozytorium git, DZIAŁA, nadal masz lokalną kopię.

Jeśli hostujesz swoje repozytorium na serwerze w budynku biurowym firmy (tak jak w przypadku udostępnionego dysku sieciowego ...?), To jeśli biuro firmy spali się, tracisz jedno i drugie.

Oczywiście nadal potrzebujesz kopii zapasowych jak zwykle ...

Nie krępuj się zamienić słowa „burns down” na „zostanie zainfekowany ransomware”.

Zasadniczo dostępność jest większa.

Jako oszustwo

Musisz udostępnić swoje pliki stronie trzeciej, która będzie hostować Twój kod. Jeśli masz naprawdę duże tajemnice firmowe, może to być niedozwolone. Na przykład, jeśli masz bazę danych zawierającą dane osobowe od obywateli europejskich, możesz nie mieć pozwolenia na hostowanie twojego kodu na stronie trzeciej z USA - ponieważ będą one podlegać prawu amerykańskiemu, a zatem nie można na nich polegać przestrzegają przepisów UE dotyczących prywatności. Nawet jeśli nie jest to kwestia prawna, należy pamiętać, że osoba trzecia może zostać przekupiona za oddanie twoich prywatnych plików. Prawdopodobnie byłoby to bardzo złe dla strony trzeciej (ogromna kara za reputację), ale może się zdarzyć.

Zasadniczo poufność jest obniżona.

Jeśli nie zgadzasz się na poufność informacji dotyczących dostępności, dobrym pomysłem jest hosting prywatnego kodu online z osobą trzecią. W przeciwnym razie nie. Możesz wyjaśnić kompromisy, aby umożliwić szefowi podjęcie inteligentnej decyzji - ale możesz usłyszeć „nie”. To może się zdarzyć, jeśli dasz komuś decyzję. Jeśli twój szef mówi nie, to tyle. Nie sądzę, aby przekonywanie twojego szefa było bardzo dobrym pomysłem.

Oczywiście jest to kwestia zaufania do dostawcy i tego, jak bardzo cenisz swój kod źródłowy.

Myślę jednak, że jest jasne, że przynajmniej w przeszłości ludzie zbyt cenili swój kod źródłowy.

• W przypadku produktów „automatyzacji procesów biznesowych”; gdzie wewnętrzny zespół tworzy strony internetowe i inne oprogramowanie specjalnie na potrzeby firmy. Wartość tego oprogramowania dla innych osób jest na ogół bardzo niska.

• W przypadku oprogramowania do sprzedaży; to sprzedawany plik binarny, który można skopiować i zhakować bez dostępu do kodu źródłowego.

Po drugie: powinieneś również rozważyć, czy przechowywanie twojego kodu z podmiotem zewnętrznym faktycznie zwiększa ekspozycję powyżej jego obecnego poziomu. W wielu przypadkach tak nie będzie

• Na przykład; jeśli twój produkt jest witryną bez kodu zaplecza, Twój kod jest już publiczny.
• Jeśli skompilowany kod jest rozpowszechniany, można go dekompilować.
• Jeśli Twój kod jest witryną lub usługą i hostujesz go u strony trzeciej. Następnie strona trzecia może dekompilować kod.
• Jeśli przechowujesz swoje kopie zapasowe w firmie zewnętrznej, mają one dostęp do Twojego kodu.

Krótko mówiąc, większość nowoczesnych firm będzie ufać różnym stronom trzecim w ich codziennej działalności; nawet rzeczy, które są dla nich niezbędne i wyjątkowe.

Częścią tego procesu decyzyjnego może być trochę testowania, prób i błędów. Weź mały projekt i poproś kilku członków o wypróbowanie różnych stron. Powinno to obejmować użyteczność zespołu, ale istnieją inne względy.

1. Obecna infrastruktura - niektóre firmy mają już serwery, połączenia internetowe, VPN i personel obsługujący serwery, dzięki czemu niektóre koszty i obawy mogą być łatwiej przyswojone. Start-up może być bardziej skłonny do korzystania z czegoś takiego jak Github, ponieważ nie muszą dokonywać tego typu inwestycji i mogą zacząć działać wcześniej.
2. Budżet - tutaj znajdzie się wiele aspektów nr 1, ale mogą istnieć inne rozwiązania z wysoką ceną. Niektóre firmy mogą uzasadnić koszty. Oczywiście przy niskim budżecie wiele opcji jest wyeliminowanych.
3. Dystrybucja drużynowa - Gdy wszyscy pracują poza tym samym biurem w tych samych godzinach, możesz nie potrzebować github. Jeśli twój serwer plików nie jest zbyt obciążony, po prostu włóż na niego Git.
4. Bezpieczeństwo - prawdopodobnie możesz znaleźć wiele bezpiecznych witryn, ale postrzeganie bezpieczeństwa dla niektórych klientów jest ważniejsze. Posiadanie własnej sieci Ironclad może być właściwą rzeczą, aby zdobyć ich zaufanie. Odznaki bezpieczeństwa, skanery siatkówki i uzbrojeni strażnicy po prostu krzyczą o bezpieczeństwie niektórych klientów.
5. Szkolenie - jest coś więcej niż tylko korzystanie z aplikacji, istnieją zasady i procedury, które firma / zespół chce wprowadzić. Pomysł na to, jak chcesz to zrobić, może wpłynąć na to, jakich narzędzi użyć. Przyciąganie dodatkowych członków zespołu staje się trochę łatwiejsze, jeśli podoba im się sposób, w jaki robisz różne rzeczy.

Rozpocznij pracę od całego procesu kodowania i dostarczania. Im więcej osób zaangażowanych w ten proces, tym lepiej. Nie chcesz przyjmować platformy kontroli źródła opartej na określonych kryteriach, aby ktoś w zarządzie zmienił wszystko. „Ta rozproszona zwinna rzecz nie działa, więc wszyscy musimy zacząć pracę w biurze od 8 do 7 od poniedziałku, dobrze”.

Niekoniecznie mówię, że nie powinieneś przechowywać repozytorium swojej firmy w chmurze, ale osobiście doświadczyłem pewnych wad i problemów z hostingiem w chmurze.

Jak szybkie i niezawodne jest twoje połączenie internetowe?

Dla mnie to najważniejsza kwestia. Na przykład moja firma znajduje się na ładnym obszarze wiejskim. Podczas gdy nasze prędkości wewnątrz sieci błyskawicznie płoną, nasze prędkości między sieciami są co najwyżej wolne, w najgorszym przypadku wręcz płatkowe.

W zależności od używanego VCS, część bólu można złagodzić. Rozproszone systemy kontroli wersji, takie jak Git, nie są takie złe, ponieważ nadal możesz pracować lokalnie. Możesz nawet zainicjować nowe repozytorium na dysku sieciowym, jeśli naprawdę chcesz udostępnić jakiś kod współpracownikowi. Dla porównania, tak naprawdę nie możesz zrobić żadnej z tych rzeczy w Team Foundation (pomimo całej lokalnej przestrzeni roboczej).

Ale to tylko kod. Repozytorium hostowane w chmurze zawiera o wiele więcej niż tylko kod. Co z twoimi elementami pracy (funkcje / lista błędów)? Co z twoją dokumentacją (wiki)? Co z kompilacją ciągłej integracji? Wszystkie te rzeczy prawdopodobnie będą również przechowywane w chmurze obok twojego kodu. Jeśli Twoje połączenie internetowe przestanie działać, jak będziesz działać bez tych rzeczy?

Gitlab zapewnia bezpłatną wersję lokalną, która prawdopodobnie zapewni więcej niż potrzebuje Twój zespół. Bardzo polecam instalację na miejscu. Znacznie zmniejszy to ryzyko.

Co powinniśmy wziąć pod uwagę, aby podjąć tę decyzję?

Powinieneś rozważyć wady. Ja (wraz z innymi) skutecznie zachęciłem mojego obecnego pracodawcę do zaprzestania hostingu klejnotów korony własności intelektualnej firmy na prywatnym repozytorium github. Nie zrozum mnie źle; github jest fantastyczny dla oprogramowania typu open source.

Czy w przypadku zamkniętego oprogramowania źródłowego github.com (lub inna alternatywa) podpisała umowę o nieujawnianiu (NDA), aby nie udostępniać światu kodu źródłowego? Powodzenia z tym!

Moim zdaniem szaleństwem jest ujawnianie klejnotów własności intelektualnej korony innej osobie, dopóki ta inna osoba nie podpisa z Tobą umowy NDA. Planujesz korzystać z usługi takiej jak github, która nie podpisuje umów NDA ze swoimi klientami. Zamiast tego oferują niejasną obietnicę w postaci bardzo długiej umowy EULA (umowa licencyjna użytkownika końcowego).

Sami Github zdają sobie sprawę, że może to być poważny problem, dlatego oferują Github Enterprise jako mechanizm do hostowania kodu źródłowego (i innych prywatnych rzeczy) na własnym serwerze.