Пользователь
Сейчас компетентность в сфере TestOps является таким же базовым требованием к QA-инженерам, как и написание автоматизированных тестов. Причина — в активном развитии CI/CD в проектах и необходимости QA-инженерам работать с пайплайнами (читать как "последовательность этапов в CI/CD") и даже внедрять свои. Так почему же CI/CD — отличный инструмент контроля качества? Давайте разбираться.
В IT индустрии используется большое разнообразие инженерных культур и практик, таких как Agile, бережливое производство (lean software development), DevOps. Все они так или иначе нацелены на бесперебойную доставку ценности за счет повторяемых коротких итераций. Неотъемлемой частью такого подхода является конвейерный подход или по-английски – pipelines. Подразумевается, что в идеальном мире разработчик заливает код на сервер и дальше происходит магия, состоящая из автоматизированных этапов сборки проекта, контроля качества кода, запуска тестов и сбора метрики. На рынке существует большое количество платных и бесплатных инструментов для настройки такого процесса, который мы называем “процессом непрерывной интеграции” или CI/CD (Jenkins, GitLab CI, Teamcity и д.р.). Однако для построения действительно зрелого процесса недостаточно просто установить инструмент. За каждым этапом конвейера стоит сложная логика того, что должно быть запущено, на каких вычислительных ресурсах и как эти ресурсы используются.
На собеседовании кандидаты очень часто гордо говорят, что знают CI/CD. Но знать можно по-разному. Одно дело нажимать кнопку запуска и смотреть, какой цвет получился: красный или зеленый. И совсем другое дело настраивать весь флоу от и до самостоятельно, чем обычно и занимаются DevOps инженеры. Для проверки глубины знаний я задаю базовый вопрос, на который очень редко получаю ответ: “А в чем разница между CI и CD ?”. Далее я хочу поделиться своим пониманием отличий CI от CD и от еще одного CD на примере запуска автотестов. Заранее предупрежу, что мое видение может частично отличаться от вашего. Ведь у всех нас немного разный опыт, разные проекты и источники для изучения, которые могут расходиться. Главное, что какое-то видение у вас есть!
Всем привет! Меня зовут Анатолий Калмыков, и я отвечаю за качество создаваемых решений в «Ростелеком ИТ». Сегодня я расскажу вам про WireMock – это одновременно и утилита, и библиотека на Java для создания HTTP заглушек над веб-сервисами. Он создает HTTP-сервер, к которому мы могли бы подключиться, как к реальному веб-сервису.
Статья получилась длинной, поэтому в первой части я расскажу, что такое WireMock и в каких случаях его необходимо использовать, как его разворачивать и настраивать, как правильно сопоставлять запросы с заглушками и как использовать журналирование. Сегодня речь пойдет исключительно о WireMock в амплуа утилиты и standalone http-сервер, который можно настроить как душе угодно, не зная языков программирования.
Всем привет! В предыдущей части я рассказал, что такое WireMock, в каких случаях его необходимо использовать, как его разворачивать и настраивать, как правильно сопоставлять запросы с заглушками и как пользоваться журналированием. Настало время рассмотреть все что связано с HTTP ответом, который возвращает заглушка, а также затронем сценарии.
Давайте признаем: современный Web стал очень сложным. Веб-дизайнеры все меньше думают о пользователях с узким каналом, которые вынуждены ждать, пока загрузится очередная огромная картинка. Иногда нам просто нужен старый добрый веб-сайт, без каких-либо дополнений, таких, как постоянное подключение к базе данных, панели администратора с WYSIWYG редактором и т. д.
Да, существует несколько способов создать веб-сайт, который будет представлять собой набор статических HTML-файлов. Но этот подход имеет массу недостатков: каждая страница загружается индивидуально, а наша задача определенно не состоит в том, чтобы возвращаться в 2000-е (хотя ностальгия может быть прекрасной, что уж там).
SPA (Single-Page Application, или одностраничное приложение) — хорошее решение, которое не требует перезагрузки каждой страницы, когда содержимое нуждается в обновлении. Но проблема в том, что эти веб-сайты полностью генерируются на стороне клиента, в браузере; не каждая поисковая система сможет их проиндексировать. В подобных ситуациях хорошим решением является рендеринг страницы на стороне сервера (Server-Side Rendering, или SSR), после этого — «переключение» в режим SPA (регидрация). Когда пользователь захочет перейти на другую страницу, с сервера будет загружен небольшой фрагмент данных, и необходимости перезагружать полностью страницу не будет.
Идея состоит в том, чтобы создать такой шаблон (boilerplate), чтобы каждый веб-мастер (или любой человек, обладающий базовыми навыками верстки на HTML и CSS) мог создать веб-сайт, который будет достаточно быстрым и удобным в обслуживании. Здесь в игру вступает Heretic.
Map - это интерфейс, а HashMap - одна из его реализаций. Тем не менее, в этой статье мы постараемся разобраться, чем полезны интерфейсы, узнаем как сделать код гибче с помощью интерфейсов и почему существуют разные реализации одного и того же интерфейса.
В данной статье вы познакомитесь с Marko.js актуальной на данный момент пятой версии. Пару лет назад на Хабре уже была отличная статья (за авторством apapacy) о том, как работает этот замечательный реактивный фреймворк, разработанный где-то в недрах eBay.
В своем комментарии (а это был далекий 2020 год) я предложил написать на Хабр статью, посвященную моему опыту работы с Marko, и вот - как с тем самым котом - время наконец пришло :-)