FreeIPA zapewnia centralnie zarządzany system tożsamości, polityki i audytowania. Używa połączenia Open Source’owych rozwiązań 389 Directory Server, MIT Kerberos, NTP, DNS, systemu certyfikatów DogTag, SSSD i innych otwartych komponentów.
Testowanie oprogramowania to jedna z ciekawszych dziedzin we współczesnej informatyce. W teorii każda osoba techniczna wie, czym są testy. Często nawet wie, jak je wykonać. Niemniej jeśli zapytać o podstawowe zasady obowiązujące w testowaniu, to niewiele osób potrafi wymienić choćby jedną. O tych zasadach traktuje ten artykuł.
Dziś porównamy dwa odmienne podejścia do używania narzędzia, jakim jest system kontroli wersji Git. Pierwszym podejściem jest git flow, który dawno już podbił serca użytkowników Gita. Drugi to development oparty o gałąź ...
Dewelopment oparty o gałąź główną (Trunk-based development) to sposób pracy z repozytorium kodu, w którym zmiany ewidencjonuje się od razu w głównej gałęzi. Jest antagonistyczny w stosunku do git-flow, przez co wiele osób uważa go za kontrowersyjny. Jest za to skuteczny. W raporcie „Stan DevOps – Raport 2017” trunk-based development jest jednym z wyróżników najlepiej radzących sobie przedsiębiorstw. Dziś opowiem o rozwoju opartym o gałąź główną. Artykuł porównujący to podejście oraz git-flow niebawem.
Zdziwiony? Ja też byłam, gdy czytałam artykuł naukowy o roli architekta w ciągłym dostarczaniu oprogramowania (bibliografia, notka o „wolnym tłumaczeniu”), a tu zaraz obok takich zasad jak „Małe i niezależne jednostki wdrożeniowe”, „Zbieraj logi”, „Izoluj zmiany” czy „Testowalność wbudowana w architekturę” stoi jak byk „Nie skupiaj się zbyt mocno na reużywalności”. Toż wiadomo, że reużywalność to cudowna sprawa! Że piszesz raz, a używasz w nieskończoność. Że oszczędza czas i pracę i obniża koszty utrzymania, zwiększa produktywność itd. itp. Otóż nie wiadomo, bo artykuł w tytule miał jeszcze dopisek „z perspektywy praktyków”, a ulubionym zdaniem inżynierów jest „to zależy”.
W naszym ulubionym Open Source'owym programie brakuje nam funkcjonalności. Co zrobić? Odetchnąć z ulgą 😉 w końcu to Open Source – możemy ją sobie po prostu dopisać. Wystarczy, że znajdziemy kod źródłowy ...
W artykule Automatyzacja z lotu ptaka pisaliśmy o istocie automatyzacji. Z kolei tekst dzisiejszy prezentuje szereg dobrych praktyk i w ten sposób opowiada na pytanie „jak automatyzować?”. Podzieliliśmy je na dwie grupy: ogólne oraz związane ze środowiskami deweloperskimi.
Na naszym blogu można znaleźć wiele artykułów poświęconych automatyzacji, między innymi serię o Ansible. W tym tekście zrobimy krok w tył, żeby zobaczyć automatyzację w szerszej perspektywie. Przyjrzymy się jej roli w DevOps oraz powiemy wysokopoziomowo o samej automatyzacji.
W związku z zapotrzebowaniem na artykuły z pogranicza technicznego, ale nie niosące zbyt dużego ciężaru gatunku, dziś rozpoczynamy kolejną serię tekstów. Będzie ona mówić o wytwarzaniu oprogramowania z punktu widzenia różnych metodyk. ...
Artykuł zakłada, że czytelnik posiada przynajmniej minimalną wiedzę na temat Gita. Niektóre z zagadnień będą jednak na odrobinę wyższym poziomie. Przydatna może okazać się także wiedza na temat programowania w powłoce BASH i o szeroko pojętym Linuksie.
W związku z dużym zainteresowaniem poprzednim artykułem o Gicie postanowiłem umieścić na naszym blogu kilka komend/praktyk/instrukcji, które w mojej pracy z tym narzędziem okazały się bardzo przydatne lub zostały przeze mnie uznane za ciekawe.
Dawno, dawno temu, za siedmioma mainframe'ami, za siedmioma terminalami, a przed siedmioma monitorami pracowali programiści. Już w tych ciemnych wiekach, kiedy nie było jeszcze internetu, facebooka i wielu innych wynalazków programiści, dziś zwani dumnie deweloperami, musieli współpracować razem. Chcieli osiągnąć ambitny cel, jakim było, i jest do dziś, wytworzenie działającego oprogramowania. Każde z tych przedsięwzięć borykało się z tym samym problemem – synchronizacją pracy nad kodem źródłowym.