Публикувано на: 27 юли, 2023*Текстът е предоставен от 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 …
Hybrid
София
- docker pull ghcr.io/magik3a/dev.bg.blazorapp1:latest
- 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 процес!
