Рубрика «ci» - 2

Вот вы сделали что-то новое и крутое, приходит мысль — выложить в опенсорс и опубликовать в npm.

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

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

На самом деле всё это может занять у вас меньше часа. Без знаний DevOps и совершенно бесплатно.

Как заопенсорсить npm-пакет с нормальным деплоем, CI и демо (без потери радости к жизни) - 1Читать полностью »

Держи багОбщаясь с людьми на конференциях и в комментариях к статьям, мы сталкиваемся со следующим возражением: статический анализ сокращает время на нахождение ошибок, но отнимает время у программистов, что нивелирует пользу от его использования и даже наоборот тормозит процесс разработки. Давайте разберём это возражение и покажем, что оно беспочвенно.
Читать полностью »

bugTalking to people at conferences and in comments to articles, we face the following objection: static analysis reduces the time to detect errors, but takes up programmers' time, which negates the benefits of using it and even slows down the development process. Let's get this objection straightened out and try to show that it's groundless.
Читать полностью »

Picture 4

Релиз PVS-Studio 7.04 совпал c релизом плагина Warnings Next Generation 6.0.0 для Jenkins. Как раз в этом релизе Warnings NG Plugin добавил поддержку статического анализатора PVS-Studio. Этот плагин визуализирует данные о предупреждениях компилятора или других инструментов анализа в Jenkins. В этой статье будет подробно рассказано как установить и настроить данный плагин для использования с PVS-Studio, а также описано большинство его возможностей.
Читать полностью »

Мой пятый день с Haiku: давайте портируем немножко программ - 1

TL;DR: Новичок увидел Haiku в первый раз, пробует портировать некоторые программы из мира Linux.

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

Добрый день, в данной статье я покажу как развернуть Symfony 4 приложение на AWS. В официальной документации есть пример подобного процесса, однако мой вариант не столь тривиален, как загрузка zip архива с приложением. На дворе 2019, в моде docker, микросервисная архитектура и CI/CD практики наконец-то начинают входит в инструментарий не только DevOps-инженеров, но и простых смертных разработчиков. Чтобы статья была более интересна, я добавил фронт на React.JS, для охвата потребностей большей массы людей, если ваше приложение не использует Encore — не беда, я укажу как изменить Docker-файл для вас, поддержка React.JS тут влияет только на него. Кому будет интересен данный туториал? В первую очередь он направлен на PHP-разработчиков, желающих изменить свою практику деплоя — отойти от привычных канонов и воспользоваться docker для паковки своего приложения и выкладки образа. Но можно пойти чуть глубже, и дальнейшее повествование будет направлено на автоматический деплой приложения из Git'а посредством CI/CD платформы (будет использован CircleCI, но если интересует конфиг Gitlab'а, пишите в комментариях, я приложу). По сути, тут абсолютно не важно React/PHP ли у вас приложение или, скажем, на .NET Core, данная часть будет интересна разработчикам для получения навыков автоматизации деплоя в целом. Исходный код доступен в github-репозитории, ссылка в конце статьи. Ну что же, поехали!
Читать полностью »

На РИТ++ Никита Соболев (sobolevn) выступил, как он сам назвал это, с проповедью на тему качества кода и процессов в компании. Особо впечатлительных просим налить себе ромашкового чаю, но отойти от экранов не предлагаем. Вы можете не соглашаться ни с одним из тезисов, настаивать, что трёп о сериалах — залог здоровой атмосферы в коллективе, и утверждать, что вам не нужны строгие рамки линтера и CI, чтобы писать хороший код. Но если вы хоть раз винили окружающих в неудачах на работе, вам стоит прочитать или посмотреть рассказ Никиты.

Работали ли вы когда-нибудь на плохой работе?

Я работал и долго. Моя компания была ужасна. Все было очень плохо, за что ни возьмись — все из рук вон. У нас были отвратительные процессы, ненавистные клиенты и неумелые разработчики. С этим ничего нельзя было поделать. Когда все так плохо, просто не знаешь, за что взяться, с чего начать. Чувствуешь себя жалким винтиком, который не может ни на что влиять.

Blameless environment: никто не должен писать качественный код - 1

Когда я говорю, все плохо, я имею в виду, что у нас был:

  • плохой код — никто не думал о качестве кода, никто не мог даже сформулировать, что такое качество кода.
  • плохие процессы.
  • мы не могли нормально общаться,
  • мы не делали то, что хотел клиент.

Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.Читать полностью »

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

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

Автоматизируй это! Как мы улучшали интеграционное тестирование - 1

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

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

Эволюция CI в команде мобильной разработки - 1

Написав код, вы должны убедиться, что он:

  1. Работает.
  2. Ничего не ломает, в том числе код, который написали ваши коллеги.

Если оба условия выполняются, то вы на пути к успеху. Чтобы легко проверять эти условия и не сворачивать с выгодного пути, придумали Continuous Integration.

CI — это рабочий процесс, при котором вы как можно чаще интегрируете свой код в общий код продукта. И не просто интегрируете, а еще и постоянно проверяете, что все работает. Так как проверять нужно много и часто, стоит задуматься об автоматизации. Можно все проверять на ручной тяге, но не стоит, и вот почему.
Читать полностью »

Картинка для привлечения внимания

Поддержка SAST для JavaScript

Благодаря Static Application Security Testing (SAST) GitLab сканирует код и помогает обнаружить потенциальные уязвимости еще в конвейере. В релизе 11.8 мы добавляем в список поддерживаемых SAST языков JavaScript, на основе существующей поддержки node.js. Теперь можно просканировать любые файлы JavaScript, статические скрипты и HTML. Важной практикой в DevSecOps сейчас является сканирование изменений при каждом коммите, и с этим обновлением SAST мы покрываем один из самых популярных веб-языков, помогая пользователям раньше обнаруживать риски в коде на JavaScript.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js