Słowem wstępu Praca z Gitem. Dużo się o nim mówi, zwłaszcza w środowisku .NET, głównie ze względu na to iż Microsoft kupił Github, a także udostępnił źródła .NET Standard i .NET Core na licencji Open Source (MIT). Osobiście, ciągle się uczę Gita i przy okazji sprawdzam, testuję różne rozwiązania około-gitowe. Wtyczki, narzędzia, różnego rodzaju integracje z Gitem. To sprawia, że wiem co mogę i ile mogę. Gita świetnie się obsługuje z poziomu konsoli czy terminala i przy tym pozostanę, ale zawsze dobrze mieć coś w zanadrzu. Zamysł Ludzie są różni i różne potrzeby mają. Ha! Taki komunał na początek. Dlatego nie każdy będzie używać konsoli do pracy z Gitem. Osobiście uważam że jest to najlepsza droga ku temu, ale hej…każdy lubi „po swojemu”. Do tematu podszedłem od strony czysto użytkowej. Git jest wspaniały ale, jak ze wszystkim, nie dla każdego. Owszem, da się, ale czy to oznacza, że od razu trzeba? Dlatego filozofie nt. tego czy trzeba czy nie, zostawiam na...
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...
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>” ...
Visual Studio i ReSharper w jednym stali domu…
Mam w pracy tę możliwość, że zazwyczaj mogę używać najnowszego Visual Studio, w połączeniu z ReSharper’em rzecz jasna. Często najnowszego .NET’a czy dotNET core’a (zaraz sobie język połamię). Cenię sobie tę możliwość, bo pozwala mi to być na bieżąco z głównym narzędziem/środowiskiem pracy całej rzeszy dotnetowców, siszarpowców i nie tylko. Jednakże rodzi to czasem problemy, no bo jakżeby inaczej. „Bunt maszyn” czy co? W każdym bądź razie ostatnio, dosyć często, Visual Studio nie radzi sobie z ReSharper’em. Może na odwrót? Nie ważne. Ważne, że Visual Studio czasami nie widzi możliwości dodania referencji do klasy, dll’ki którą właśnie chcę użyć. Czasami nawet po dodaniu tej referencji „ręcznie”, VS nadal uważa, że jej nie ma i podkreśla to użycie czerwoną linią wstydu. Na szczęście podczas builda wszystko jest w porządku, co nie zmienia faktu, że całe Visual Studio świeci czasami na czerwono. Jedynym rozwiązaniem, a raczej...
