TagTeamCity

Continuous integration#03: Docker. Containers. Swarm.

Trzeci post nt. Continuous Integration.  Omówienie i krótki wstęp do inicjalizacji docker swarm, w celu utworzenia środowiska dla testów build serwerów. „Warsztat smokogromcy” „Atrybuty smoczego pogromcy” „Docker. Containers. Swarm.” Podejście kolejne Od czasu ostatniego wpisu dotyczącego Continous Integration, Continous Delivery, Continous Deployment, w kontekście testu build serwerów, minęło kilka miesięcy. W tym czasie popełniłem kilka mniej wymagających (ale nie mniej znaczących!) postów. Nabrałem trochę wprawy w blogowaniu i w wyrażaniu własnych myśli, a także nauczyłem się sporo w dziedzinie samej „developerki”. Uznałem, że czas powrócić do tematu automatyzacji, pobawić się trochę DevOpsowymi zabawkami.   Na dobrej zabawie, czas szybko płynie.   W tym wpisie wyjaśniam, jak widzę dalszą pracę z przygotowaniem środowiska i jak widzę kolejne kroki. Zastrzegam również, że jestem przygotowany na „bunt maszyn”...

Continuous integration#01: Warsztat smokogromcy

Jest to pierwszy post nt. Continuous Integration. W miarę pisania, będą się pojawiać kolejne. „Warsztat smokogromcy” „Atrybuty smoczego pogromcy”   W tym szaleństwie jest metoda Continuous Integration – według definicji jest to praktyka programistyczna, wedle której członkowie zespołu często winni scalać wyniki swojej pracy (przynajmniej raz dziennie). Potem jakiś automatyczny system buduje/testuje, powstałe wcześniej zintegrowane wersje kodu. Uważam że, do pełni szczęścia potrzebne są jeszcze procesy Continuous Delivery i Continuous Deployment. Sama praktyka programistów, którzy w miarę często (raz dziennie to jednak zbyt rzadko) commitują swoje zmiany, nie wystarczy. Bardzo ważną rolę odgrywają właśnie tzw. build serwery (Source automation servers), które potrafią budować projekty, testować je i dodatkowo publikować je na określone maszyny/serwery/środowiska. Tym tematem zajmiemy się innym razem. Tymczasem…   Teoria broni W tym cyklu...

Newsletter



Społecznościowe

Historycznie

Tagi