DevOps przez ostatnie lata zyskał sporo na popularności. Automatyczne zbudowanie paczki i wgranie jej na serwer brzmi naprawdę świetnie. Wystarczy umieścić nową funkcjonalność w repozytorium, by za kilka minut była ona już dostępna na serwerze. W tym wpisie zapoznamy się z Azure Devops i skonfigurujemy prosty pipeline automatycznego wdrożenia nowych funkcjonalności na serwer. Dla przykładu posłuży nam aplikacja PairMatching
.
Konfiguracja github
Na platformie github w pierwszej kolejności z marketplace musimy zainstalować Azure Pipelines. Po zainstalowaniu przechodzimy do konfiguracji, wybieramy repozytorium, z którego chcemy budować paczki. Wybieramy subskrypcje azure, tworzymy nowy projekt i przechodzimy do portalu Azure DevOps.
Jeżeli przy tworzeniu nowego projektu pojawi się komunikat „The project visibility specified is invalid. Public projects are not allowed in this organization.” Należy zalogować się w Azure DevOps , tam utworzyć nowy publiczny projekt i wróćcie do kreatora.
Automatyczny build – plik yml
W Azure DevOps dla automatycznego builda możemy utworzyć plik yml. Można zrobić to przez kreator lub dodać plik bezpośrednio do repozytorium a następnie w sekcji pipeline builds wskazać plik yml.
Przykładowy plik yml dla projektu .Net Core, w którym projekt zostanie zbudowany oraz zostanie utworzony artefakt z nową wersją aplikacji wygląda następująco:
# ASP.NET Core
# Build ASP.NET Core projects targeting .NET Core.
pool:
vmImage: 'Ubuntu 16.04'
steps:
- script: dotnet publish -c Release --output ./PublishApp
- task: PublishBuildArtifacts@1
inputs:
pathtoPublish: '$(System.DefaultWorkingDirectory)/PairMatching/PublishApp'
artifactName: WebApp
Konfiguracja maszyny wirtualnej azure [ubuntu]
Przechodzimy do sekcji Pipeline następnie Deployment groups i dodajemy nowy grupę. Wybieramy system operacyjny, w moim przypadku jest to Linux. Kopiujemy wygenerowane polecenie.
Podłączamy się do serwera Ubuntu prze ssh i wykonujemy skopiowane polecenie. Po chwili serwer powinien byś skonfigurowany z Azure DevOps.
Automatyczny deploy
W sekcji Pipelines przechodzimy do Releases, tworzymy nowy pipleine. W stages wybieramy empty job, przechodzimy do dodania tasków. Zmieniamy Agent job na Deployment group job. Następnie dodajemy nowe zadanie Bash Script w trybie Inline. W polu script wpisałem komendy do wykonania po stronie serwera. Poniższy skrypt, który przekopiuje pliki artefaktu w docelowe miejsce, na koniec ponownie uruchomi usługę aplikacji. Dodałem również zmienią Upass, w której przechowywane jest hasło użytkownika z uprawnieniami administratora (mało eleganckie rozważanie w przyszłości planuje to zmienić).
Treść pola skrypt
echo "stop dotnet-core-app.service" echo $Upass | sudo -S systemctl stop dotnet-core-app.service echo "copy files" 'cp' -rf $(System.DefaultWorkingDirectory)/_$(Build.DefinitionName)/WebApp/* /home/ubuntu/PairMatching/PairMatching/ echo "start dotnet-core-app.service" echo $Upass | sudo -S systemctl start dotnet-core-app.service
Przechodzimy do pipleline i dodajemy artefakt oraz uruchamiamy trigger, który uruchomi deploy gdy pojawi się nowy artefakt. Zmiany automatycznie zostaną wdrożone na serwer.
a co z bazą danych?
W projekcie PairMatching znajduje się baza danych SQLite, niestety nie udało mi się jeszcze znaleźć sposobu na automatyczne podgrywanie zmian w bazie danych na serwer. Problem polega na tym, że nie ma za bardzo możliwości porównania projektu bazy danych z bazą na serwerze w czasie wykonywania builda. Można oczywiście pobrać całe repozytorium na serwer i tam odpalić build i porównanie bazy jednak takie rozwiązanie jest mało eleganckie. Może Wam udało się rozwiązać ten problem dajcie znać w komentarzach.