Рубрика «Git»

От 15 и больше: как обеспечить масштабируемость CI - 1

Сейчас публикуется много статей и докладов про конкретные технологии в DevOps: Docker, Kubernetes, Ansible… Я же хочу поговорить про построение процессов и про то, как мы в Wrike за два с половиной года эволюционировали от релизной системы для 15 фронтенд-разработчиков до почти 60-ти, и 2-3 деплоев в день.

Эта статья — про те уроки, которые мы на этом пути решили. Статья основана на моем докладе для DevOps митапа в Wrike Tech Club. Если некогда читать, есть видеозапись презентации. Читатели, добро пожаловать под кат.
Читать полностью »

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.

Git снизу вверх - 1
Изображение из твиттера @girlie_mac

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.
Читать полностью »

Полезное дизайнеру: бесплатные новинки для оптимизации дизайн-процессов. Выпуск 2-й - 1

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

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

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

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

В мире современных веб-технологий все стремительно развивается и меняется. Пару лет назад совершенно нормальным было по запросу клиента рендерить DOM структуру на сервере (например, при помощи PHP) и отдавать уже полностью сформированную страницу. Сейчас все чаще появляются сайты c полным отделением фронтенда (Angular, React, Vue.js...) от бэкенда (некие API эндпоинты), где на фронтенде почти весь контент формируется посредством скриптов, а сервер отдает только данные по запросу. Тут можно было бы упомянуть SSR (Server Side Rendering), но не об этом данное произведение.

В любые времена перед разработчиками и владельцами сайтов стояла непростая задача: доставить контент как можно быстрее, как можно большему количеству клиентов. Одно из самых правильных решений — использовать CDN (Content Delivery Network) для раздачи статичных файлов. В случае с динамическим рендером страниц на сервере мы должны были ограничиваться небольшим списком объектов, которые можно было разместить в CDN: таблицы стилей, файлы скриптов, изображения. Однако, фронтенд, написанный на Angular (React, Vue.js...), статичен целиком, включая индексную страницу. Вот тут и возникает мысль: а почему бы не организовать раздачу через CDN всего фронтенда?

В данной статье пойдет речь о настройке комплексного решения для разработки, контроля версий, автоматической сборки и доставки статического сайта с использованием Gitlab CI, Amazon S3 и Amazon CloudFront. Также речь пойдет о настройке сопутствующих вещей: git, безопасное соединение по протоколу HTTPS, доменная почта, DNS хостинг, бэкенд сервер…

Если вас заинтересовала эта тема, добро пожаловать под кат.
Осторожно! Много скриншотов.
Читать полностью »

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

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

Καλημέρα! (Доброе утро!) В этот раз мы приветствуем вас из греческого города Гераклиона.

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

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.

Так что из себя представляет стильный модный молодёжный Open Source проект в 201* году?

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

Сборка проектов с GitLab CI: один .gitlab-ci.yml для сотни приложений - 1

В статье решается задача управления описанием сборки для большого количества однотипных приложений. Чтобы в проекте заработал GitLab CI, нужно в репозиторий добавить файл .gitlab-ci.yml. Но что, если в сотне репозиториев это файл с одинаковым содержимым? Даже если разложить его по репозиториям один раз, то как его потом изменять? А что, если одного .gitlab-ci.yml мало для сборки — нужны Dockerfile или Dappfile, разные скрипты и структура YAML-файлов для Helm? Как обновлять их?

С чего начать решение задачи по сборке сотни однотипных приложений? Конечно же, посмотреть, можно ли GitLab CI указать использовать .gitlab-ci.yml из другого репозитория или компоновать .gitlab-ci.yml из файлов в других репозиториях…Читать полностью »

Почему нужно перестать использовать Git rebase - 1

После нескольких лет работы с Git я обнаружил, что постепенно стал переходить на всё более сложные Git-команды в рабочем процессе. Вскоре после того как я открыл для себя Git rebase, я тоже быстро внедрил эту команду в повседневные задачи. Те, кто знаком с этой процедурой, знают, насколько это мощный инструмент и какой это соблазн — постоянно им пользоваться. Но вскоре оказалось, что rebase влечёт за собой ряд неочевидных на первый взгляд трудностей. Но прежде чем обсудить их, хочу быстро рассмотреть различия между merge и rebase.

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