Azure deployment

Kopiowanie plików z lokalnej maszyny na serwer choć proste i łatwe i szybkie, nie jest tym jak powinno się umieszczać binarki na produkcji. Muszę się przyznać, że ja tak właśnie robiłem, ale zabrałem się wreszcie za siebie i mam postanowienie poprawy.
Otóż otóż. Chciałem być trendi i chciałem skorzystać z „darmowych” rozwiązań, travis ci czy appveyor i dupa, nie umiem. Wreszcie pomyślałem skoro postawiłem aplikację na azure, to czemu nie skorzystać z azure aby zrobić deploy. Działa lepiej niż myślałem.

Start

Krok pierwszy: Włączamy Visual Studio, ja aktualnie korzystam z VS2017 także to właśnie włączę, a potem klasycznie:
File New Project
Web project
ASP .NET Web Application (.NET Framework)
Podaję nazwę „Continous”
Framework 4.6.2
Projekt MVC bez użytkowników
i wreszcie OK.

PRODUCTION

Teraz mała zmianę w kodzie i wrzucamy na produkcje. Na stronie głównej (home/index.cshtml) wrzucę informację o tym że jesteśmy na produkcji:
<h1>Production</h1>
git add -A
git commit -m”production” i tyle.

Azure po raz pierwszy

Teraz pora na azure:
Klik na https://portal.azure.com,
all resources
tworze nowy zasób
wybieram web app
następnie nazwa „continous”
nowa grupa (później prościej będzie posprzątać)
wyłączyłem app insight
nie wybrałem opcji z automatyzacją
klikam create
czekam chwilę .

Na scenę wchodzi Bitbucket

Po chwili znowu:
Klikam na azure w link „all reasources
wybieram mój projekt „continous
następnie w sekcji deployment przewijam do deployment options i klik.

Pojawia się nowy ekran z opcjami do wyboru:
Choose source – wybieram bitbucket. Ponieważ wcześniej nie upoważniłem azure do dostępu do bitbucketa robię to teraz.
Wreszcie poniżej wybieram projekt, jako że trochę się tego uzbierało przewijam aż znajdę swój „continous” – klik.
Kolejna opcja to wybór brancha, póki co posiadam jeden: „master”, więc nie poszaleje – klik.
Na koniec już – nie wybieram opcji automatyzacji i ostatni klik w OK.

Jeszcze raz szybki klik w deployment options, nie pojawiało się nic? W takim razie klik w sync – potwierdzam że chce zaciągnąć kod i jest! Coś się buduje – czekam.

Pierwsze dziecko

Klikam overview, potem w url który jest taki: (projekt nie jest dostępny, za mało cebul w kieszeni) http://continous.azurewebsites.net i Jeeeeeeeeeeeeeeeeeeeeeeeeest! Z dumnie podniesionym i prezentowanym na zielono PRODUCTION.

Po mi to production było?

Chce jeszcze jedno

Zróbmy sobie branch „develop”. I przełączmy się na visual studio. Od razu uderzamy do indeksu (home/index.cshtml) i zmieniamy z zielonego production, na czerwone develop.
Potem git add/commit/push i jest. Wracam na mastera i robię jeszcze raz, ale brancha nazwę „UAT” i na żółto wrzucę taki sam opis w indeks (home/index.cshtml). A potem też tego brancha wrzucę na serwer. Teraz mamy trzy wersje kodu na repo, ale jak je testować? Część może odpowiedzieć, że na produkcji, a część puknie się w czoło. Na szczęście azure ma deplyment sloty. Działa to tak, że tworzymy poddomenę(nie wiem jak to poprawnie nazwać) dla naszej aplikacji i tam możemy wrzucić inny kawałek kodu, np. nasze brancze develop czy uat.

Deployment slot

Robi się tak:
W sekcji deployment klikamy na deployment slots
Następnie add slot, podajemy nazwę (production jest zajęta), ja zacznę od develop.
Póki co moje środowisko nie jest w żaden sposób skonfigurowane więc nie mam czego skopiować.
OK.
Wróciło mnie na główną, klikam ponownie deployment slots, czekam i klikam na develop-continous, tak się nazywa mój pierwszy slot. Widok się przełącza i wygląda jak by znowu mnie wrzuciło na stronę domową głównego projektu, ale po chwili zauważam że jestem na projekcie develop-continous. Działa to trochę jak podprojekt. Znów wybieram opcje deploment options i idę tak jak poprzednio, z tą różnicą że branch z którego chce robić deploy to nie master a develop. (Co ciekawe, do slotów można deplojować z innych źródeł, czyli np. master idzie z bitbucket, a develop idzie z dropboxa).

Jeszcze jeden i jeszcze raz

Powtarzam czynność dla UAT, zmieniając odpowiednio nazwę oraz branch. Do tego czasu slot z developem powinien być już gotowy, przechodzę więc tam klikam na overview i klik na link (http://continous-develop.azurewebsites.net/) zwróćcie uwagę na nazwę slota w url i widzę (po chwili) stronę z czerwonym napisem DEVELOP. Mogę spokojnie wrócić na stronę główną i obejrzeć napis production.

Rozwój na aplikację rwie się do przodu

Co dalej? Otóż wróćmy do brancha develop i zmieńmy napis na EPIC DEVELOP, teraz szybki powrót do azura i prawie udało się zobaczyć jak wrzutka się kompiluje. Ale prawie. W związku z tym F5 w przeglądarce na stronie z developem i widzę epickość.whoa! Lubię to. Działa i proste.

Swap

Ale lepsze jest to. Gdy okazuje się że epic jest production ready wystarczy zrobić podmiankę.
W azure znajduje główny projekt, przechodzę do deployment options.
Klikam swap (czujecie co się święci?) i wybieram production <-> develop (tak pomijam wersję uat specjalnie, mam jaja!)
OK.
Po chwili odświeżam w przeglądarce główny projekt i developerski. Yep! Swap zrobił swoje i zamienił się miejscami. Na produkcyjnym url mam epickość, a na developie mam starą produkcję. Zawsze mogę się wycofać.

Moar

Ale teraz, chce jeszcze więcej epickości. Wracam do visual studio, tutaj nadal jestem na branchu develop. Dodaje więc jeszcze więcej epickości do swojego kodu. Git add-commit-push! Zbudowało się. Yeah. Tylko teraz który z urli będzie posiadać jeszcze bardziej epicki kod? Klikam oba i co? Na master urlu kod epicki, a na develop urlu jeszcze bardziej. Jak ja to lubię. Smutny UAT w ciszy lekko sobie szlocha.

Finito

I tyle odemnie. Może nie jest to odkrycie na miarę nobla czy coś, ale mi leniwemu i staremu człowiekowi bardzo ułatwia to robotę. B A R D Z O!

Youtube

Jeśli gdzieś się zgubiłeś, poniżej nagranie video z całej akcji, plus opis słowny i moja twarz mówiąca słowa.

One thought on “Azure deployment

  1. Pingback: dotnetomaniak.pl

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *