Если вы еще никогда не поддерживали чужие приложения, или пусть даже свои, но таких размеров, что уже не помещаются в одной голове, то прошу вас расслабиться, откинуться на спинку кресла и воспринимать прочитанное как поучительную сказку с надуманными проблемами, забавным сюжетом и очевидным счастливым концом. В противном случае, если реальный боевой опыт у вас имеется, добро пожаловать в ад, но с IDDQD и IDKFA.

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Всем привет! Мы продолжаем цикл статей «Как мы внедряли DevOps» от команды Vorlon.JS.
Vorlon.JS — это основанный на node.js инструмент, который позволяет веб-разработчикам удобный способ удаленно тестировать, контролировать и отлаживать веб-приложение, особенно на мобильных и embedded системах. В своем блоге на MSDN, команда подробно описывала поэтапное внедрение DevOps практик в организацию работы над Vorlon.JS и выбор инструментов для решения ежедневных задач. Vorlon.JS является проектом с открытым исходным кодом.

Microsoft предлагает большое количество инструментов, которые могут быть использованы для реализации DevOps практик, и в этом цикле мы подробно расскажем про Visual Studio Team Services, Visual Studio Code и работу с Microsoft Azure. Конечно, затронем и возможность использования также множества не-Microsoft инструментов, в том числе при развертывании приложений в Microsoft Azure.

Содержание цикла:

• Планирование и управление проектами с помощью Visual Studio Team Services
• Непрерывная интеграция с GitHub и системой сборки Visual Studio Team Services
• Инфраструктура-как-код с помощью Microsoft Azure и Azure Resource Manager
• Управление выпусками в Visual Studio Team Services
• Тестирование в production-среде с Microsoft Azure App Service и Web Apps

Вы возможно уже знаете, что Visual Studio Team Services (VSTS) предоставляет инструменты управления исходным кодом с поддержкой GIT или TFVSC (Team Foundation Version Source Control).

В этой статье мы подробно расскажем, как легко внедрить непрерывную интеграцию для кода, расположенного на GitHub, используя Visual Studio Team Services.

Не поймали за хвост удачу в виде главного бага известного сервиса, нет желания “толкаться” на oDesk или не хочется делать то же, что уже и так делаете в рабочее время?

Мы нашли альтернативные и не суперконкурентные варианты: излагать технический опыт по-английский, получать ренту с кода или завести монетизируемое хобби, связанное с математикой, инженерией или общением.

Однажды мне потребовался WYSIWYG редактор, я помнил как он выглядит, его функции, но не помнил названия. Через 45 минут я все же его нашел… Тогда я поставил перед собой задачу помочь многим, в том числе и себе: сделать сводный список всех чуть более известных WYSIWYG редакторов.

Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Webhook

Webhook — это платформа для создания сайтов. Важно не путать со статическими генераторами, потому что это именно «CMS builder». Проект успешно завершил кампанию на Kickstarter 14 мая этого года, где смог собрать сумму в два раза большую, чем было необходимо. А буквально недавно состоялся релиз первой версии продукта. Webhook построен с использованием NodeJS, Grunt и Firebase для реалтайма, работает на Windows, Linux и Mac, внутри целая система виджетов со множеством вариаций на выходе, «Django-like templating» с помощью Swig JS, кроссплатформенная админ панель и еще целый ряд плюсов.

Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

В этом топике мы в общих чертах рассмотрим процесс реализации непрерывной интеграции на примере TeamCity Enterprise 6.0 EAP (build 15400) и обратим внимание на применении инструментов рассмотренных в прошлой теме: Обеспечение качества программного продукта.

В этой статье я расскажу об опыте поставки и конфигурирования многочисленных взаимосвязанных продуктов (непричастные называют это просто «созданием инсталляторов»).

Итак, представьте разбросанный по нескольким серверам набор приложений: 12 штук. Приложения разнородные, разработаны разными компаниями в разное время. Реализованы различные методы интеграции от примитивных экспортов/импортов через файловую систему, до продвинутой на базе web-сервисов. Приложения используют базы данных SQL Server и Oracle. Все эти приложения работают в сотнях разных окружений конечных заказчиков.

Установить и сконфигурировать все это стоит немалых трудов и ресурсов. Хорошо, установили. А обновления, которые для бухгалтерских систем должны выпускаться в соответствии с изменениями в законодательстве? Масштабирование приложений? А новый функционал? Что насчет новых клиентов с их «особенными» конфигурациями? Вручную – дорого и долго, если у вас, скажем, 150 клиентов и хотя бы 2 обновления такого «монстра» в год.