niedziela, 29 marca 2015

Englishman in New York, czyli jak .NETowiec może uwić sobie gniazdko w świecie MSSQL

Wieczór, herbata, ciepłe papcie, nie za twardy, nie za miękki narożnik, na którym wyciągasz swoje zmęczone nogi. Gdzieś w tle leniwie snuje się muzyczka plum plum plum... Cieplutko, mięciutko, strefa komfortu. Mmmmm... Klawo!
Gdy tak sobie leżysz w apogeum czilałtu muzyka przestaje nagle grać, idąc sprawdzić o co chodzi zahaczasz nogą i wyrywasz kabel sieciowy, potem przepala Ci się bezpiecznik od światła, a z kranu zaczyna ciec woda. Tyle było twojego komfortu...
Jedziesz na tydzień na narty do Czech. Niby wszyscy mili, niby podobny język, ale jednak jakoś tak dziwnie. Uśmiechy wydają się coraz bardziej ukradkowe. Po złożeniu zamówienia w restauracji do ostatniej chwili drżysz czy faktycznie zamówiłeś to co chciałeś.
Albo dajmy na to delegacja do Wałbrzycha lub Sosnowca...

Praca programisty daleka  jest od błogostanu. Nowy dzień, nowe problemy. Pudełko czekoladek prosto od Foresta. Szczególną sytuacją jest zmiana projektu. Konsternacja sięga zenitu. Nowe osoby, nowe środowisko i te parszywe nowe technologie.

"...you can hear it in my accent when I talk, I'm an Englishman in New York"
  
Jakiś czas temu doświadczyłem takiej zmiany. Drastyyycznej zmiany. Z intensywnej pracy przy mocno JavaScriptowym systemie przeszedłem na drugą stronę. Ciemniejszą stronę. Tam gdzie nie ma frontendu - systemu Business Inteligence w MSSQL.

"First I was afraid, I was petrified"
 
Nie tylko Ty się tak czułaś moja droga Glorio.

Suma wszystkich strachów

Czego się obawiałem?
1. Management Studio jest przyzwoitym środowiskiem do zarządzania bazą danych. Z funkcjonalnościami i rozbudowaniem Visual Studio nie ma jednak żadnego porównania. Ot taki mniej rozgarnięty koleżka. Ten co nosi za duże, używane rzeczy po starszym bracie.
2. Skryptów inkrementalnych. Każdy z nas wie jak bolesne jest utrzymywanie tego barachła. Oczywiście można sobie radzić, stosować konwencje nazewnicze, używać migracji w Entity Framework, ale czy to czyni sprawę przyjemną? Don't think so... Znośniejszą. W najlepszym razie. Dodajmy jeszcze do tego konieczność utrzymywania aktualnej struktury bazy, by można było zawsze odtworzyć ją od zera, kontrolę wersji i pracę na wielu branchach. Mniam. Mniam. Paluszki lizać.
3. Wdrażania na różne środowiska. Developerskie, Testowe, Preprod, Produkcjne, NaKolejneZyczenieKlienta. I każde z tych środowisk się trochę różni, na każdym trzeba trochę inne skrypty odpalić. Kup sobie chłopcze zapas melisy jeśli chcesz być wdrożeniowcem, wujo Ci to mówi. Jeden Cherry pick, drugi cherry pick, zapomnisz przerzucić jeden skrypt inkrementalny i KA BOOM! Nie ma Cię - ehę. Albo produkcji. Twoja premia też gdzieś się zapodziała.
4. Struktura i modularność projektu. Jak ładnie utrzymywać strukturę projektu w świecie MSSQL. Podział kodu, modularność, biblioteki, współdzielenie kodu przez różne projekty? Czy to w ogóle możliwe? Projekty w Management Studio, w porównaniu do tych znanych z VS to właśnie te spodnie starszego brata, które podcięto, żeby robiły za bojówki. Do tego kod się nie kompiluje, jak być pewnym, że po zmianie nazwy kolumny nie zapomnieliśmy poprawić kodu, w którejś procedurze? Jak być pewnym, że nasz projekt jest dalej stabilny?
5. No i na koniec duszki Kacperki w porównaniu z poprzednimi punktami. Czyli takie fanaberie jak intellisence, refactoring, sprawdzanie gdzie używana jest procedura, tabela, przystępniejsze debugowanie kodu. Małe rzeczy, które czynią nas szczęśliwszymi. 

SSDT To the Rescue!