Skuteczny sposób utrzymywania przeszłych projektów w środowisku pracy?

Zauważyłem, że ilekroć chcę uruchomić poprzedni projekt, minie dużo czasu, nim go znajdę i zanim ponownie skonfiguruję wszystko, aby mógł on działać.

Na przykład mam projekty w języku Python, które utworzyłem w systemie Linux i zależy to od pakietów oprogramowania, które można łatwo zainstalować w systemie Linux, ale nie mam już używanej maszyny wirtualnej z systemem Linux. Niektóre inne moje projekty zależą od innych zmiennych, takich jak konfiguracja serwera WWW, zmienne PATH, sdk, IDE, wersja systemu operacyjnego, urządzenie itp.

Czy ktoś ma skuteczny sposób poradzenia sobie z tym problemem? Na razie zajmowałem się tylko utrzymywaniem kopii zapasowej kodu źródłowego, ale trudno jest przywrócić działające środowisko programistyczne, a także trudno jest utrzymać działające środowisko programistyczne .

To, co zrobiłem w przeszłości, to albo przekształcenie maszyny do programowania fizycznego w maszynę wirtualną, albo jeśli jest to już maszyna wirtualna, zachowaj ją do wykorzystania w przyszłości. Nie jest tak wydajny, jak bym chciał, jeśli chodzi o wykorzystanie miejsca na dysku, ale miejsce jest tanie. Ponadto ten proces jest o wiele tańszy pod względem czasowym niż próba ponownej konfiguracji środowiska w przyszłości, jeśli zajdzie taka potrzeba.

Moją ulubioną metodologią jest utrzymywanie skryptu, który instaluje WSZYSTKIE niezbędne zależności dla projektu, pobiera źródło i łączy wszystko. Niektóre skrypty mają dwa tryby - jeden do produkcji, który zwykle jest właściwie podzbiorem drugiego trybu: programowanie.

Niektóre środowiska zajmują tylko około 5 minut, aby zainstalować za pomocą skryptu - w takim przypadku mam lokalną maszynę wirtualną ze świeżą instalacją docelowego systemu operacyjnego, na którym wdrażam skrypt projektu po przyjeździe do pracy rano - a następnie wykonuję całe kodowanie powiązane prace nad tym wystąpieniem maszyny wirtualnej. Przed wyjazdem wypycham wszystkie zmiany za pomocą git na moją maszynę fizyczną lub nasze centralne repozytorium i kończę maszynę wirtualną.

Jeśli instalacja trwa dłużej (instalacje długo działające, pobieranie dużych plików itp.), Powyższą procedurę wykonuję raz w tygodniu.

Zaletą jest to, że bardzo łatwo jest wdrożyć na nowej maszynie i / lub serwerze produkcyjnym, wszystko jest udokumentowane w skrypcie, a skrypt jest bardzo często weryfikowany.

Opisywana koncepcja polega na zarządzaniu konfiguracją. To brzmi, jak się wydaje, sposób na identyfikację, nagrywanie, wersję / śledzenie i raportowanie środowiska. Często jest to zadanie ściśle związane z kontrolą wersji i zarządzaniem kompilacją, ale jest wystarczająco wyraźne, co często wymaga osobnej strategii, nawet jeśli wykorzystuje niektóre z tych samych koncepcji i te same mechanizmy przetwarzania i przechowywania.

Zarządzanie konfiguracją oprócz pomocy w utrzymywaniu kontroli nad środowiskiem pracy pomaga również ustanowić rejestr różnych środowisk roboczych, w których używane jest oprogramowanie (rozwój, jak wspomniano, plus testowanie / kontrola jakości, wdrożenie do rutynowych klientów, wdrożenie do klientów wymagających szczególnej uwagi lub specjalnej konfiguracji lub buduj właściwości itd.).

Jak powiedziałem, często jest to zadanie, które pokrywa się z kontrolą wersji źródłowej, a często dane zarządzania konfiguracją znajdują się obok źródła w dokumentacji i repozytorium źródłowym. Nie musi tak być, ale często jest to dla wygody.

Automatyzacja niektórych aspektów zarządzania konfiguracją znacznie się poprawiła w ostatnich latach. Niektóre odpowiedzi i komentarze sugerowały skrypty jako sposób na promowanie zarządzania konfiguracją, a skrypty są dobrą odpowiedzią na uzyskanie powtarzalnych wyników, ale często ręcznie tworzone skrypty są niespójne i niekompletne. Jednym z takich sposobów ulepszenia jest automatyczne udostępnianie. Systemy takie jak marionetka lub szef kuchnipomagać w określaniu komponentów i systemów oprogramowania dla konkretnego użytkownika lub maszyny lub dla konkretnego profilu zadania oraz dostarczać „przepisów”, które pozwalają na bezproblemowe podejście do konfigurowania kompletnej maszyny lub środowiska. Zasadniczo przyjmuje koncepcję repozytorium dystrybucji oprogramowania i rozszerza ją i uogólnia, zapewniając nie tylko pakiety oprogramowania potrzebne dla systemu, ale także profile konfiguracji specyficzne dla każdego pakietu, dzięki czemu jest on gotowy do użycia w sposób odpowiedni dla twojego sytuacja.

Vagrant podąża to w nieco innym kierunku i zapewnia sposób szybkiego rozwijania definicji maszyn wirtualnych, dzięki czemu maszyna wirtualna może mieć automatycznie przydzielane oprogramowanie i sprzęt wirtualny oraz może okazać się wygodnym sposobem na odtworzenie określonej reprezentacji sprzętu środowisko używane przez użytkownika oprogramowania.

Konfiguracja każdego systemu (i jego odmian) zajmuje trochę czasu, ale ma pewną wyraźną wartość, jeśli przeładowanie i ponowna konfiguracja są częstym zadaniem.

Docker byłby dobrym rozwiązaniem. Możesz użyć pliku dokującego, aby działać jako manifest dla żądanej maszyny wirtualnej. Nie musisz przechowywać żadnego obrazu, pobierze on wymagany. Ponadto może używać własnych obrazów, dzięki czemu można utworzyć własny obraz podstawowy, a następnie dodać składniki wymagane przez środowisko.

Za pomocą okna dokowanego może to również poprawić inne części przepływu pracy:

• Utworzone środowisko można umieścić na tym samym CVS, co projekt, co daje środowisko z wersją (fajnie!)
• Za pomocą dokera można zapewnić środowisko na żywo, zmniejszając trudności związane z uruchamianiem projektów w produkcji.
• Jeśli inni zaczną z tobą współpracować, wystarczy plik dokera, aby załadować tak ogromne środowisko.

Pomysły na użycie maszyny wirtualnej są więc tylko częściowo słuszne. Wiem, że dyski twarde stają się coraz większe, ale nie jest to powód do wykorzystywania całej dostępnej przestrzeni. Ponadto, gdy środowisko VM potrzebuje więcej miejsca na dysku twardym wewnętrznie, może to być nieco trudne i istnieje szansa, że ​​będziesz musiał je odbudować. Chociaż rozmiar pliku może nie być problemem, prędkość Internetu nadal staje się wąskim gardłem, gdy trzeba wysłać ponad 5 Go na zwykłym połączeniu DSL.

Większość systemów (języki, środowiska wykonawcze lub systemy operacyjne) ma jakiś znormalizowany sposób instalowania oprogramowania i konfiguracji, więc spróbuj ich użyć. Jak na przykład:

• Maven lub Gradle dla Java
• CPAN dla Perla
• rpm dla RedHat / Fedora
• dpkg / apt-get dla Linux
• Pakiety MSI dla Windows

Następnie wykonaj instrukcje instalacji wyjaśniające dokładnie, co należy zainstalować / jakie kroki są konieczne:

• Podaj krótkie instrukcje dotyczące tego, co chcesz zainstalować (podstawowy system operacyjny, podstawowe środowisko wykonawcze, takie jak Java / Perl / Python ...)
• Napisz krótki skrypt, który wykonuje wymagane instalacje (najlepiej tylko jedno wywołanie narzędzia takiego jak Maven)
• Przetestuj to podczas nowej instalacji (np. Na maszynie wirtualnej)

Następnie powinieneś być w stanie odtworzyć środowisko, a inni także powinni to zrobić (co może być ważne, jeśli nie jest to projekt solo).

Może być konieczne przechowanie gdzieś niezbędnych pakietów instalacyjnych lub dołączenie instrukcji pobierania (chyba że system śledzi te, takie jak apt-get lub Maven). Zależy to od tego, jak bardzo ufasz dostawcom pakietów - prawdopodobnie nie musisz przechowywać podstawowych pakietów Debiana, ale przy niewielkim projekcie wolnego oprogramowania może to być dobry pomysł.

Rozwiązanie maszyny wirtualnej również będzie działać i prawdopodobnie będzie mniej pracowało w krótkim okresie (po prostu zachowaj maszynę wirtualną). Uważam jednak, że to rozwiązanie oferuje większą elastyczność, na przykład przy zmianie środowiska.