Project slug что это
Project slug что это
Для работы со слагами в Laravel нам понадобится простой и удобный пакет cviebrock/eloquent-sluggable. Устанавливаем его для Ларавел 5.5:
Если вы захотите изменить какие-либо дефолтные настройки, то создайте файл конфигурации:
После этой команды будет создан новый конфиг: config/sluggable.php в котором можно поменять некоторые значения. Думаю, что разберетесь с этим.
Теперь выбираете файл модели, к которой хотите создать слаг. Пусть, к примеру, эта модель называется Post. В этой модели нужно указать пространство имен и создать метод для генерации слага из какого-либо поля таблицы:
Рассмотрим вариант, когда таблица у вас уже существует и необходимо создать новую миграцию, для добавления одного поля:
После чего будет создана новая миграция и вы увидите в командной строке, что-то наподобие этого:
Внутри созданного файла создаем новое поле:
И запускаем миграцию:
Вначале мы проверяем, не является ли слаг числом. Зачем мы это делаем?! Часто слаги внедряют в программу уже после того, как был другой механизм построения пути. Например, через числовые индексы. Тогда может получится ситуация, что пользователь, зайдя на сайт по старой ссылке, увидит 404 ошибку, что такой страницы не существует. Ведь мы теперь работаем через слаги. Поэтому, нам необходимо сделать 301 редирект со старой страницы, на новую.
Для этого мы и проверяем полученный аргумент на числовое значение, пытаемся по этому значению получить коллекцию (collection), и если такой пост действительно существует (если нет, то выводим 404 ошибку), то делаем 301 редирект на страницу со слагом.
Если же вы создаете сайт с нуля и сразу используете слаги, то вам такой проверки и редирект делать не нужно.
Построения ссылки в шаблоне тоже очень простое:
В принципе, это и все!
Как видите, сложности нет вообще никакой, а использование слагов очень просто и удобно для пользователей и поисковиков.
Project slug что это
Для работы со слагами в Laravel нам понадобится простой и удобный пакет cviebrock/eloquent-sluggable. Устанавливаем его для Ларавел 5.5:
Если вы захотите изменить какие-либо дефолтные настройки, то создайте файл конфигурации:
После этой команды будет создан новый конфиг: config/sluggable.php в котором можно поменять некоторые значения. Думаю, что разберетесь с этим.
Теперь выбираете файл модели, к которой хотите создать слаг. Пусть, к примеру, эта модель называется Post. В этой модели нужно указать пространство имен и создать метод для генерации слага из какого-либо поля таблицы:
Рассмотрим вариант, когда таблица у вас уже существует и необходимо создать новую миграцию, для добавления одного поля:
После чего будет создана новая миграция и вы увидите в командной строке, что-то наподобие этого:
Внутри созданного файла создаем новое поле:
И запускаем миграцию:
Вначале мы проверяем, не является ли слаг числом. Зачем мы это делаем?! Часто слаги внедряют в программу уже после того, как был другой механизм построения пути. Например, через числовые индексы. Тогда может получится ситуация, что пользователь, зайдя на сайт по старой ссылке, увидит 404 ошибку, что такой страницы не существует. Ведь мы теперь работаем через слаги. Поэтому, нам необходимо сделать 301 редирект со старой страницы, на новую.
Для этого мы и проверяем полученный аргумент на числовое значение, пытаемся по этому значению получить коллекцию (collection), и если такой пост действительно существует (если нет, то выводим 404 ошибку), то делаем 301 редирект на страницу со слагом.
Если же вы создаете сайт с нуля и сразу используете слаги, то вам такой проверки и редирект делать не нужно.
Построения ссылки в шаблоне тоже очень простое:
В принципе, это и все!
Как видите, сложности нет вообще никакой, а использование слагов очень просто и удобно для пользователей и поисковиков.
ЧПУ (SEF URLs) в Symfony 3 — автогенерация slug, настройка и маршрутизация
Всем доброго времени суток!
Третьего дня мне понадобилось провести блиц вебинар на тему ЧПУ в Symfony. Вообще время вебинара у меня ограничено двумя часами, при этом я должен был рассказать еще и про автогенерацию CRUD функционала (scaffolding) в той же Symfony, и про простейший способ создать постраничность. Это создало проблему, так как я знаю как сделать ЧПУ «ручками», не прибегая к автоматизированным под эту задачу инструментам, но рассказ получился бы долгий и оказались бы затянутыми в обсуждение лишние темы. Поэтому я пошел спрашивать у Интернета как сделать все проще. И вот я оказался в той редкой ситуации, когда такая популярная платформа как Symfony не имеет банального обучающего материала на тему «ЧПУ в три клика». Смотрел так же и на английском языке, но там тоже пусто (может плохо искал — время было ограничено). В общем я справился с поиском разрозненного материала по данной теме, а так же со сбором его в единое повествование, так что почему бы не поделиться со всеми?
Терминология
Я не знаю кто будет читать мою статью, так что для начала разберемся в терминологии.
ЧПУ — аббревиатура от «Человекопонятные URL». На английский переводится как Friendly URL или Semantic URL. Однако чаще используется как аналогичная аббревиатура: SEF URLs — Search Engine Friendly URLs.
Самое очевидное — это то, что URL-ы вашего сайта будут понятны пользователю. Зачем, только, ему их читать? Большинство клиентов моих заказчиков даже не подозревают о наличии адресной строки браузера. Если есть сомнения, то посмотрите сколько результатов выведет запрос в Гугл «Где находится адресная строка браузера».
Однако есть неоспоримые плюс — правильно составленные ЧПУ являются одним из важных элементов SEO оптимизации, благодаря которой странички вашего сайта будут появляться в поисковике на первой странице. Для этого URL на вашем сайте должны содержать релевантную для поисковика информацию о страничках, на которые они ведут и иметь продуманную вложенность. Все это замечательно, но речь в этой статье не о SEO оптимизации. Предполагается, что вы уже решили получить ЧПУ на своем сайте и дополнительная мотивация вам уже не требуется.
ЧПУ URL-ы — это адреса страниц описывающие всю необходимую информацию о запрашиваемой у сервера странице в виде сегментов пути, то есть GET параметры в таком URL-е большая редкость.
Обычно можно найти шаблоны пути подобные таким:
http(s)://Домен/slug-категории/slug-подкатегории/slug-товара-или-статьи
http(s)://Домен/Профайл/slug-владельца-профайла
Тут появляется еще один термин — Slug, который важен для дальнейшего понимания статьи:
Slug — (из Викисловаря) альтернативная дружественная к восприятию человеком — буквенно-цифровая часть универсального адреса интернет-ссылки (URL) к рубрицируемому содержимому. То есть, если по простому, то slug заменяет всяческие признаки и id-шники ресурсов нашего сайта в URL-е на человекопонятный текст.
Кому и так ясно что-такое ЧПУ — мотаем дальше.
На примере сайта магазина rozetka.com.ua (первый сайт, который попался под руку). ЧПУ тут в зачаточном состоянии. Давайте попробуем их ссылки довести до ума вручную:
Я зашел на страницу «Мячи для настольного тенниса» и адрес в ее оказался:
rozetka.com.ua/t_balls/c81265
Явно, что «c81265» первым символом указывает на то, что запрашиваемый объект — категория товаров, а число после него — id категории в базе данных.
Переделав под ЧПУ у на получилось бы просто:
rozetka.com.ua/t_balls
Просто удалили id-шник? Как же так? А как же контентные страницы (http://rozetka.com.ua/contacts/)?
Да никаких проблем. Просто поставьте все контентные страницы, так чтобы текущий путь в запросе сверялся в первую очередь с ними. В Symfony это делается всего лишь тем, что маршруты для этих путей объявлены первыми.
Если и так не получается или у вас на сайте есть еще что-то важное кроме контентных страниц и категорий товаров, то делаем более однозначный путь:
rozetka.com.ua/category/t_balls
Далее я перешел на сам продукт «Мячи для настольного тенниса Donic Elit 1* 6 шт белый (618016): rozetka.com.ua/198578/p198578
Вот тут просто беда. ЧПУ даже перестало пахнуть.
Как должен был выглядеть такой URL? В зависимости от того как у вас устроен сайт может быть несколько вариантов. По степени загруженности URL сегментов, уменьшающих неоднозначность пути:
t_balls — slug категории
donic-elit-1-6-beliy — slug продукта
Думаю с наглядностью мы закончили.
Как получить ЧПУ в Symfony
Объяснять буду на примере свежей установки Symfony. На момент написания была взята версия Symfony 3.3.0. Предполагается, что вы установили Symfony и сконфигурировали доступ к базе данных.
Прежде чем начнется суть да дело нужно подружить нашу Symfony 3.3.0 с phpunit, чтобы она не валилась после автогенерации контроллеров. Дополните composer.json проекта двумя строчками:
И произведите обновление зависимостей:
Или так, если у вас композер архивом лежит в проекте:
Генерируем внутри бандла AppBundle сущность продукта консольной командой:
Наверняка вы заметили, что помимо остальных полей имеется интересное поле slug. Я сделал его уникальным, и без возможности быть равным null. Дело в том, что в нашем новом проекте мы должны будем иметь возможность выбирать товары из базы данных как по id-шникам, так и по slug-ам. Slug теперь — наш второй после id уникальный идентификатор записи.
Для удобства изложения и для вашего удобства тестирования мною изложенного материала сгенерируем CRUD контроллер на основе сущности AppBundle:Product, созданой на предыдущем шаге. Для этого выполним консольные команды:
Теперь после запуска сервера
Мы можем посетить страницу http://localhost:2020/products/ и увидеть пустой список продуктов да ссылку на страницу создания нового продукта:
Повременим с созданием новых продуктов. Ведь нас ждет подключение расширений Doctrine.
Подключение поведенческих расширений Doctrine
Почему нам нужны расширения Doctrine? Разве мы сами не можем генерировать slug для продукта? В целом да. Все это можно сделать собственными руками: генерировать slug на основе поля или набора полей, заботиться об уникальности slug-а, иметь всегда в виду необходимость его заполнения, иначе сайт рухнет. Но мы не ради этого здесь собрались. Так что читаем официальную документацию по тому как пользоваться расширениями Doctrine:
Тут нам советуют использовать бандл StofDoctrineExtensionsBundle, который обеспечит корректное подключение расширений Doctrine. Читаем документацию по нему:
Устанавливаем бандл StofDoctrineExtensionsBundle:
Подключаем скачанный бандл:
Из всего богатства вовлеченных нами в проект расширений Doctrine нам нужно всего одно — Sluggable behavior extension. Так что сконфигурируем StofDoctrineExtensionsBundle таким образом, чтобы это расширение было включено:
Расширение Sluggable behavior extension подключено. Надо теперь указать ему, что именно от него требуется. Для этого почитаем по нему документацию:
Оказывается, нам не так уж и много нужно сделать. Всего-то нужно в сущности продукта подключить класс аннотаций, которые предоставляет нам расширение, да указать этими аннотациями полю Product:slug, что оно должно автоматически заполняться как slug на основе полей, которые мы выберем:
Пора создавать продукты. Но перед этим нужно убрать лишнее поле из формы, ведь поле slug Doctrine будет заполнять самостоятельно:
Заходим на форму создания продукта (http://localhost:2020/products/new)
Сохраняем и видим, что slug сгенерирован. Он годен для использования в маршрутах вашего приложения:
Остается проверить ЧПУ на деле.
Первый ЧПУ маршрут
Сделаем все по простому. А именно — переделаем маршруты products_show и products_edit:
таким образом, чтобы они показывали нам продукт не по id-нику, а по slug-у. Маршрут products_delete менять не будем, так как он не виден ни пользователю, ни поисковику.
Теперь маршрут на детальный просмотр продукта выглядит так: @Route(«/
Маршрут на редактирование продукта: @Route(«/
Уникальность slug-ов
Вопрос заданный мне в комментариях пользователем psycho-coder сподвиг меня дополнить статью. А что, если я захочу создать несколько продуктов с одинаковым наименованием? Ведь Symfony позволяет это сделать. Что будет тогда со slug-ами, которые пишутся в поле с уникальным ключом в базе данных?
Как я говорил выше, Doctrine Sluggable behavior extension берет на себя ответственность по построению уникальных slug-ов.
Для примера я создал три раза подряд продукт с одним и тем же именем: „Что-то осмысленное“. Автоматически сгенерированные slug-и получились такими:
Если этот вариант не нравится, то можно для поля slug указать генерацию на основе не одного поля, а двух. Пример подобной аннотации для поля slug:
Трижды создаем продукт с промежутком в одну минуту и получаем slug-и:
Если и это не нравится, то придумываем свой вариант и делимся в комментариях
Мы добились нашей цели:
Архив с Symfony проектом, созданным в процессе написания статьи прикладываю тут.
Кстати, 3d картинку рендерил сам специально для этой статьи. Мне она понравилась, да и сил много не отняла.
Введение в непрерывную поставку (CD) при помощи GitLab
Данный туториал позволит вам быстро прочувствовать как происходит командная работа с использованием GitLab. В целом, начать практиковать DevOps/CD с GitLab проще чем с использованием других продуктов потому что GitLab — это решение «всё в одном».
В процессе этого туториала мы
Желательны но необязательны базовые знания
Время от времени я буду просить вас что-то сделать. Такие моменты помечены значком «!«. Пожалуйста выполняйте действия по мере чтения текста чтобы получить от данного туториала наибольшую пользу.
В оригинале места где требовалось что-то сделать были помечены эмодзи «молоток и гаечный ключ». Так как редактор habr’а вырезает эмодзи, я заменил эти эмодзи на «!«.
Трудно переводить на русский вещи, которые даже русскоязычные программисты между собой называют по-английски. Я постарался литературно переводить термины для которых есть общепринятые переводы и не переводить остальные. Например, мы будем использовать словечки вроде «чекбокс» и «коммитить», а названия разных штук в GitLab останутся на английском, как есть.
Введение и знакомство с проектом
В качестве «подопытного кролика» мы будем использовать чуть модифицированный шаблонный проект, созданный утилитой create-react-app.
Почему React? Во-первых, это самая распространённая UI-библиотека на JavaScript, и многие читатели знакомы с ней. Во-вторых create-react-app даёт нам осмысленные стадии компиляции и тестирования которые уже реализованы за нас.
! Теперь давайте клонируем репозиторий с кодом с которым мы будем работать.
! Перейдите в каталог локального репозитория
Должна отобразиться стандартная стартовая страница create-react-app.
Вы можете вместо этого этапа просто создать новое приложение при помощи create-react-app, но версия в репозитории содержит некоторые правки, и версии пакетов в коде в репозитории я тестировал.
! Установите npm пакеты локально, выполнив
Используйте npm ci если при выполнении npm install произойдёт ошибка
! Попробуйте «собрать» проект
! Затем запустите тесты
! Осталось осуществить «развёртывание», но чтобы не засорять туториал инструкциями по установке веб-сервера, давайте просто запустим отладочный веб-сервер чтобы увидеть как выглядит наше веб приложение выглядит в браузере.
Всё это, а также многое другое, поддерживается GitLab. Платная версия предлагает больше возможностей, но для наших целей нам хватит и бесплатной версии доступной на GitLab.com.
GitLab выделяется на общем фоне отсутствием ограничений на использование собственных job runners, однако некоторые довольно базовые «управленческие» и «корпоративные» фичи GitLab вроде обязательного утверждения merge request’ов входят в платные версии. Проектам с открытым кодом все фичи GitLab доступны бесплатно.
️ Базовая настройка управления проектом на GitLab.com
В этой части мы создадим сам проект в GitLab и задачи над которыми будем работать в дальнейшем, а также настроим Kanban-доску для визуализации состояния проекта.
Создание проекта в GitLab
Мы будем использовать GitLab.com в качестве инсталляции GitLab чтобы избежать хлопот по установке и настройке локальной версии.
! Если у вас ещё нет учётной записи на GitLab.com, зайдите на https://gitlab.com и заведите её.
GitLab позволяет нам создать проект просто выполнив push в удалённый репозиторий.
! Воспользуемся для этого следующей командой:
тут — ваше имя пользователя на GitLab.com.
Эта команда создаст приватный проект с именем gitlab-cd-react внутри вашей учётной записи на GitLab.com.
Далее мы настроим канбан-доску, а заодно создадим несколько задач чтобы было вокруг чего строить дальнейшую работу и о чём собирать статистику.
️ Создание задач и настройка доски
Давайте начнём с создания задачи.
! Кликните Issues в левом меню, затем нажмите одну из кнопок New Issue в основной области. Откроется форма создания задачи. Укажите в качестве заголовка «Создать задания для туториала».
В описании укажите следующий текст
Да, именно эти вещи мы и будем делать в дальнейшем. Оставьте остальные значения по умолчанию. Нажмите кнопку Submit issue.
Обратите внимание, что список с пробелами в квадратных скобках вначале элементов был распознан как чеклист, а отдельные его элементы как задачи. GitLab, как и многие другие платформы, использует Markdown в качестве языка разметки.
! Назначьте задачу Создать задания для туториала на себя. Для этого нажмите ссылку Edit в панели с надписью 0 Assignees справа на странице редактирования задачи.
Поздравляю, теперь вы — исполнитель. На самом деле на этом этапе задача может быть назначена любому члену команды но т.к. по сути ничего не изменится, мы не будем плодить пользователей.
! Давайте теперь на самом деле создадим все задачи, перечисленные в описании нашей первой задачи. Укажите только заголовки, остальные поля оставьте по умолчанию. Вы можете «ставить галочки» в описании задачи Создать задания для туториала как по мере создания задач, так и все сразу когда закончите.
Существуют разные способы создавать задачи, при создании задач по списку найдите и используйте хотя бы 3 разных способа. В итоге у вас должно получиться 6 задач.
Наш процесс работы
Под процессом работы(workflow) обычно подразумевается порядок этапов, которые задача проходит для того чтобы считаться выполненной. В Continuuos Delivery, Kanban и DevOps задача движется через некую последовательности состояний либо вперёд, либо может быть возвращена на один из предыдущих этапов.
Это подразумевает линеаризованные value streams. Про value streams можно почитать тут. Превращение порой затейливой диаграммы переходов в последовательность состояний является иногда очень сложной управленческой задачей, решение которой выходит за границы этой статьи.
Мы будем использовать простую последовательность состояний
Вначале задача оказывается в состоянии Open. Затем она затягивается(pull) в работу разработчикам в стадию Dev. После того, как работа завершена, происходит передача задачи в стадию Dev: done.
Зачем нам нужна эта дополнительная стадия? Дело в том что в Lean, на котором основаны все методологии типа CD, Kanban и DevOps, следующий этап(work center) затягивает задачи когда он готов в отличие от методологий где задачи передаются в следующий этап предыдущим. Это позволяет отслеживать задачи которые находятся в стадии ожидания, а накопление задач в стадии ожидания позволяет нам понять, где в нашем «конвейере» «бутылочное горлышко».
Итак, затем задача затягивается в этап QA где работают специалисты по качеству и автотесты, а «выпускники» QA считаются настолько хорошими что развёртываются непосредственно на продуктив.
«Ну так же не бывает, это же чих-пых — и в продакшн, должны же быть другие среды типа Staging в процессе!» — скажете вы. Я совершенно согласен, но тут мы используем максимально простой в реализации и для понимания конвейер чтобы меньше отвлекаться от GitLab и не закопаться где-нибудь в дебрях Kubernetes.
️ Настройка меток
Для организации задач GitLab использует метки(labels). Они как теги и позволяют искать, фильтровать и отображать задачи в разных местах в зависимости от наличия той или иной метки. Давайте заведём сами метки
Названия меток тут полностью произвольные и никакого особого смысла с точки зрения GitLab в них нет.
! Когда закончите, назначьте задачу Создать метки статус Closed.
Теперь всё готово для настройки Kanban-доски.
Настройка доски
В GitLab есть Kanban-доски. Они позволяют отображать разные задачи в соответствии с их метками. Несмотря на название они могут быть использованы не только для реализации Kanban, но и Scrum а также других методологий. У нас же уже создана задача для этого.
! Назначьте эту задачу на себя.
Если вы создали их в другом порядке, вы можете изменить порядок, перетаскивая списки «за заголовки».
Таким образом мы указываем что начали работать над этой задаче. Обратите внимание что у задачи появилась новая метка Dev.
! Так как всю работу мы уже сделали, переведите задачу в столбец Dev: done.
Мы приближаемся к стадии QA. Постарайтесь внутренне ощутить себя тестировщиком, подумайте какие разработчики неблагонадёжные люди, и, опционально, разберите при помощи отвёртки небольшой бытовой прибор.
! Затем переведите задачу в стадию QA. Тут можете несколько раз поперетаскивать задачу из столбца в столбец туда-сюда. Кстати, такие приключения порой и происходят с задачами на данном этапе. В процессе у задачи будет появляться метка нового столбца и исчезать метка предыдущего столбца. В конце концов оставьте задачу в столбце Closed и обратите внимание что в результате этого действия она была закрыта.
Есть ещё один полезный интерфейс — To-Do List(в меню рядом с меню логина есть подменю). Это список действий, которые по тем или иным причинам ожидается от вас. Мы не будем останавливаться на нём подробно, но я рекомендую заглядывать в него в процессе туториала время от времени чтобы составить представление о том как эта штука работает.
Конвейер непрерывной поставки
В этой секции мы реализуем непрерывную поставку(Continuous Delivery) средствами GitLab.
️ Построение конвейера непрерывной поставки в GitLab
Для того чтобы на самом деле выполнять код задач конвейеров, GitLab.com использует общие агенты (shared runners) которые реализуют docker executors. Если вы зарегистрируете свои собственные агенты, вам будет доступна куда большая гибкость в выборе сред сборки.
Давайте теперь сконструируем наш конвейер.
! Назначьте issue Создать конвейер непрерывной поставки и переведите его в статус Dev.
Формат, который использует GitLab для определения конвейеров сборки — один из самых простых и интуитивно понятных в отрасли.
Чтобы получить нужный нам конвейер чуть модифицируем этот файл.
image задаёт какой образ docker будет использован для выполнения jobs сборки. По умолчанию GitLab использует Docker Hub, но это можно настроить. Нам понадобится образ с предустановленным Node.js.
! Укажите
before_script и after_script выполняются перед и после каждой задачи соответственно. В процессе выполнения задач, мы будем использовать модули Node.js.
! Организуем кэширование модулей для того чтобы не скачивать модули каждый раз из интернета.
after_script нам в этом туториале не понадобится.
! Изменим команды чтобы действительно осуществлять сборку:
Обратим теперь внимание на кусок кода для этапа stage: test
Перейдём к части связанной напрямую с развёртыванием.
Эта часть обычно завязана на специфику среды в которую осуществляется развёртывание и потому технически сложна. GitLab поддерживает развёртывание в Kubernetes с минимальными усилиями по настройке. Альтернативой является реализация логики развёртывания в другую среду своими силами. Оставим технические детали этого процесса для будущих статей. Фокус данной статьи на объяснении основ работы с GitLab, поэтому мы прибегнем к хитрости, а точнее используем то обстоятельство что наше приложение на React технически является статическим вебсайтом и развернём его на GitLab Pages, которые доступны любому у кого есть учётная запись на GitLab.com.
! Заменим job deploy1 на этот код.
Мы переименовали deploy1 в pages потому что GitLab именно по названию задачи понимает что требуется развернуть файлы доступные этой задаче в GitLab Pages.
Далее делаем 2 вещи.
Завершим на этом работу над нашим конвейером.
! Переведите задачу Создать конвейер непрерывной поставки в стадию Dev: done.
Проведём несколько циклов работы с GitLab Flow
Git — очень гибкая система контроля версий кода и использовать его можно очень по-разному. Если каждый член команды использует Git по-своему, возникает путаница когда трудно понять логику действий других людей из истории изменений, и никто не понимает что ожидать от других. Об измерении производительности в такой ситуации и говорить не приходится. Для того чтобы такая путаница не возникала участники команды обычно договариваются о единых правила работы с Git, такая договорённость и называется Git workflow.
Чтобы изучить реализацию GitLab Flow в GitLab мы сделаем эти вещи:
Процесс работы с Git
Если коротко, то GitLab Flow состоит в том что
На самом деле для реализации CD нам годится любой процесс работы с Git который поддерживает trunk based development, и мы могли бы реализовать любой такой процесс при помощи GitLab. Однако по той причине, что GitLab рекомендует использовать GitLab Flow и для того чтобы не усложнять наш сценарий, мы его и используем.
Уровни доступа в GitLab
Существует разные уровни доступа, в порядке понижения полномочий.
Merge requests
Merge requests — основной способ внесения изменений в код при использовании GitLab. Изменения вносятся в код, затем автором изменений создаётся merge request, который затем обсуждается, в котором происходит code review. Merge request в результате принимается, отправляется на доработку или отклоняется.
! Переведите задачу Создать конвейер непрерывной поставки в стадию QA.
Да, вот так мы будем тестировать наш конвейер, но вы должны тестировать на реальных проектах более ответственно. Не делайте как я делаю, делайте как я говорю.
Наше приложение бесполезно. В этом нет ничего необычного, ведь в интернете много бесполезных приложений. Чтобы выйти на новый уровень, давайте сделаем наше приложение токсичным. Существуют 2 фичи, которые являются проверенным способом достичь этого.
В качестве Commit message укажите, например, «Add React imports». В качестве Target branch оставьте master и нажмите Commit changes.
! Измените Allowed to push на No one.
Соответствующий участок кода должен теперь выглядеть примерно так
Укажите «Add the annoying popup» в качестве commit message.
Вы увидите что вам предлагается добавить коммит в некую ветвь и в уже автоматически сгенерировано некоторое имя ветви. Мы в будущем заменим это имя на более осмысленное и соответствующее нашему процессу работы с Git, но пока давайте проведём небольшой эксперимент.
! Замените предлагаемое имя на master и нажмите Commit changes.
Нажмите Submit merge request
После создания merge request’а, ы окажетесь его на странице. Давайте изучим эту страницу. В основной области мы видим следующее.
Для бесплатных подписок есть только возможность «совещательного» согласования merge request’а, в платных версиях есть возможность сделать согласование необходимым.
Если вы переключитесь на вкладку Changes, вы можете посмотреть, какие изменения в код планируется внести. Здесь же вы можете создать комментарий, который будет ссылаться на строку кода.
Кстати, merge requests также поддерживают метки, которые вы можете использовать чтобы было проще находить нужные.
К этому моменту работа конвейера уже должна завершиться и… тесты завершены неуспешно. В нашем конкретном случае это потому что мы использовали window.alert который является чисто браузерным объектом и наши выполняемые в среде Node.js юнит-тесты не имеют к нему доступа.
В случае непрерывной поставки требуется очень хороший набор автоматических тестов потому что именно на них переложена почти вся, а в случае непрерывного развёртывания(Continuous Deployment) — вся, ответственность за контроль качества. Поддержание такого набора тестов в актуальном состоянии — главная технический вызов в реализации таких методологий.
! Давайте вернёмся в merge request Add the annoying popup и нажмём кнопку Merge и примем изменения в код. Оставьте чекбокс Delete source branch установленным.
При использовании GitLab Flow feature branches традиционно удаляют. Это позволяет избежать замусоривания системы уже неактуальными ветвями и создавать ветвь с тем же именем в случае отправки задачи на доработку.
При создании merge request’а таким образом задача будет закрыта автоматически как только мы сольём код в основную ветвь.
Добавим функцию оповещений в наш вебсайт чтобы он выглядел современно.
после ранее добавленной строчки
! Нажмите кнопку Commit в левой нижней части. Вы увидите интерфейс коммита, укажите в качестве commit message «Add the notifications users want». Оставьте всё остальное по умолчанию и нажмите кнопку Commit.
! Перейдите в merge request, например, используя подменю в верхней правой части экрана рядом с меню логина.Нажмите кнопку Mark as ready в верхней правой части формы merge request’а. Нажмите кнопку Merge или Merge when pipeline succeeds в зависимости от того завершился ли уже конвейер.
! Откройте наш тестовый вебсайт и убедитесь что новые «фичи» работают, и наша страница ощущается как большинство современных сайтов в интернете.
! Если с сайтом всё хорошо, перетащите задачу Создать конвейер непрерывной поставки в стадию Closed на доске.
Итак, мы провели несколько полных циклов работы и теперь можем изучить метрики, которые GitLab собрал в процессе работы.
Метрики CI/CD в GitLab
В процессе командной работы полезно собирать статистику чтобы понимать повышается ли продуктивность или падает. Способы оценки производительности могут быть совсем разными в зависимости от характера работы и типа проекта или продукта.
Например, веб-студия может иметь «типовые» задачи типа отрисовки макета в рамках стандартного пакета услуг, предлагаемого клиенту. Agile стартап же может находиться в стадии когда концепция продукта меняется вместе с растущим пониманием потребностей клиента и рынка, и задачи могут быть трудно предсказуемы и часто уникальны. Вместе с тем, можно выделить чисто технические показатели производительности вроде одного из основных для DevOps времени вывода новой фичи на рынок (time to market, TTM) или просто длительности той или иной стадии. Отслеживать динамику таких показателей может быть очень полезно: за достаточно длительный период времени это позволяет понять как изменяется производительность.
Хорошей новостью является то что GitLab имеет функционал сбора этой статистики. Давайте с этим функционалом познакомимся.
! Кликните на Analytics. По умолчанию откроется раздел Value stream. В Lean вообще и в DevOps в частности считается что задачи несут в конечном итоге некоторую пользу для конечного заказчика. И движение таких полезных задач, от стадии формулирования через все этапы работы до того момента когда результаты становятся доступны заказчику называется value stream.
Основные средние величины по этапам:
Если вы сложите длительность Issue, Plan, Code, Review и Staging, вы и получите примерно то самое заветное время для вывода на рынок (TTM).
Наверху страницы в также увидите некие агрегатные показатели по проекту за выбранный период времени.
Поздравляю!
Вы осуществили имплементацию непрерывной поставки(CD) при помощи GitLab начиная с задач с канбан-доской и завершая метриками.