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#02: Atrybuty smoczego pogromcy
Drugi post nt. Continuous Integration. Zapraszam do lektury. „Warsztat smokogromcy” „Atrybuty smoczego pogromcy” Ten, kto tańczy ze smokami, musi się liczyć z tym, że spłonie. George R.R. Martin – Rycerz Siedmiu Królestw Przeciwnik Czy na pewno? Czy nie ma sposobu na walkę ze smokiem? Tym razem będzie lekko. Opiszę pokrótce projekty-smoki które będą bazą do testów. Są dwa: WebApi napisane w C#.NET Core z testami jednostkowymi WebApi napisane w pythonie, bez testów jednostkowych (dopiero się uczę pythona), które ze względu na swoją różną od .NETowej naturę, będzie dobrym porównaniem Jedyne, co te dwa projekciki robią, to udostępniają API RESTowe, za pomocą którego można pobrać listę książek z lokalnej bazy danych MySQL. Nie chodzi o to aby projekt-smok był mega wielki i ociężały. Potrzebne mi były małe, lekkie źródełka do testów narzędzi, opisanych w poprzednim poście. Większy smok… Technology stack: .NET Core 2...
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...
