Проблема

При разработке с открытым исходным кодом, поскольку разработчики создают параллельные ветви своей собственной работы и объединяют их только после того, как они будут завершены, код не объединенной скопированной ветки будет все больше и больше отличаться от кода исходной основной ветки. Неизбежные расхождения между ветвями могут принести нам множество проблем, а именно: появление ошибок, создание конфликтов слияния или даже полная остановка всей кодовой базы, что делает весь процесс разработки и выпуска программного обеспечения чрезвычайно сложным.

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

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

Что такое CI и почему

Непрерывная интеграция, сокращенно CI, - это стратегия рабочего процесса, которая гарантирует, что все внесенные изменения очень часто объединяются с последней версией основной ветки для всех разработчиков в команде при разработке с открытым исходным кодом. Примером службы, обеспечивающей CI, является GitHub, где каждый разработчик может создать вилку (независимую копию) репозитория, чтобы сделать Pull Request, чтобы попросить объединить их работу (коммиты), просмотреть с комментариями и предложениями или закрыть. . Это не только облегчает жизнь каждого отладки ошибок на более ранних этапах процесса и снижает вероятность возникновения конфликтов слияния (конкурирующих изменений в коде, которые Git не может разрешить), но также улучшает взаимодействие между разработчиками для решения проблем. Здесь мы рекомендуем каждому разработчику чаще интегрировать свой код с основной веткой вместо того, чтобы работать над некоторыми функциями изолированно в течение длительных периодов времени, прежде чем интегрировать их. По сути, это позволяет каждому получать последнюю версию проекта через более частые промежутки времени и, таким образом, снижает вероятность конфликта и время, необходимое для его проверки. Кроме того, всем было бы полезно тестировать каждое небольшое изменение, которое они вносят, чтобы снизить риск ошибки и выявлять потенциальные ошибки на раннем этапе, чтобы они не повлияли на ветки, созданные позже, а также иметь автоматическое тестирование на нескольких платформах для выявлять неожиданные проблемы на платформах, которые не тестировались ранее, и создавать инструкции для конкретных платформ, чтобы увеличить охват тестированием за счет его автоматизации, некоторые из которых можно было бы пропустить, протестировав его вручную, и избавиться от хлопот, связанных с необходимостью тестирования программирования вручную каждый раз, что сортируется при непрерывном развертывании. Каждое изменение отправляет уведомление команде, что позволяет другим разработчикам легко проверять, хотят ли они оставлять комментарии или предложения.

В большинстве случаев Cl практикуется командой одновременно с автоматическим тестированием с использованием выделенного сервера или службы CI. Здесь код будет автоматически построен и протестирован сервером, чтобы проверить, работает ли он и может ли он быть интегрирован с кодом из основной ветки. Затем сервер выдаст вывод с результатами сборки, содержащий всю специфику относительно того, соответствует ли ветвь всем требованиям для интеграции в основную ветвь разработки.

Взгляд на CI / CD

Поскольку CI предоставляет нам все подробности о сборке и тестировании информации для каждого коммита, сделанного в каждой ветке, он помогает нам приспособиться к так называемой непрерывной доставке, практике разработки программного обеспечения таким образом, чтобы вы могли выпустить его в любое время. . Непрерывное развертывание - это расширение непрерывной доставки, которое позволяет с уверенностью внедрять новые разработанные функции в производственную среду. Место, где вы можете бесплатно узнать больше о компакт-дисках, - это GitHub Actions, где есть интерактивные курсы для всех, кто может узнать больше об автоматизации рабочих процессов и тестировании в репозиториях GitHub, из которых вы можете создавать, тестировать и развертывать свой код.

CI на GitHub!

Что делают разработчики для интеграции, так это то, что они вносят изменения локально и отправляют эти изменения в GitHub, известные как коммиты, а роль CI здесь заключается в использовании автоматического тестирования, чтобы определить, будут ли они интегрироваться с последней основной веткой. Во-первых, когда происходит действие (например, когда кто-то открывает запрос на перенос), серверы CI анализируют сообщение, отправленное Webhooks на GitHub, и получают последнюю копию ветки, чтобы создать ее и запустить тесты. Когда это будет сделано, GitHub использует информацию, отправленную обратно с CI-сервера, для отображения информации о проверках в запросе на вытягивание вместе со ссылками, по которым вы можете щелкнуть, чтобы вернуться для получения более подробной информации, как на изображении ниже:

Это дает каждому, независимо от того, является ли он участником, участником или владельцем репозитория, более четкое представление о том, какие изменения могут быть интегрированы в основную ветку, а какие нет (или могут потребоваться дополнительные изменения). При базовой настройке CI / CD мы можем создать систему, которая позволяет развертывать каждую новую фиксацию в основной ветке поставщиком CI, например GitHub Actions. Проверьте это, чтобы узнать больше: https://lab.github.com/github/hello-github-actions!

Почему CI / CD важен для Юлии

Теперь, когда мы все знаем, что непрерывная интеграция - отличный способ для каждого управлять рабочим процессом проекта, в котором задействовано несколько человек, работающих над разными его аспектами одновременно, мы можем поговорить о том, почему это так важно для пакета Джулии. Разработчики. Это особенно удобно, когда дело касается разработки пакетов в экосистеме Julia. Вы можете обнаружить, что CI / CD, возможно, чаще используется разработчиками пакетов Julia по сравнению с другими языками программирования, поскольку Julia имеет очень обширную коллекцию пакетов, и, таким образом, очень сложно управлять, тестировать и просматривать такое большое количество пакеты каждый раз объединяются в экосистему. Помимо того, что большинство пакетов в Julia содержат много кода, который повторно используется и скомпонован, существует больший риск возникновения конфликтов в коде, что может привести к поломке зависимых пакетов или, что еще хуже, всего проекта! Поскольку это такой важный аспект разработки пакетов на языке программирования Julia, разработчики создали ботов, чтобы помочь автоматизировать этот процесс и упростить тестирование. Примером этого является NewPkgEval.jl, который оценивает пакеты, чтобы определить, нарушат ли коммиты Julia саму экосистему или нет. Также существует бот под названием Registrator.jl, который автоматизирует создание запросов на извлечение регистрации для пакетов julia в общий реестр.

Настройка базового сценария CI для репозитория Julia с помощью GitHub Actions

Предполагая, что у вас есть репозиторий с программами Julia, которые вы хотите запустить, вы можете использовать GitHub Actions (как упоминалось ранее), чтобы помочь автоматизировать рабочие процессы CI и развернуть код прямо из GitHub. Сегодня мы не будем вдаваться в подробности, а просто рассмотрим основы, которые помогут вам начать работу. Одним из основных элементов рабочего процесса CI в Julia является действие GitHub под названием setup-julia, которое помогает настроить среду Julia для использования в действиях путем загрузки определенной версии Julia и добавления ее в PATH, чтобы сценарий можно легко запустить, просто позвонив julia.

Если вы перейдете к своему репо, вы должны увидеть вкладку, которая называется «Действия». Нажмите на нее и справа от вас выберите вариант «Настроить рабочий процесс самостоятельно».

При этом создается .yml файл внутри папки workflows внутри папки .github. По умолчанию он называется main.yml, но вы можете изменить его имя, сохранив в конце расширение .yml.

Когда это будет сделано, вы можете создать другую папку с именем src, чтобы разместить в ней все остальное в вашем репо (за исключением новой папки .github). В этом нет необходимости, но это может сделать репо более организованным, особенно если у вас их много.

Теперь вы можете вернуться к редактированию .yml файла. Во-первых, вы можете изменить раздел name: на имя, которое вы хотите назвать своим скриптом. После этого мы можем настроить график развертывания. Замените раздел on: следующим кодом:

on:
  schedule:
  - cron: "*/8 * * * *"

Показанный выше пример позволяет запускать файл каждые 8 ​​минут. Не стесняйтесь менять номер на произвольный. Щелкните здесь, чтобы узнать больше о настройке cron:.

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

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v1
    - uses: julia-actions/setup-julia@v1
      with:
          version: '1.0.4'
    - uses: julia-actions/julia-buildpkg@master
    - run: julia --project file.jl

Значение runs-on здесь указывает ОС, в которой будет выполняться действие. В этом примере использовалось ubuntu-latest. Вы можете изменить бегун на другие операционные системы, такие как Windows и macOS. Для получения дополнительной информации нажмите здесь. Затем вы можете изменить свою версию Julia, заменив '1.0.4' версией, которую вы хотите использовать, например. '1.2.1'. В конце не забудьте изменить file.jl на путь к программе, которая будет запускать этот рабочий процесс. Примером может быть main.jl или src/main.jl, если вы создали src файл.

На Julia на машине, которую мы будем использовать, не будут установлены все пакеты. Итак, добавьте следующие 2 строки в начало вашей программы над using <Package>, чтобы установить нужные нам пакеты (не стесняйтесь пропустить, если пакеты не используются!):

import Pkg
Pkg.add(["package1", "package2", "package3"]) #list of package names

Вот пример:

import Pkg
Pkg.add(["OAuth", "HTTP", "JSON"])
using OAuth, HTTP, JSON

Отличная работа! Мы успешно создали автоматизацию для нашей программы! Не стесняйтесь взглянуть на этот пример, чтобы увидеть, как это делается.

Прежде чем ты уйдешь…

Я просто хочу сказать, что я настоятельно рекомендую всем, кто хочет присоединиться к индустрии разработки программного обеспечения, взглянуть на то, как работает CI / CD, если вы еще этого не сделали. На самом деле это не очень сложная идея: вам просто нужно обдумать ее. Я знаю, как неприятно на первый взгляд звучит необходимость объединять коммиты несколько раз в день, может быть, потому, что вас не беспокоят или вы думаете, что ваше время можно более эффективно использовать для работы над самим проектом, но просто попробуйте : это тоже часть проекта! Это мгновенно превратит рабочую среду в очень продуктивную. Спасибо за чтение!

Использованная литература:

Atlassian. (нет данных). Что такое непрерывная интеграция. Получено с https://www.atlassian.com/continuous-delivery/continuous-integration
CloudBees Inc. (без даты). Непрерывная интеграция: что такое CI? Учебное пособие по тестированию, программному обеспечению и процессам. Получено с https://codeship.com/continuous-integration-essentials
DigitalOcean. (2019, 18 сентября). Введение в непрерывную интеграцию, доставку и развертывание. Получено из https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment
7 причин, по которым вам следует использовать непрерывную интеграцию. (2015, 3 февраля). Получено из https://about.gitlab.com/blog/2015/02/03/7-reasons-why-you-should-be-using-ci/
Непрерывная интеграция. (нет данных). Получено с https://www.oughttworks.com/continuous-integration
Filho, W. (2016, 7 августа). Почему так важна непрерывная интеграция? Получено с https://medium.com/the-making-of-whereby/why-continuous-integration-is-so-important-7bb63ba5dc57 »
Что такое непрерывная интеграция и как извлечь из нее выгоду? (нет данных). Получено из https:// Nevercode.io/blog/what-is-continuous-integration-and-how-to-benefit-from-it/
О конфликтах слияния. (нет данных). Получено из https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-merge-conflicts
Профессиональные руководства: непрерывная интеграция, непрерывная доставка. (нет данных). Получено с https://www.youtube.com/watch?v=xSv_m3KhUO8
Виртуальные среды для бегунов, размещенных на GitHub. (нет данных). Получено из https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners
События, запускающие рабочие процессы. (нет данных). Получено из https://help.github.com/en/actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows
setup-julia Action. (нет данных). Получено с https://github.com/marketplace/actions/setup-julia-environment