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:

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"

  1	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:

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:

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.

DevOps – może mieć różne definicje, bo jest różnie rozumiany. Zwykle rozumiemy przez niego połączenie pracy człowieka, procesów i produktów, które umożliwiają dostarczanie wartości klientowi w procesie Continous Delivery. Czasami łatwiej jest powiedzieć, co nie jest DevOps. Przykładami takich czynności są tworzenie dokumentacji, modyfikacja ustawień firewall. Te czynności nie przynoszą klientowi bezpośrednich korzyści. Co innego utworzenie nowej funkcjonalności w aplikacji.

Observe, Orient, Decide, Act – pętla OODA – każdorazowo, przy każdej iteracji należy obserwować skutki poprzednich zmian, określać czy są one pożądane, decydować o kolejnych krokach i wykonywać je. Dzięki częstej ocenie pracy, można uniknąć błądzenia po niepoprawnych rozwiązaniach, na bieżąco korygować błędy i w efekcie szybciej dostarczyć wyniki dla klienta.

Continous Integration – proces ma na celu upewnienie się, że wprowadzone zmiany działają z innymi zmianami, wykonywanymi przez innych programistów, w tym również że są zgodne z wymogami security itp. Programista wysyłając swój kod może powodować konflikty, które powinny być szybko wykryte. Łatwiej je wykrywać, gdy często są wykonywane testy. Programista wykonuje małą zmianę, oprogramowanie jest budowane i testowane w automatyczny sposób.

Continous Delivery – Jest to implementacja logiki „Fail Fast” – jeśli coś ma się nie udać, albo ma nie dać wartości dla klienta, to lepiej jeśli zostanie to wykryte wcześniej. Zmiany wykonane w rozwiązaniu, dostarczamy klientowi tak szybko jak się da. Z jednej strony, klient nie musi długo czekać na rezultaty, z drugiej strony może szybko zareagować, jeśli coś jest nie tak.

Version Control – utrzymywanie jednego prawdziwego miejsca gdzie utrzymywany jest kod aplikacji. Ten kod może być podzielony na różne etapy pracy (branch), ale jeśli szukasz odpowiedniego miejsca skąd można pobrać kod źródłowy – idziesz tam. Version Control wspiera zachowanie historii wszystkich zmian, możliwość przeglądu wysyłanego kodu itp.

Agile – metodologia dzieląca pracę na mniejsze fragmenty „sprinty”, co pozwala na dopasowanie pracy do możliwości zespołu i śledzenie postępu

Monitoring – pozwala na zbieranie i analizę danych w Azure, która nastęnie może być wykorzystana do podejmowania dalszych decyzji w rozwoju oprogramowania, a operacyjnie pomaga w utrzymaniu dostępności usługi.

Cloud – umieszczanie usług w chmurze: prywatnej, publicznej lub hybrydowej.

IaaC – tworzenie i zarządzanie infrastruktury za pomocą kodu

Microservice – podział aplikacji na wiele małych usług, z których każda jest odpowiedzialna za niewielki fragment funkcjonalności. Jest to przeciwieństwo architektury monolitycznej

Containers – technika uruchamiania aplikacji wyizolowanej z systemu operacyjnego do postaci tzw. kontenera. Kontener powołuje się na konfigurację utworzoną wcześniej w innym kontenerze i dodaje do niego swoją warstwę funkcjonalności, np. funkcjonalności specyficznej aplikacji.

Migracja w stronę DevOps wymaga stworzenia wyspecjalizowanych zespołów, dopasowania procesów, stąd właśnie taka a nie inna definicja tego czym jest DevOps. Konflikty z istniejącymi procesami są jednak nieuniknione.

DevOps team musi definiować swoje cele, a do tego są potrzebne metryki: ile czasu spędza się na naprawie błędów, ile czasu spędza się na wykonaniu powtarzalnych czynności, ile czasu trwa stworzenie określonej funkcjonalności.