Возникли проблемы с совместимостью ваших приложений? Для этого есть инструменты, которые помогут решить эти проблемы.

Наборы инструментов и примеры:

Microsoft Deployment Toolkit (MDT) 2008 Update 1(571 KB — 20.7 MB)
Microsoft Toolkit (MDT) 2008 это средство для распространения (установки)OC настольных и серверных приложений

Microsoft Application Compatibility Toolkit 5.5(404 KB — 20.6 MB)
Microsoft Application Toolkit (ACT) содержит необходимые инструменты и документацию для оценки и смягчения проблем совместимости приложений перед развертыванием на Windows 7, Windows Vista, Windows Update, Internet Explorer.

Microsoft Assessment and Planning Toolkit(27 KB — 219.3 MB)
Microsoft Assessment and Planning Toolkit представляет собой инструмент, который помогает оценить текущую ИТ-инфраструктуру для различных методов миграции.

App-V — инструмент для решения проблем совместимости.

Материалы:

Средство миграции пользовательской среды 3.0
Набор средств для обеспечения совместимости приложений

thanks: evgeny_shiryaev

Этот скрипт более исследовательский, чем предназначен для серьезных групп разработчиков. Создавался мною чтобы изучить python получше. Но тем не менее, я успешно пользуюсь им более полугода.

Данная статья для тех разработчиков, которые ведут некоторый проект в SVN, имея удаленный сервер, доступ к которому есть по ftp и ssh, но устанавливать на который ничего нельзя.

Наверняка, большинство из тех, кто разрабатывает или деплоит Python приложения, использует виртуальные окружения. В частности через virtualenv, написанный Ian Bicking.

Идея оказалась так хороша и распространена, что нечто похожее теперь присутствует в Python 3.3 из коробки в виде модуля venv. Он почти такой же, как virtualenv, только немного лучше.

Интересно, скольким из вас приходилось хотя бы иногда, но повторять рутиные действия для настройки автодеплоя с гитхаба на сервер: создать ssh-ключ, добавить его для репозтория проекта на Гитхабе, создать скрипт, который будет слушать какой-то адрес, добавить вебхук в интерфейсе гитхаба, который будет дергать этот скрипт… Уфф… А что, если я скажу вам, что автоматизировал все эти действия по-максимуму? Да, теперь вам нужно выполнить всего пару команд и автодеплой запущен и работает! И все это благодаря Гитхабайзеру.

Привет, Хабраюзеры! На улице противная погода, ангина не дает покоя моему воспаленному горлу, почему бы не написать статью? Это моя первая проба пера на Хабре, поэтому не судите строго. Название ее навеяно огромным количеством книг, имеющих схожее название. В этой статье я постараюсь описать путь воина-автоматизатора для юных падованов, коим в некоторой мере являюсь сам. Речь пойдет о подходе, который при определенном старании, поможет в краткие сроки познакомиться с таким инструментом кроссплатформенной автоматизации, как CHEF. А также, при сильном старании – овладеть ним в достаточной мере для первых серьезных опытов. Эта статья – некий “guiding way” для людей, мало знакомых с процессом автоматизации.

Привет-привет, хабраюзер! Все еще с нами? CHEF – это интересно! Продолжим наш вояж к мастерству воина-автоматизатора, который начался в первой части данной статьи. В этой статье речь пойдет о первом опыте написания cookbook-а, о рецептах, атрибутах и шаблонах.

Сегодня стационарные компьютеры начинают медленно уходить на задний план. Их место прочно занимают ноутбуки, а затем идут и планшетные компьютеры. Сочетание мобильности, высокой производительности и высокой скорости получения информации – все это является несомненным плюсом планшетов. Однако, и своя ложка дегтя у планшетов есть: это малый размер жестких дисков. Если диск 16, 32 и даже 64 ГБ, вовсе не хочется разбрасываться ценным пространством на установочные файлы. С выходом Windows 8.1 Update появилось решение этой проблемы – WIMBoot – новый способ установки ОС, обеспечивающий большее свободное пространство для пользователя.

Доброго времени суток!

Совсем недавно мой коллега познакомил меня с замечательным инструментом автоматизации ручного труда под названием Ansbile. После чего моментально родилась идея написать что-то своё, что упрощает тот самый ручной труд. Что чаще всего приходится делать руками? Правильно, деплоиться.

В этой статье я расскажу о том, как с использованием ansible раскатать django-проект на чистом удаленном сервере ubuntu 14.04, создав при этом для проекта отдельного пользователя.

Случилось то, чего мы так долго ждали. Наша идея воплотилась в камне онлайн сервисе.
Проделав долгий путь от идеи к сервису, через гору кода, стены тикетов и море тестов, с уверенностью можно сказать — мы запустились.

Наш сервис ставит софт в облако. В основном большие серверные продукты, но есть место и небольшим средам для программистов.

Краткая заметка с примерами конфигов, как использовать Travis CI при разработке модулей для Magento обеих версий.

Вступление

Добрый день, уважаемые читатели! Совсем недавно я завершил разработку одного своего приложения на Qt, и мне захотелось создать профессиональную программу установки, чтобы всё было «как у взрослых». Как оказалось, сделать это непросто, учитывая, что на официальном сайте инструментария информации по развёртыванию почти нет. В данной статье рассмотрены некоторые этапы подготовки программ на Qt версии 5.2 или выше для распространения на компьютеры других пользователей. Итак, вот план руководства:

1. Подготовка проекта Qt к развёртыванию
2. Компоновка дистрибутива программы
3. Подписание кода и создание установщика

Не будем терять времени и приступим к работе.

За последние лет пять я вижу очень много статей по «удачным» рецептам построения систем деплоймента и управления конфигурацией на базе Chef/Puppet/Vagrant/Ansible. Я потратил около 7 лет на решение задач автоматического деплоймента в компании, в которой я в то время работал, и теперь считаю, что имею достаточно опыта, чтобы покритиковать многие распространенные инструменты.

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

Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.

Я отметил следующие недостатки:

• Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
• Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов (однако, можно настроить распараллеливание комманд явным образом).
• Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
• Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
• Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.

Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.

Некоторое время назад мы в HeadHunter обнаружили “сумеречную зону” при передаче новой версии сайта из тестирования в эксплуатацию. Недостаточное внимание к разнице между тестовой и боевой инфраструктурой периодически приводило к падению сайта.



Старые тестовые стенды заметно отличались по внутреннему устройству от рабочего кластера. Отличались init-скрипты для запуска сервисов, отличались файлы конфигурации по расположению и содержанию. Взаимодействие сервисов между собой происходило без учета особенностей боевого окружения.

Я покажу логику нашего решения, которая позволила достичь качественно новых результатов тестирования.

Эта статья продолжает мой доклад на SQA Days-18.

Привет, Хабр! Упомянутая в заголовке тема всё ещё порождает множественные дискуссии и недопонимание между системными администраторами. В своей статье я постараюсь ответить на следующие вопросы:

1. Что такое SID и каких он бывает типов?
2. Когда наличие двух и более машин с одинаковыми Machine SID будет порождать проблемы? Или, другими словами, когда всё-таки (не)нужно менять Machine SID?
3. Что такое Sysprep и нужен ли Sysprep для клонирования/развёртывания?

Эти вопросы будут рассмотрены в первую очередь в контексте задачи развёртывания/клонирования множества рабочих станций/серверов из одного мастер-образа в пределах одной компании.



В основу рассуждений была взята популярная статья Марка Руссиновича (доступна также на русском языке), которую довольно часто неправильно интерпретируют (судя по комментариям и «статьям-ответам»), что приводит к неприятным последствиям. Добро пожаловать под кат.

Друзья, доброго времени суток.

Честно говоря, уже устал поддерживать версии приложений на серверах и делать изменения в БД врукопашную. Использую свои скрипты установки — те же программы, за которыми тоже надо следить самому и править в разных обстоятельствах, типа добавления нового сервера или подготовки новой виртуалки тестировщикам. Захотелось посмотреть, какие есть цивилизованные решения для таких задач. Хочу поделиться первым опытом работы в среде автоматизации процесса развертывания софта – Serena Deployment Automation (SDA) — продукт бесплатен при условии использования на не более 5 серверах.

Коротко для тех, кто спешит

Утилита FTP Deployment: написана на php, принимает в качестве параметра путь к конфигу и выкладывает файлы на удаленный сервер, довольно быстро и хорошо.

Долго и подробно для тех, кому интересно

Все мы любим классные и удобные методы деплоя с помощью capistrano, rsync или, на худой конец, git pull. А если надо выкладывать проекты на shared-хостинг?

Да, некоторые провайдеры предоставляют ssh и git. Но, прямо скажу, их немного.

Однажды я вдруг понял, что привык к хорошему, и ненавижу выкладывать проекты через (S)FTP: не залился какой-то файл; надо вспомнить, где лежат конфиги; вот эту папку не надо выкладывать вообще; вот тут надо проверить права. Думаю, многие этот список легко продолжат.

Привет, Хабраюзеры!
Мы – небольшая команда разработчиков из четырёх человек, и хотим представить на ваш суд свою PaaS, аналог Heroku.

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

Попробовав Heroku в качестве решения, мы поняли, что такое качество и удобство. Единственное, что кусалось – цены. Поэтому около 4-х месяцев назад мы поставили цель сделать свою собственную платформу. И мы ее сделали. Знакомьтесь: Dokkur – первый полноценный PaaS из России!

Мы уже обсуждали сборку и развёртывание приложений Elixir(перев: с помощью exrm): как осуществлять миграции поверх релиза или как работать с переменными среды. Пришло время открыть для себя ещё один инструмент, который поможет развёртывать Elixir приложения.

Практика развёртывания Elixir приложений и дальнейшее отслеживание их работы на нодах с помощью Exrm позволяет нам чувствовать себя гораздо увереннее в вопросах управления релизами в production. Однако возникает следующий вопрос: как управлять самим процессом развёртывания? Конечно, мы можем воспользоваться Capistrano, особенно если в мир Elixir мы пришли из Rails. Но посмотрим на цитату из Edeliver README:

edeliver основан на доставке и предоставляет bash-скрипт для сборки и развёртывания Elixir и Erlang приложений, а так же позволяет совершать "горячее" обновление кода.

Пытаться организовать весь процесс развёртывания вручную — это жёсткая головная боль с кучей повторяющегося кода. А вот использование Edeliver для развёртывания оказалось очень простым с первой же попытки! В конце концов, весь процесс развёртывания уместился в один меленький bash-скрипт:

#!/bin/bash -ex

BRANCH=${1:-master};

mix edeliver build release --branch=BRANCH --verbose
mix edeliver deploy release to production --verbose
mix edeliver start production --verbose
mix edeliver migrate production up --verbose

Скорее всего Вам придётся подкрутить этот скрипт под собственные нужды. Мы используем его только для развёртывания в production, но Вы так же можете использовать его и для staging развёртываний. Описание того, как всё это работает — под катом.

В данной статье речь пойдет об истории успеха воображаемого новостного портала, счастливым владельцем которого являетесь вы. К счастью, вы уже храните код проекта на GitLab.com и знаете, что для тестирования можно использовать GitLab CI.
Теперь вам интересно, можно ли пойти дальше и использовать CI еще и для развертывания проекта, и если да, то какие возможности при этом открываются.

Чтобы не привязываться к какой-либо конкретной технологии, предположим, что ваше приложение является простым набором HTML-файлов, никакого выполнения кода на сервере, никакой компиляции JS assets. Деплоить будем на Amazon S3.

У автора нет цели дать рецепты для конкретной технологии в этой статье. Наоборот, примеры кода максимально примитивны, чтобы слишком на них не зацикливаться. Смысл в том чтобы вы посмотрели на фичи и принципы работы GitLab CI в действии, а потом применили их для вашей технологии.