Czym dokładnie są „prawdziwie powtarzalne kompilacje”?

Czym dokładnie są? Dlaczego są one ważne w dziedzinie ciągłej dostawy?

Kontekst: Widziałem w jednym z komentarzy (wydaje mi się, że reddit), że kompilacje Naprawdę Powtarzalne są wciąż technologią niedokładną i bardzo trudno ją stworzyć.

Chciałem więc wiedzieć, dlaczego tak trudno je stworzyć?

Czym dokładnie są?

Oto cytat z odtwarzalnych-builds.org :

Odtwarzalne kompilacje to zestaw praktyk programistycznych, które tworzą możliwą do zweryfikowania ścieżkę od czytelnego dla człowieka kodu źródłowego do kodu binarnego używanego przez komputery.

Dlaczego są ważne?

IMO najłatwiejszym sposobem wyjaśnienia ich znaczenia jest rozważenie ich jako odmiany procedury tworzenia kopii zapasowej.

Jako przykład:

• Załóżmy, że firma korzysta (zależy) od pewnego pakietu oprogramowania licencjonowanego od jakiegoś dostawcy oprogramowania. Podczas gdy firma otrzymuje tylko pliki wykonywalne, a nie źródła itp., Które zostały użyte do ich utworzenia.

• Wszystko idzie dobrze, ale w pewnym momencie coś idzie nie tak z dostawcą oprogramowania, np. Przestaje działać (np. Bankructwo).

• Może to narazić na ryzyko ryzyko (na dłuższą metę). Tj. Jeśli firma nie ma procedury / umowy, aby uzyskać (legalny) dostęp do wszystkich wymaganych źródeł, dokumentacji, procedur kompilacji itp. Związanych z czymkolwiek od dostawcy oprogramowania używanego (w czasach), kiedy pliki wykonywalne (używane przez firma) zostały utworzone (i wysłane do firmy).

• Właśnie tam przychodzi „ Software Escrow ”: jeśli istnieje taka umowa, można by pomyśleć, że za pośrednictwem strony trzeciej nadal będzie możliwe uzyskanie przez firmę dostępu do „ wszystkiego, co zostało wykorzystane ”, w celu odtworzenia pliki wykonywalne, aby odtąd firma mogła mieć szansę na dalsze korzystanie z tego oprogramowania i tam, gdzie odpowiedni sam zacznie go utrzymywać (tylko do prowadzenia własnej działalności).

• Jednak „ cokolwiek zostało użyte ” w poprzednim punkcie jest najtrudniejszą częścią, aby to zadziałało. Wymaga to, aby strona trzecia przeprowadziła odpowiednie zatwierdzenia z góry. I zaufaj mi, minęło trochę czasu, zanim odtworzysz plik wykonywalny, dla którego możesz udowodnić, że oprócz (np.) Daty łącza, idealnie pasuje do tego, co sprzedawca oprogramowania dostarcza agentowi oprogramowania.

I dlaczego są tak trudne do stworzenia?

Jeśli powyższa próbka nadal nie jest wystarczająco jasna, wyobraź sobie, że jesteś moim agentem oprogramowania, powiedz mi, czego potrzebujesz jako danych wejściowych do odtworzenia kopii oprogramowania licencjonowanego przez mojego klienta. Zdobyć? Nie zapomniałeś sprawdzić, która wersja mojego kompilatora, może mój system operacyjny, opcje kompilacji / linku, wersje komponentów wielokrotnego użytku (obejmuje), biblioteki itp.?

Aby podać praktyczny przykład próby stworzenia prawdziwie powtarzalnej kompilacji, rozważ następujące kwestie:

Potok kompilacji, który zaczyna się od repozytorium git, dla którego żaden użytkownik nie może przepisać historii ani usunąć nie połączonych gałęzi.

Pierwszym krokiem po kompilacji po sprawdzeniu kodu źródłowego jest rozpakowanie kontenera zawierającego wszystkie zależności czasu kompilacji.

Dane wyjściowe uruchomionego kontenera czasu kompilacji to kontener zawierający skompilowany plik binarny.

Co ważniejsze dla powtarzalności kompilacji, do końcowego kontenera dodawane są następujące tagi:

• Dokładny skrót kodu źródłowego w oryginalnym repozytorium oraz adres URL zarówno repozytorium git, jak i migawki tar tar kodu, który jest przesyłany do repozytorium artefaktów.
• Dokładna wersja kontenera kompilacji, która została użyta do uruchomienia kompilacji.
• Dokładna wersja oryginalnego obrazu podstawowego, do którego załadowano plik binarny.
• Wartości wszystkich zmiennych czasu kompilacji użytych do utworzenia pliku binarnego.
• Wersja dokera, w którym zbudowano wszystkie trzy kontenery, a także wersja, w której działały, gdy budowano.

Dodając wszystkie te metadane, możemy zapewnić, że w dowolnym momencie w przyszłości możemy wyciągnąć dokładny zestaw zależności kompilacji (za pośrednictwem kontenera kompilacji), skompilować plik binarny z dokładnie znanym zestawem kroków (zapisanym w kontenerze kompilacji ) i spakuj do innego znanego obrazu podstawowego ze wszystkimi zależnościami w czasie wykonywania (przy użyciu znacznika obrazu podstawowego), a wszystko to może być oparte na dokładnej poprawnej wersji kodu źródłowego opartego na znaczniku na kontenerze.

Teoretycznie powinno to dać nam możliwość dokładnego odtworzenia wersji kompilacji.

Ważne jest to, że pozwala nam spojrzeć na to, co działa w produkcji, i nawet jeśli wszystko znacznie się rozwinęło, cofnij się i wyciągnij wersję kodu, obrazu podstawowego i kontenera kompilacji pierwotnie użytego, abyśmy mogli na przykład , zastosuj poprawkę do tej wersji przed przebudowaniem dokładnie tak jak poprzednio, abyśmy mogli wdrożyć ponownie wiedząc, że jest to dokładnie ten sam artefakt, a jedyną różnicą jest poprawka.