+
Вход

Въведи своя e-mail и парола за вход, ако вече имаш създаден профил в DEV.BG/Jobs

Забравена парола?
+
Създай своя профил в DEV.BG/Jobs

За да потвърдите, че не сте робот, моля отговорете на въпроса, като попълните празното поле:

77+23 =
+
Забравена парола

Въведи своя e-mail и ще ти изпратим твоята парола

Безплатна DevOps автоматизация от край до край – част 2

*Текстът е предоставен от VSG Bulgaria

След като в първата част навлязохме в света на DevOps и автоматизацията, сега е време да продължим нашия път и да влезем още по-дълбоко в механизмите на автоматизацията.

Съсредоточаваме се върху добавянето на версия на проектите, работата с deployment среди и секретни променливи, използването на Docker и Github Actions, както и автоматично генериране на файл с промени и релийзи.

Линк към първата част: https://dev.bg/digest/vsg-bulgaria-devops-automation-dc03/

Добавяне на версия на проектите:

За да поддържаме последователност и организация в нашите проекти, е изключително важно да имаме управление на версиите. Първата стъпка към това е създаването на файл VERSION, който съдържа текущата версия на нашия проект. При билдване, този файл ни позволява да сменим версията на всички .NET проекти в процеса. Това ефективно улеснява проследяването и управлението на различните версии.

За да добавим версия на всички проекти в нашето репозитори, може да създадем един файл VERSION в главната директория, в който ще добавим примерна версия като 1.0.42 (пример).

След което в нашите процеси в папката „.github/workflows“ редактираме файловете за билдване, като добавим следния код: (пример).

Една от добрите практики, когато вече имаме версия, е да добавим по лесен начин тестер, който да достигне версията. При АПИ проекти, може да се направи рекуест, който да я връща, а при фронт енд или мобилни проекти, може да се добави в ъгъла на приложението или специална страница „за приложението“.

Deployment среди и секретни променливи:

Следващата стъпка е да използваме GitHub environments и environment secrets за управление на deployment среди и секретни променливи. Това ни позволява да изолираме различни среди за разработка, тестване и продукция (production), както и да поддържаме безопасността на нашите секретни променливи без риск от изтичане.

Първо влизаме в GitHub, настройки на репозиторито и след това е средата. Добавяме нова среда с име „Azure“ като в нея може да добавим нова секретна променлива с примерно име „BlazorApp1_DeployToken“.

След това отиваме във файла, който управлява процеса за деплой в „Azure“ и добавяме средата и секретната променлива.

По този начин, може да създадем различни среди с различни секретни или обикновени променливи, които ще са видими само за автоматизираните процеси и само за администратори на проекта.

Докер и разпространение:

Чудесно! Вече имаме версии, имаме среди със секретни променливи, време е да се заемем с Docker, мощна платформа, която позволява създаване, разпространение и изпълнение на приложения в контейнеризирана среда.

Използването на Docker в процеса на разработка носи множество предимства. Той позволява приложенията да бъдат пакетирани с всичките си зависимости в стандартен формат, който може да бъде разпространяван и използван върху всякакви платформи и среди, без да е необходимо да се правят специални настройки.

Първата стъпка, както винаги, е да добавим нов файл в „.github/workflows“ с примерно име „blazorapp1-docker-github.yml“ (пример).

Последната стъпка е да добавим нов „Dockerfile“ в папката „src /BlazorApp1“ (пример).

Веднъж добавили всичко, ще видите вашия докер имидж (Docker image) в репозиторито и всеки тестер или програмист може да изпълни командата и да стартира приложението на локалния си компютър, без да има нужда от абсолютно нищо друго, освен Docker!

Днес те питаме…

Как предпочиташ да комуникираш с колегите си на работа?
Loading ... Loading …
  1. docker pull ghcr.io/magik3a/dev.bg.blazorapp1:latest
  2. docker run ghcr.io/magik3a/dev.bg.blazorapp1:latest

Веднъж изтеглили и стартирали докера (Docker), може да отворим https://localhost:7018 и да видим, че всичко работи локално на нашия компютър.

Линк към докер имиджа в примера тук.

Използването на Docker осигурява консистентност между средите за разработка, тестване и продукция. Това означава, че ако приложението работи на локалната ви машина в Docker контейнер, то е много вероятно да работи по същия начин в продукционната среда (production).

Автоматични релийзи и генериране на файл с промени (Changelog):

Създаването на автоматични релийзи и документиране на промените, извършени в проекта, са критични аспекти от процеса на разработка на софтуер. В този контекст, GitHub Actions предоставя ефективни инструменти, които могат значително да улеснят и автоматизират тези задачи.

Първо ще създадем в “Github” нова задача с примерно заглавие: Create release drafter (пример).

След това в папката „.github“ добавяме нов файл с име „release-drafter.yml“ , който ще използваме за темплейт на описанието в нашия релийз (пример).

Последно добавяме нов файл в „.github/workflows“ с примерно име „release-dist.yml“ (пример).

Когато решим че сме готови за релийз и кодът ни е достатъчно добър, отиваме в екшъните (actions) в “Github” и стартираме ръчно „Release Distribution Packages“ (може да го направим и автоматично, когато нов код влезе в главния бранч).

И финалният ни релийз изглежда така:

Линк към релийза.

Като цяло, автоматичното създаване на релийзи и генерирането на файл с промените са важна част от DevOps практиките и са съществена част от ефективния и бърз процес на доставка на софтуер.

Добра работа!

С усвояването на практиките, описани в тази статия, вече сте направили значителен напредък в създаването на автоматизирана DevOps среда. Използването на Docker, GitHub Actions и редица други инструменти ви позволява да подобрите процесите на разработка, тестване и разпространение на вашия софтуер.

Създаването на консистентни, изолирани и повтаряеми среди с Docker е мощна стратегия за подобряване на качеството и надеждността на вашите проекти. Автоматичното създаване на релийзи и генериране на changelog подобрява прозрачността и комуникацията вътре в екипа, като и при общуване с клиентите.

Всички тези стратегии и инструменти водят до един и същи край – постигане на висока ефективност, подобрено качество на кода, сигурност и бързина на доставка.

Но, ако има нещо, което трябва да се припомни, то е, че DevOps е постоянен процес на усъвършенстване и адаптиране. Трябва да продължаваме да търсим нови и подобрени методи за автоматизация и оптимизация на нашите процеси. Без значение дали сте нов в DevOps или сте опитен професионалист, винаги има място за обучение и подобрение.

В следващата част на поредицата ще навлезем в малко по сложни неща (и за съжаление някои от тях платени), като създаване на ботове, интеграции с Microsoft Teams и Skype, както и дистрибутиране в Kubernetes и Chaos engineering.

Благодаря ви за времето и че стигнахте до края на статията! Браво за свършената работа и продължавайте да се стремите към ефективност и качество във всяка една стъпка от вашия DevOps процес!

Линк към проекта.