Od stycznia 2018 pełnię obowiązki lidera kompetencji – Programowanie (.NET)
Swoją pracę chciałbym traktować usługowo na rzecz zespołów.
Jestem otwarty na sugestie jakie kompetencje chcielibyście, aby były rozwijane w naszych zespołach.
Jak widzicie .NET jest w nawiasie, więc nie chciałbym jednak, aby było to ograniczeniem zakresu kompetencji, które będziemy rozwijać w naszych zespołach.
Ostatnie posty:
Pułapka w design-time DbContext Creation
W dokumentacji na stronie: https://learn.microsoft.com/en-ie/ef/core/cli/dbcontext-creation?tabs=dotnet-core-cli opisano 3 sposoby w jaki niektóre polecenia narzędzi EF Core Tool próbują utworzyć DbContext w czasie projektowania. Przykładowo wykonanie komendy dotnet ef migrations add mojaTestowaMigracja wymaga zapewnienia możliwości utworzenia DbContext-u. Jedną z metod jest dostarczenie konstruktora bezparametrowego. W jednym z projektów zdecydowaliśmy się korzystać z tej drogi. Jednak okazało się, […]
GitLab Flow – Historia
Historia Historia jest w Git acyklicznym grafem skierowanym. Mówiliśmy, że nalezy dbać o historę aby była prosta i czytelna: Wprowadzanie nowej funkcjonalności: Wprowadzanie poprawki ma masterze i jednej wersji wcześniejszej: Zwróćmy uwagę, że: poprawkę implementuje się tak samo jak nową funkcjonalność. wszystkie commity z poprawki sa cherry-pickowane jako jeden commit. pomimo braku konfliktów może wystapić […]
GitLab Flow – Nowa funkcjonalność
Nowa funkcjonalność Propozycja flow pracy jak implementować nową funkcjonalność w zgodzie z zasadami. 00 Nigdy nie commitujemy do mastera Gałąź master powinna być gałęzią chronioną (protected), do której deweloperzy nie mają możliwości bezpośredniego pushowania. Wszelkie zmiany powinny odbywać się na feature branchach i być wprowadzane do mastera poprzez merge z feature branch. 01 Utworzenie gałęzi […]
GitLab Flow – Dekalog
Dekalog jaki dał Ci GitLab 1. Nie będziesz commitował bezpośrednio do mastera. Wszelkie zmiany powinny być rozwijane na feature branch i być wprowadzane do mastera poprzez merge. Gałąź master powinna być gałęzią chronioną (protected), do której deweloperzy nie mają możliwości bezpośredniego pushowania. 2. Commit message będzie odzwierciedlał Twoje prawdziwe intencje. Commit message powinien w zwięzły […]
GitLab Flow – Commitujemy często!
Commitujemy często. Zachowujemy SRP dla commitów Zachowujemy zasadę pojedynczej odpowiedzialnosci dla commitów. Przykład w TDD: osobne commity dla red, green, refactor. Commity powinny zależeć, więc nie tyle od czasu, ale od zakodowanych funkcjonalności. Jednakże zrobienie commita i pusha raz dzienne wydaje się absolutnym minimum. Cele Kopia zapasowa Historia rozwoju projekty, funkcjonalności Możliwość cofnięcia się do […]