3 posty z tagiem "Git"

Ukończyłem LFD140 „GitHub for Open Standards Development" od The Linux Foundation. Kurs uczy, jak przenieść zasady grupy roboczej do repozytorium: kto zatwierdza zmianę normatywną, którą gałęzią idzie specyfikacja do ratyfikacji, gdzie zapisać sprzeciw i jak wymusić to ochroną gałęzi i CI. Ten model uważam za dobry i wart przeniesienia także poza fundacje open source. Przykładowe bramki GitHub Actions z materiałów kursu uruchomiłem jednak lokalnie, na odtworzonym checkoucie pull requesta. Z pięciu skryptów żaden nie działa poprawnie w podanej postaci. Dwie kontrole CHANGELOG przepuszczają zmianę w specyfikacji bez wpisu, dwie bramki blokują PR-y, które powinny przejść, a krok sprawdzający etykietę przechodzi zawsze. Próg „dwóch zatwierdzeń" liczy recenzje zamiast recenzentów. Poniżej opisuję, co z kursu warto wziąć, co w przykładach nie działa i jak wyglądają poprawione wersje.

Średni koszt naruszenia ochrony danych wynosi obecnie ponad 4,4 miliona dolarów, a ręczne łatanie luk drastycznie obciąża budżety operacyjne organizacji. Odpowiedzią na te wyzwania jest zautomatyzowane podejście DevSecOps realizowane przez GitHub Advanced Security (GHAS), które osadza procedury ochronne bezpośrednio w cyklu życia oprogramowania (SDLC). Zastosowanie zaawansowanej automatyzacji i wczesnej analityki kodu znacząco obniża ryzyko biznesowe, uwalnia moce przerobowe inżynierów i gwarantuje wymierny, wielokrotny zwrot z poczynionych inwestycji.

Ręczne zarządzanie wersjonowaniem (SemVer) i pisanie notatek do wydań (changelog) to procesy podatne na błędy i niepotrzebnie angażujące czas dewelopera. W podejściu Automation First proces ten powinien dziać się "w tle". Poniżej przedstawiam implementację w pełni zautomatyzowanego potoku CI/CD opartego o semantic-release oraz GitHub Actions.