Разборы технологий, обзоры инструментов и практические заметки инженерной лаборатории.
Миграция в облако — это не просто переезд на виртуальные машины. Это пересборка всей инфраструктуры с нуля: под новые требования к надёжности, стоимости, безопасности и скорости развития. Когда мы в TSKLab затеяли этот процесс, задача стояла сугубо практическая: снять с команды лишнюю операционку, ускорить развёртывание сервисов и получить прозрачный контроль над ресурсами, не завязанный на единственный […]
В TSKLab выбор редактора кода — не вопрос личных предпочтений, а инженерное решение, привязанное к конкретным сценариям. Часть команды работает в IntelliJ IDEA, часть — в VS Code, и это не раскол, а осознанное разделение труда. За годы тестирования на реальных проектах мы убедились: универсального инструмента не существует, зато есть чёткие критерии, когда какая среда даёт максимальную […]
# Как мы внедряли CI/CD: GitLab CI и GitHub Actions на проектах TSKLab
В проектах TSKLab мы сознательно использовали два разных подхода к CI/CD: GitLab CI — там, где важны единая платформа и жесткий контроль пайплайнов, и GitHub Actions — там, где удобнее жить рядом с кодом и быстро масштабировать автоматизацию. Такой гибридный подход оказался практичнее, чем попытка […]
Представим, что после релиза сервис стал отвечать быстрее. В новой версии переписали кэширование, одновременно обновили runtime, изменили размер пула соединений и перенесли приложение на другой тип виртуальной машины. Само улучшение можно измерить. Гораздо труднее ответить, какое из четырёх изменений связано с ним сильнее.
После тестов новая версия приложения всё равно впервые сталкивается с реальным production-трафиком, реальными данными и рабочими зависимостями. Canary deployment уменьшает масштаб этого первого контакта: старая стабильная версия продолжает обслуживать основную нагрузку, а release candidate получает только ограниченную часть трафика.
Разработчику привычно сначала сформулировать гипотезу, зафиксировать исходное состояние системы и только потом оценивать последствия изменения. Похожий подход используется и в SEO: например, в эксперименте с топовысок сначала сохраняют стартовые показатели целевой страницы, а затем сопоставляют их с новыми ссылочными событиями и дальнейшей динамикой.
Observability часто начинают настраивать после проблемы: релиз уже выполнен, показатель изменился, и команда пытается понять, что произошло. Для инженерного эксперимента порядок лучше развернуть. Сначала нужно решить, какие состояния и события система умеет показывать, и только затем вносить изменение.
Когда ко мне приходят с вопросом «что круче — PostgreSQL или MongoDB», я всегда прошу показать модель данных. Потому что выбор базы — это не голосование за бренд, а инженерное решение, которое определяется тем, как устроены ваши сущности, какие запросы будут ходить и насколько критична целостность. В реальных системах PostgreSQL чаще выигрывает там, где важны согласованность, сложные […]
Новая функция может уже находиться в production-коде и при этом оставаться недоступной пользователям. Для этого поведение приложения помещают за feature flag — условием, которое вычисляется во время выполнения и определяет, какую ветку логики использовать.
Когда после обновления поведение системы меняется, команде обычно нужно ответить сразу на несколько разных вопросов. Что было изменено в коде. Что вошло в релиз. Что именно происходило во время проверки и какие наблюдения были получены. Проблема в том, что эти три вопроса часто пытаются закрыть одним объектом, чаще всего списком commit.