Pod Hyper-V pracuje maszyna wirtualna z Linux. Część z plików została wykasowana z Linuxa, ale rozmiar dysku wirtualnego pozostał duży (ok 45 GB). Dostępny w konsoli Hyper-V edytor dysku, mimo wydania komendy zmniejszenia dysku, nie zmniejszył rozmiaru, albo zrobił to w minimalnym zakresie. Co robić?

1. Kilka operacji do wykonania na systemie gościa – Linuxa. Oczywiście na początku kasujemy wszelkie niepotrzebne pliki (ale to nie główny temat tego wpisu). Następnie na dysku na którym występuje problem (u mnie to dysk podmontowany w katalogu root) należy wykonać takie oto polecenia:

su
cd /
cat /dev/zero > zero.dat ; sync ; sleep 1 ; sync ; rm -f zero.dat

O co chodzi? Hyper-V zoptymalizuje tylko „wyzerowane” sektory. Ta komenda całe puste miejsce dysku zapełnia zerami. Dzięki temu, za chwilę komendy Hyper-V zobaczą to puste miejsce. Polecenie zapełnia dysk na 100% używając też miejsca wykorzystywanego przez juz usunięte pliki i o to właśnie chodzi. Jeśli na systemie linux działa jakaś ważna aplikacja, to zapełnienie dysku może być dla niej poważnym problemem – przemyśl ten krok 😉

2. Wyłącz linuxa.

3. Na systemie hosta, w powershellu uruchomionym jako administrator:

Optimize-VHD "C:\HV-Machines\exported u20\U20\Virtual Hard Disks\U20.vhdx" -Mode Full

To polecenie dokonuje pełnej optymaliacji dysku usuwając wyzerowane sektory. W moim przypadku rozmiar dysku spadł z 45 GB do 33, a wcześniej uruchamiany kreator nie zwalniał praktycznie nic.

Źródła:

How to compact VHDX files in the most efficient way – C:Amie (not) Com! (c-amie.co.uk)

virtual machine – Linux VHDX size on Hyper-V – Stack Overflow

Mówią, że Windows to system prosty, zbyt prosty, że prawdziwi profesjonaliści wybierają Linuxa, bo na Windows można umrzeć z nudów. Tak? To jak spowodować, żeby pliki mp4 automatycznie uruchamiały się np. z odtwarzaczem VLC?

• Programy domyślne – nie działa
• Instalacja kodeków – nie działa
• Instalacja / Deinstalacja Films & TV – nie pomaga
• Grzebanie po rejestrze – odpada.
  Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mp4\UserChoice
  Skojarzenie pliku z programem jest dodatkowo zabezpieczone przez sumę kontrolną i nie wiem jak ją wyliczyć…. ale ktoś wiedział…

Pobierz program

https://kolbi.cz/SetUserFTA.zip

A następnie uruchom polecenie:

SetUserFTA.exe" .mp4 "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe"

Sprawdź. U mnie działa. Koniec.

How to make VLC or Windows Media Player to open mp4 files without asking additional questions?

• download https://kolbi.cz/SetUserFTA.zip
• run command

   SetUserFTA.exe" .mp4 "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe"

• done!

Azure CLI uruchamiane z linii komend jest zdecydowanie prostsze niż wykonywanie tej samej czynności z poziomu PowerShell. No dobrze, może nie zawsze, ale zdarza się. Na przykład do utworzenia alertu, w przypadku PowerShella trzeba utworzyć kilka różnych obiektów programistycznych, które w końcu łączy się w całość. Nie jest to problem dla programisty, ale administrator może mieć odmienne zdanie.

Niestety z CLI jest taki problem, że zbudowanie poleceń, które nawzajem wykorzystywałyby swoje wyniki wymaga znajomości języka skryptowego BASH. BASH jest starszy, żeby nie powiedzieć „toportniejszy” od nowoczesnego PowerShella.

Ostatnio spotkałem jednak eleganckie rozwiązanie na usunięcie grupy zasobów, której nazwa rozpoczyna się od zadanego ciągu znaków. No po prostu bardzo mi się to spodobało:

az group list --query "[?starts_with(name,'lab-dev-de')].name" --output tsv

To polecenie poszuka takich grup. Warto je uruchomić przed usuwaniem, bo właśnie te grupy zasobów zostaną usunięte w kolejnym kroku. Korzystamy z opcji group list, czyli wylistuj grupy zasobów, których nazwa zaczyna się od czegoś tam.

No i polecenie usuwające:

az group list --query "[?starts_with(name,'lab-dev-de')].[name]" --output tsv | xargs -L1 bash -c 'az group delete --name $0 --no-wait --yes'

Zaczynamy od polecenia szukającego określonej grupy zasobów i potokiem przekazujemy do xargs, którego zadaniem jest uruchomić komendę z parametrami. polecenie to az group delete, a parametr to $0 – czyli nazwa grupy zasobów. Reszta parametrów jest przekazywana statycznie. O nic nie spyta tylko weźmie i usunie. Wygodne (i niebezpieczne)

Azure DevOps daje specjalistom dostęp do zestawu narzędzi takich jak

• boards,
• pipelines,
• repos,
• artifacts i
• test plans.

Wszystkie te narzędzia są ze sobą zintegrowane pozwalając z jednej strony przypisać zadania członkom zespołu, a z drugiej strony wykonać zmiany w kodzie, które zostaną automatycznie zbudowane i przetestowane, a informacja o zakończeniu zadania może być automatycznie odnotowana w Azure Boards śledzącym postęp pracy.

W świecie IT występują dziesiątki narzędzi dających podobne funkcjonalności do Azure DevOps, ale Azure DevOps jest zintegrowaną platformą. Wybór odpowiednich narzędzi może też być determinowany przez typ realizowanego projektu. Jeśli projekt jest open source, to prawdopodobnie chętniej skorzystamy z GitHub, bo to również jest rozwiązanie typu open source. Z kolei, jeśli realizujemy zadanie wewnętrzne w firmie już korzystającej z Azure DevOps, to naturalnym wyborem będzie właśnie Azure DevOps.

Azure DevOps integruje się z Microsoft Account, co pozwala na przypisywanie odpowiednich uprawnień i definiowanie ról. Sam dostęp do konta można zabezpieczać przez multifactor authentication. Mamy tu też już predefiniowane role i policy, które pozwalają zaimplementować wewnętrze polityki bezpieczeństwa organizacji. Dostęp może być też definiowany w luźny sposób, np. wykorzystując tylko access token.

GitHub, chociaż open source też ma mnóstwo zalet, które są dostarczone w może trochę inny sposób:

• codespace pozwala na tworzenie chmurowego środowiska programistycznego,
• repos pozwalają na przechowywanie kodu aplikacji w kontrolowany sposób, integruje się z git,
• przy pomocy actions pozwala automatyzować budowanie i dostarczanie aplikacji,
• przy pomocy już wcześniej opublikowanych pakietów na GitHub, możemy się z nimi łatwo integrować,
• zawiera również narzędzia skanujące kod przed popularnymi zagrożeniami.

Zarówno AzureDevOps, jak i GitHub są dostępne w wersji płatnej i darmowej.

Azure DevOps nie jest przy tym zamknięty na świat Microsoft. Projekty można migrować niezależnie, można korzystać z wielu narzędzi, platform, a nawet budować rozwiązania do konkurencyjnej chmury.

Azure Boards to narzędzie pozwalające planować pracę podobnie jak w Kanban. Boards może być połączony także z GitHub. Zwykle praca jest dzielona co najmniej na 3 etapy: „to do”, „in progres” i „done”. Zadania dodatkowo klasyfikuje się do odpowiedniej kategorii, jak np. „bug”.

Zadania są zdefiniowane raz, ale mogą być wyświetlane z punktu widzenia jednego użytkownika, całej firmy albo jednego repozytorium. Zdefiniowane zadania mogą być aktualizowane w mniej lub bardziej automatyczny sposób przy pomocy szablonów. Dobra klasyfikacja zadań pozwala w kolejnym kroku na dobre raportowanie, a to z kolei pozwala na ustalenie czy są osiągane KPI.

Azure Board może być połączone z kontem GitHub pozwalając prezentować na Azure Boards postęp prac nad projektem publikowanym na GitHub.

https://learn.microsoft.com/en-us/azure/devops/boards/github/connect-to-github?view=azure-devops

Odpowiednikiem Azure Board na GitHub jest Git Project Board. Cel obu tych narzędzi jest podobny – śledzenie postępu prac nad projektem programistycznym.

Zmiany wprowadzane przez programistów powinny koniec końców zostać opublikowane w postaci kodu. Ten kod jest umieszczany w systemie kontroli wersji, którym może być Azure Boards lub GitHub. Co warto zauważyć można korzystać z Azure Boards, ale swój kod publikować na GitHub. W systemie kontroli wersji  zachowywana jest cała historia wykonywanych zmian przez wszystkich programistów. Dzięki temu można w dowolnej chwili sprawdzić stan określonej linii kodu w dowolnym pliku. W razie potrzeby można więc wrócić do wcześniejszej wersji.

Dobrą praktyką w tworzeniu kodu jest:

• Tworzenie małych zmian
• Publikowaniw tylko plików, które budują projekt (żadnych plików personalnych)
• Częsta aktualizacja kodu (push/pull)
• Weryfikacja kodu przed wyslaniem do repozytorium
• Czytanie (!!!) komunikatów zwracanych przez git
• Łączenie wykonywanych zmian z przypisanymi zadaniami (Azure Boards)
• Współpraca – niezależnie od pozycji w zespole

Kod źródłowy jest utrzymywany w centralnej lokalizacji i wykorzystywany przez wielu programistów jednocześnie. Z drugiej strony kod przechowywany może być w postaci dystrybuowanej. Dystrybucja polega na tym, że cały kod aplikacji jest w pierwszej kolejności ściągany lokalnie na komputer użytkownika i tam programista zarządza kodem tworząc np. nowe branch, czy commitując swoje zmiany. Dopiero w pewnym momencie wysyła te zmiany do centralnej lokalizacji, którą jest GitHub Repo lub Azure Repo.

Każdy projekt zaczyna się tak samo: od potrzeby klienta. Sama potrzeba jest zwykle na początku bardzo słabo opisana. Dzięki pracy architekta można jednak zdefiniować wymagania klienta, które da się przenieść do postaci funkcjonalności aplikacji, tzw. functional & non-functional requirements.

W oparciu o requirements i dokładniej opisane rozwiązanie (Low Level Design), do pracy przystępują programiści. Właściwie to właśnie w tym miejscu najczęściej zaczynamy dostrzegać różnice w rónych sposobach podejścia do tematu.

W Waterfall, programiści zbudują w oparciu o wymagania aplikacje, która zostanie przekazana do klienta. Jeśli po drodze czy to architekt, czy programista popełnił błąd, to na tym etapie będzie go trudno odkręcić. Na dodatek żadne zmiany w requirements na tym etapie nie są dopuszczalne.

Co innego w Agile. Tutaj programiści będą skupiać się na małych zadaniach, które są stale dostarczane do klienta. Klient może wcześnie zareagować na niepoprawne decyzje, ale co ważniejsze – również architekt może wprowadzić pewne zmiany do rozwiązania. To podejście jest zdecydowanie bardziej elastyczne. Zasady pracy w zespole Agile są spisane w postaci manifestu:

https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Czy Waterfall jest zawsze zły? Pewnie nie. Dobrze sprawdzi sie tam, gdzie jako twórca oprogramowania doskonale wiesz, co chcesz osiagnąć. Jeśli jednak takiej pewności nie masz, a tak chyba aktualnie jest w większości przypadków, to metoda Agile wydaje sie lepsza.

Istotna jest też budowa zespołów pracujacych nad danym rozwiązaniem. Chcociaż w DevOps uciekamy od podziału zespołów ze względu na umiejętności, to nadal jest możliwe budowanie zespołu w strukturze poziomej „horizontal”. Tak utworzone zespoły mogą wspierać i budować rozwiązania w tylko ściśle określonej technologii – tylko user interface, tylko backend, tylko bazy danych. Wydaje sie jednak, że organizacja w strukturze pionowej „vertical” lepiej sprawdza się w modelu DevOps. Jeden zespół będzie tu odpowiadał za całą pracę jednej wybranej aplikacji od A do Z, od interfejsu użytkownika po backend i bazę danych.

Struktura horizontal będzie częściej wybierana przez organizaję migrującą się z modelu silosów. Do istniejących zespołów można dodać mentorów, którzy będą wpływać na zmianę modelu pracy całego zespołu oraz modyfikować blokujące ten zespół istniejące procesy.

Agile charakteryzuje się również specyficznym zestawem narzędzi, jak np. Kanban, dashboards itp.

Umownie projekty można podzielić na

Green Field – projekty budowane w zupełnie nowym środowisku. Te projekty wydają się prostsze, bo wszystko można zrobić „jak się chce”. Wyzwaniem w takim projekcie może być brak doświadczenia z nowymi rozwiązaniami i brak potwierdzenia sprawności danej technologii w praktyce. Dużo czasu musi być poświęcone na sprawdzenie możliwych opcji i wybór tej najlepszej.

Brown Field – projekty budowane w istniejącym środowisku z istniejącymi innymi aplikacjami, systemami, zależnościami. Ten typ projektu łączy się z często z bieżącym utrzymaniem istniejących aplikacji. Inny problem to opór stawiany przez administratorów istniejącego systemu, których głównym zadaniem jest utrzymanie aplikacji „as is”. Czasami ryzyko związane z modyfikacją istniejącego systemu jest tak duże, że zamiast pracować nad „brown project”, praca zostanie przekształcona w „green project” polegający na zbudowaniu zupełnie nowego systemu.

Oba typy projektów charakteryzują się też różnego rodzaju narzędziami pozwalającymi kontrolować, co się dzieje:

System of record – są to systemy, których głównym zadaniem jest dokładne śledzenie stanu systemu, co może być osiągnięte przez dokładne opisanie wszystkich zmian. Ten typ systemu jest ważniejszy w brown field project, bo tam trzeba pilnować tego co już jest.

System of engagement – jest budowany zazwyczaj z myślą o kliencie, pozwala priorytetyzować pracę z punktu widzenia klienta. Jest on bardziej specyficzny dla DevOps, ale nie wyklucza się z system of record. Systemy te pozwalają też zespołowi śledzić kto i za co jest odpowiedzialny.

W pracy DevOps trzeba (oczywiście) pracować z użytkownikami, których można podzielić na kilka kategorii:

Canary – użytkownicy, którzy bez powiadomienia o tym – pracują z nowymi rozwiązaniami i niestety jeśli coś jest nie tak, to praca tego człowieka jest najbardziej narażona na problemy. Ten typ użytkownika może nie wiedzieć o tym, że coś jest „na nim testowane”, całkiem jak kanarki przebywające z górnikami pod ziemią. Ich rola była brutalna – jeśli ulatniał się gaz, kanarek umierał pierwszy ostrzegając w ten sposób górników

Early adopter – użytkownicy, którzy na ochotnika świadomie zgadzają się na testowanie oprogramowania.

Użytkownicy (standardowi) – uzyskują dostęp do aplikacji na koniec, kiedy dana funkcjonalność jest już przetestowana przez canary i early adopters.

Nie stronimy też od pomiaru postępu projektu poprzez KPI. Pozwalają one śledzić, jak dobrze, albo jak źle jest realizowana dana usługa, albo dane rozwiązanie. Część z KPI będzie powiązana z wartościami wyliczanymi, ale inne mogą pochodzić z subiektywnej oceny użytkownika. Zwykle ocenie podlega:

• prędkość uzyskiwania zmian (liczba release, build itp.),
• efektywność – jak np. liczba serwerów na jednego administratora, wydajność systemu,
• jakość i bezpieczeństwo – ile razy coś się nie udało, np. nie udało się dostarczenie nowej wersji aplikacji, albo aplikacja była niedostępna, ile luk (bug) w oprogramowaniu zostało znalezionych, jakie jest pokrycie kodu przez testy, czy SLA jest osiągnięte, ile czasu zajmuje rozwiązanie incydentu,
• kultura – czy programiści są zadowoleni ze swojej pracy, czy odchodzą z firmy itp.