Рубрика «continuous integration»

в 13:00, , рубрики: ci, continuous integration, legacy-код, ruvds_перевод, анализ кода, легаси код, рефакторинг, санитайзеры

Итак, вы унаследовали старую кодовую базу на C++. Что дальше? - 1


Вы жили своей обычной жизнью, но внезапно, всё поменялось. Возможно, вы устроились в новое место, сменили команду или из вашей компании ушёл сотрудник.

Теперь вы отвечаете за кодовую базу на C++. Она большая, сложная и своеобразная; достаточно слишком долго на неё посмотреть, как она начинает разваливаться разными интересными способами. Иными словами, это легаси.

Но баги всё равно как-то нужно устранять, а ещё добавлять новые фичи. То есть вам нельзя просто закрыть на неё глаза или что ещё лучше, взорвать её динамитом. Она важна для компании. По крайней мере, для тех, кто платит вам зарплату. А значит, важна для вас.

И что делать теперь?

Не волнуйтесь, у меня такое случалось очень много раз и в разных компаниях (кто-то язвительный может спросить: а разве кодовые базы на C++ бывают какими-то другими?), выход есть, он не особо сложен и поможет вам действительно устранять баги, добавлять фичи, а то и когда-нибудь переписать её.

В этой статье я расскажу о том, что оказалось полезным для меня, и о том, чего стоит всячески избегать.
Читать полностью »

в 15:23, , рубрики: ci/cd, continuous delivery, continuous integration, devops, docker, Git, gitlab, Google Cloud Platform, google kubernetes engine, javascript, kubernetes, node.js, React, управление разработкой

Развёртывание в Kubernetes из GitLab

Развёртывание в Kubernetes из GitLab

Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.

А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.

Желательны но необязательны базовые знания

  • Docker;
  • Kubernetes;
  • Git;
  • Node.js;
  • React;
  • Bash.

В дальнейшем мы сделаем следующее.

  • 🧱 Познакомимся c нашим приложением, обсудим из чего оно состоит.
  • 🐳 Докеризуем наше приложение.
  • ☸️ Развернём наше приложение в Kubernetes локально на Docker Desktop.
  • ☁️ Обсудим особенности GCP и как нужно изменить наше приложение, а затем ещё раз развернём наше приложение в Kubernetes но уже в GCP.
  • 🦊 Завершим наш туториал созданием конвейера для развертывания приложения в GCP при помощи GitLab.

Разные этапы от докеризации до Kubernetes на Google Cloud Platform

Читать полностью »

в 8:57, , рубрики: bitbucket, continuous integration, devops, Jenkins, werf, Блог компании Флант, системы сборки

Настраиваем Continuous Integration для Jenkins и Bitbucket с werf - 1

Утилита werf создана так, чтобы её было легко интегрировать с любыми CI/CD-системами. Подробнее об этом процессе в общем случае читайте в эпилоге этой статьи, но основное её содержимое — практический пример по организации CI в Jenkins и Bitbucket.

Подразумевается, что в результате наших действий мы ожидаем получить следующее:

  1. Shared Library для Jenkins, чтобы все сценарии CI хранились в одном месте и их можно было править единым коммитом.
  2. Интеграцию Jenkins с Bitbucket, чтобы запускать CI по коммиту в определенные ветки или по созданию тега.

Поехали!Читать полностью »

в 14:55, , рубрики: continuous integration, билд-светофор, лампа, светофор, Тестирование IT-систем
Ещё один Билд-светофор в офисе - 1

В своё время меня очень вдохновила идея создания билд-светоформа, описанного моими коллегами на Хабре здесьЧитать полностью »

в 22:04, , рубрики: Argo, argocd, ci/cd, continuous delivery, continuous integration, devops, Git, git-crypt, gitops, kubernetes, qbec, системное администрирование

Разбираемся с Custom Tooling в Argo CD - 1

Спустя некоторое время после написания первой статьи, где я ловко управлялся с jsonnet и гитлабом, я понял что пайплайны это конечно хорошо, но излишне сложно и неудобно.

В большинстве случаев требуется типовая задача: "сгенерировать YAML и положить его в Kubernetes". Собственно, с чем Argo CD замечательно и справляется.

Argo CD позволяет подключить Git-репозиторий и синкать его состояние в Kubernetes. По умолчанию есть поддержка нескольких видов приложений: Kustomize, Helm чарты, Ksonnet, голый Jsonnet или просто директории с YAML/JSON манифестами.

Большинству пользователей этого набора будет достаточно, но не всем. Для того чтобы удовлетворить потребности всех и каждого в Argo CD имеется возможность использовать custom tooling.

В первую очередь интересует возможность добавления поддержки qbec и git-crypt, которые с полна были рассмотренны в предыдущей статье.

Читать полностью »

в 13:49, , рубрики: bamboo, bash, bash scripting, ci/cd, continuous integration, devops, horizontal scaling, lerna, monorepo, scalability, shell, shell scripting, yarn workspaces

Lerna

Дано

  1. Монорепозиторий на базе Lerna и Yarn workspaces.
  2. Десяток приложений, и десятки общих пакетов на TypeScript, Angular, NodeJS.
  3. Высокое покрытие тестами самых разных мастей (модульные, интеграционные, e2e).
  4. и Atlassian Bamboo CI/CD.

Задача

Ускорить имеющиеся пайплайны в 2 раза (до, хотя бы, получаса). Попутно повысив стабильность до 90%.

Забегая вперед, скажу что требуемые показатели были достигнуты.

Читать полностью »

в 8:29, , рубрики: continuous integration, devops, Git, werf, Блог компании Флант, системы сборки

Content-based tagging в сборщике werf: зачем и как это работает? - 1

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. В релизе v1.1 была представлена новая возможность в сборщике образов: тегирование образов по содержимому или content-based tagging. До сих пор типичная схема тегирования в werf предполагала тегирование Docker-образов по Git-тегу, Git-ветке или Git-коммиту. Но у всех этих схем есть недостатки, которые полностью решаются новой стратегией тегирования. Подробности о ней и чем она так хороша — под катом.Читать полностью »

в 11:09, , рубрики: ci/cd, continuous deployment, continuous integration, Gamedev, github, nexus, pipeline, teamcity, unity, Блог компании Pixonic, геймдев, мобильнве игры, непрерывная интеграция, разработка игр, разработка мобильных приложений, системы сборки

Непрерывная интеграция в Unity: как сократить время сборок и сэкономить ресурсы + пайплайн в подарок - 1

Всем привет, на связи Александр Панов, техлид из Pixonic. В компании я отвечаю за межпроектные решения и околопроектную периферию и сегодня хочу поделиться своим опытом и наработками.

Платформы непрерывной разработки и интеграции, или CI/CD, сейчас используются повсеместно в тех отраслях, где решающую роль играет итеративность и отлаженность технических процессов. В этой статье речь пойдёт о CI/CD для реализации наших Unity-проектов для мобильной геймдев-разработки: с какими проблемами мы столкнулись, как их удалось решить, каких улучшений мы добились и как прописан наш пайплайн сборок билдов.

Сразу договоримся, что в качестве сервера CI мы используем TeamCity от JetBrains, в качестве хранилища Git-репозиториев ― GitHub, для хранения артефактов сборки ― Nexus.
Читать полностью »

в 17:15, , рубрики: continuous integration, devops, gitlab, jsonnet, Программирование

В продолжение предыдущей статьи про инструменты деплоя в Kubernetes, хочу рассказать вам про то как можно использовать Jsonnet для упрощения описания джоб в вашем .gitlab-ci.yml

Как описать 100 Gitlab джоб в 100 строк - 1

Дано

Есть монорепа, в которой:

  • 10 Dockerfiles
  • 30 описанных деплоев
  • 3 окружения: devel, staging и production

Задача

Настроить пайплайн:

  • Сборка Docker-образов должна производиться по добавлении git-тэга с версией.
  • Каждая операция деплоя должна выполняться при пуше в ветку окружения и только по изменении файлов в конкретной директории
  • В каждом окружении установлен свой gitlab-runner с отдельным тэгом, который выполняет деплой только в своём окружении.
  • Не все приложения должны быть задеплоены в каждое из окружений, мы должны описать пайплайн так, чтобы иметь возможность делать исключения.
  • Некоторые деплойменты используют git submodule и должны запускаться с установленной переменной GIT_SUBMODULE_STRATEGY=normal

Как видите, описать это всё может показаться настоящим адом, но мы не отчаиваемся и вооружившись Jsonnet сделаем это легко и непринуждённо.

Читать полностью »

в 6:11, , рубрики: continuous delivery, continuous integration, devops, Git, git-crypt, gitlab, Hugo, kaniko, kubernetes, qbec, непрерывная интеграция, системное администрирование, системы сборки, Системы управления версиями

Пробуем новые инструменты для сборки и автоматизации деплоя в Kubernetes - 1

Привет! За последнее время вышло много классных инструментов автоматизации как для сборки Docker-образов так и для деплоя в Kubernetes. В связи с этим решил поиграться с гитлабом, как следует изучить его возможности и, конечно же, настроить пайплайн.

Вдохновлением для этой работы стал сайт kubernetes.io, который генерируется из исходных кодов автоматически, а на каждый присланный пул реквест робот автоматически генерирует preview-версию сайта с вашими изменениеми и предоставляет ссылку для просмотра.

Я постарался выстроить подобный процесс с нуля, но целиком построенный на Gitlab CI и свободных инструментах, которые я привык использовать для деплоя приложений в Kubernetes. Сегодня я, наконец, расскажу вам о них подробнее.

В статье будут рассмотрены такие инструменты как:
Hugo, QBEC, Kaniko, Git-crypt и GitLab CI с созданием динамических окружений.

Читать полностью »

123...10...19
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js