Всем привет! Сегодня я расскажу как реализовать автоматическую публикацию npm пакета в cicd gitlab, с помощью каких инструментов мы генерируем CHANGELOG файл и обновляем версию package.json. А так же как публикуем изменения в gitlab репозитории.
Я постараюсь дать вам простую инструкцию, расскажу с какими сложностями мы столкнулись и как их решили.
Всем привет! В предыдущем посте мы подробно поговорили про добавление зависимостей в проект и про способы и стратегии их обновления.
В этом посте, как и обещал, я хочу начать обсуждение таких невероятно важных вопросов, как стабильность и безопасность в управлении зависимостями. Надеюсь, мои советы помогут вам контролировать хаос, снижать риски и всегда оставаться на безопасной стороне!
И снова привет! В прошлом посте мы начали рассматривать процесс управления зависимостями в JavaScript, разобрали основы: что такое npm-пакет; как выглядит манифест пакета; в каких полях прописываются зависимости; что такое дерево зависимостей; а также основы семантического версионирования (semver). Если вы пропустили предыдущий пост, то рекомендую начать с него.
Сегодня мы пойдем немного дальше и подробнее рассмотрим, как работает semver, как правильно прописывать диапазоны зависимостей, а также устанавливать и обновлять их.
В этом посте будет описана настройка автоматизации HotFix в Maven проектах с использованием Teamcity.
Чтобы сделать HotFix обычно делается много ручных действий:
1) Создать бранч для релиза, на который вы хотите выкатывать HotFix
2) Исправить ошибку в релизе
3) Измененить bugfix версию в релизном бранче
4) Выкатить тег bugfix версии
Пункты 1,3,4 можно автоматизировать.
Усилия и деньги, вкладываемые в продвижение языка Go, часто приносят пользу и другим разработчикам. В конце прошлого года на сайте gopheracademy была опубликована очень удачная статья о семантическом версионировании. Том самом, которое используется в npm, начинается с домика ^ и все ломает. Под катом спрятан перевод, который поможет вам быстро осмотреть сад граблей версионирования и как сейчас принято им пользоваться. И немного примеров на Go. Передаем слово автору!
Читать полностью »
Невероятно, но факт: с момента релиза JQuery прошло уже почти восемь лет. Веб-разработка сильно изменилась за эти годы, и JQuery менялась вместе с ней. И всё это время наша команда старалась сохранить безупречный баланс между совместимостью с устаревшим кодом и поддержкой самых современных методов веб-разработки.
Один из лучших способов это сделать — семантическое версионирование (semver). В практическом плане, для разработчиков и инструментов разработки, SemVer дает представление о рисках, связанных с переходом на новую версию программного обеспечения. Номера версий представлены в формате MAJOR.MINOR.PATCH, где каждый из трёх компонентов – целое число. Согласно SemVer, если меняется номер MAJOR, это указывает на существенные изменения API, с которыми разработчикам нужно быть очень осторожными.
Эта концепция версионирования обрастает нюансами, если говорить о jQuery, ведь совместимость с браузерами может быть так же важна, как совместимость API. В попытке создать более изящную jQuery, команда выпустила две версии в 2013 году. Первая осталась в линейке 1.* (сегодня это 1.11.1) и обеспечивает совместимость с максимальным количеством браузеров. Вторая версия, начиная с 2.0.0 и до сегодняшней 2.1.1, исключает поддержку ряда браузеров типа IE8 и ниже, чтобы оптимизировать код. Как 1.*, так и 2.* версии jQuery имеют одинаковый публичный API, хотя в их внутренней реализации есть некоторые различия.
Наши будущие релизы будут использовать другую номенклатуру. Как прежде, речь идет о двух разных пакетах. Преемником сегодняшней версии 1.11.1 будет jQuery Compat 3.0. Преемником jQuery 2.1.1 станет jQuery 3.0. Речь идет о двух разных пакетах на npm и Bower, но при этом они будут иметь одинаковую версию, чтобы обозначить тот факт, что их API одинаков.Читать полностью »
