TagJenkins

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”...

Windows i ścieżki, którymi podąża

Słowem wstępu Dawno, dawno temu została stworzona stała MAX_PATH, decydująca o tym jak długie mogą być ścieżki do plików i katalogów w systemie Windows. Jest to setting na poziomie Windows API. Ostatnio w pracy dotknął mnie ten problem. Niefortunne było to, że problem objawił się podczas modyfikowania pliku projektu jenkinsa, w celu utworzenia joba releasowego. Problem był o tyle uciążliwy, że przecież nie zmienię nagle całej struktury projektu i źródeł które zamierzam budować, ani tez nie będę przenosił całego jenkinsowego workspacea. Zatem opcje były trzy: Instalacja odpowiedniej poprawki do systemu Windows. Zmiana ustawienia w systemie, tak aby mnie nie blokowało. Sprawienie że Windows będzie „widział” ścieżki jako prawidłowe, lub po prostu będzie je akceptować.   Łaty i bilety Opcja nr. 1. Najłatwiejsza ze wszystkich proponowanych. Niestety nie zawsze działa. Link do patcha – PATCH Jest to patch do systemu Windows Server 2012 R2 i zawiera m.in. poprawki do...

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...

Dotnet niepokorny

Siedzisz sobie spokojnie w pracy. Piszesz nowy super-feature, w nowym super-projekcie. Palce biagają po klawiaturze jak małe Usain Bolt’y, wszystko idzie jak z płatka. Aż nagle wpada do pokoju timlider i mówi – „Fajny ten Twój super-projekt. Zrób mu joba jenkinsowego”. Mówisz sobie – „Nie trać rezonu”! Trzeba brać się do roboty!   Do dzieła! Tworzysz nowy projekt na panelu w jenkinsie, bierzesz się za napisanie pliku projektu jenkinsowego. To nic, że Twoja aplikacja jest napisana w dotNET core 2.0, przecież to już dojrzała technologia! Deklarujesz wszystkie potrzebne ścieżki, tworzysz target’y nazewniczo-kompilująco-clean’ujące. Przychodzi czas na gwóźdź programu: [code lang=”xml” wraplines=”true”] <Exec Command=”dotnet publish „$(SolutionFile)” -c $(Configuration) -o „$(dirCreated)””/> [/code] Wiadomo: dotnet publish „<ścieżka pliku solucji>” ...

Autor serwisu

Patryk

Społecznościowe

Instagram

Instagram has returned empty data. Please authorize your Instagram account in the plugin settings .

Newsletter



Historycznie

Tagi