ArchiveKwiecień 2018

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

O rolach i odpowiedzialnościach

The A Team Znacie serial pt. „The A Team”? Fabuła tegoż serialu traktowała o drużynie właśnie, byłych wojskowych, komandosach, którzy wykonywali różne, niebezpieczne misje w obronie dobra. Jakoś tak. Każda główna postać była wyjątkowa. Każdy bohater należący do owej drużyny miał swój wysoce jaskrawy charakter, co ciekawe, jednoznacznie określający rolę członka drużyny w drużynie.   Życiowe inspiracje filmem Wspominam o tym ponieważ mam wrażenie, że praca w zespołach w branży IT opiera się na takich samych zasadach. Każdy zajmuje się tym, co lubi, tym co zna najlepiej, tym co sam napisał lub tym, czego akurat ma ochotę się nauczyć. Dzielenie się wiedzą i kompetencjami nie następuje – bo i po co – prawda? Przecież NIE dojdzie do sytuacji, gdzie braknie jedynego człowieka mającego wiedzę nt. kluczowego elementu w projekcie. To się NIE wydarzy, prawda? Ponadto, jak się coś schrzani na produkcji łatwiej WYTYPOWAĆ winnego, prawda? Tego, który ZOSTANIE w...

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

Newsletter



Społecznościowe

Historycznie

Tagi