В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «1С:Предприятие 8».

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

Термины и определения

Под миграцией данных принято понимать конечную последовательность работ, проект, направленный на разовое массовое перемещение данных из систем-источников (исторические системы) в систему-приёмник. При этом эксплуатация этих данных в системах-источниках прекращается.

Следует отличать миграцию данных от интеграции данных. Интеграция, в отличие от миграции - это постоянная часть архитектуры IT, и ответственна за потоки данных между различными системами и хранилищами данных - и является процессом, а не деятельностью по осуществлению проекта.

Схема миграции в общем случае выглядит следующим образом:

Рис. 1

Исторические системы - базы данных компании Заказчика, которые планируется полностью или частично заменить при внедрении новой системы.

Система-приёмник - целевая система, произвольная конфигурация «1С:Предприятие 8».

Исходные данные - данные, выгруженные из исторических систем в произвольный формат xls -файлов. В данном случае формат xls представляется, как один из самых удобных, поскольку возможность выгрузки в xls -файл присутствует во многих учетных системах «предыдущих поколений».

Как современную альтернативу в качестве транспорта возможно рассматривать формат xml -файлов.

Также существуют варианты использования промежуточной базы данных.

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

Данные для загрузки - данные, предназначенные для загрузки в систему-приёмник. В данной статье, так же как и исходные данные, рассматривается xls -формат.

Шаблоны данных для загрузки - описание таблиц данных для загрузки в целевую систему.

Этапы миграции

Рассмотрим поэтапно процесс подготовки и проведения миграции.

К организационным этапам миграции можно отнести следующие пункты:

· Определение стратегии миграции. На данном этапе Исполнитель и Заказчик договариваются о технологии проведения миграционных работ;

· Определение состава рабочей группы по миграции. В рабочую группу должны входить специалисты и Исполнителя и Заказчика, знакомые в достаточной степени с работой исторических систем (со стороны Заказчика) и целевой системы (со стороны Исполнителя);

· Предварительный план миграции. План миграции по ходу проекта будет неоднократно корректироваться;

· Периоды дат выгрузки данных из исторических систем, объемы данных. Периоды среза данных для миграций, даты тестовых и итоговой миграций. Данную информацию можно отнести к плану миграции;

· Состав данных, подлежащих миграции. Справочные данные, классификаторы, транзакционные данные, остатки, обороты и пр.;

· Вопросы проверки качества, корректности и целостности данных в процессе миграции и по итогам;

· Вопросы отката к предыдущему состоянию в случае сбоев.

Остановимся подробнее на технологических этапах миграции.

Рис. 2

1.Подготовка шаблонов загрузки данных

Шаблон загрузки данных содержит технические описания таблиц данных для загрузки, алгоритмы и правила загрузки для текущего шаблона.

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

В шаблоне указывается:

· Описание всех полей xls -файла данных для загрузки, включая:

o Имя поля

o Признак обязательности заполнения поля

o Пример заполнения поля

o Примечание

· Описание правил загрузки таблицы целевой системы на основании данных для загрузки (очередность в случае нескольких связанных таблиц, алгоритмы поиска по ключевым полям и т.п.)

· Описание заполнения непосредственно полей таблиц целевой системы в случае, если предусматривается что-либо отличное от переноса данных «один в один» из файла данных для загрузки. Актуально для ссылочных полей, например.

В процессе работ по данному этапу Исполнитель также должен подготовить загрузчик файлов данных для загрузки. В случае работы с файлами xls данная задача не представляет особой сложности.

2.Выявление источников данных

Данный этап может начинаться вместе с предыдущим этапом «1. Подготовка шаблонов загрузки данных».

В рамках данного этапа специалисты Заказчика определяют из каких систем и какие данные могут быть выгружены. Также следует определить какие данные возможно могут понадобиться.

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

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

Тем не менее, на данном этапе нужно постараться выявить как можно больше необходимых данных.

3.Выгрузка исходных данных

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

Наиболее удобным вариантом представляется выгрузка в xls файлы. Многие старые IT -системы поддерживают такой вариант.

Также могут быть варианты выгрузки в csv формат, dbf , xml форматы и прочие.

Стоит отметить, что по тем или иным причинам (вопросы безопасности, например) Заказчик не всегда может предоставить выгрузки данных в полном объеме на этом этапе! Только структура данных и несколько тестовых позиций. Таким образом, может сложиться такая ситуация, что при тестовых и итоговой загрузках будут обнаруживаться некачественные данные в исходных таблицах, что будет приводить к незапланированным ошибкам.

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

4.Мэппинг данных

Мэппинг (data mapping ) - в общем случае процесс сопоставления данных исторических систем и системы-приемника. То есть, исходных данных и данных для загрузки.

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

На данном этапе в полной мере задействуется вся рабочая группа проекта по миграции.

В процессе мэппинга данных необходимо выделить подэтапы мэппинга таблиц и мэппинга полей.

· Мэппинг таблиц, или мэппинг шаблонов - сопоставление таблиц исходных данных и шаблонов данных для загрузки. Соответствие может быть как 1:1, так и N :N . В результате данной работы составляется и поддерживается реестр мэппинга таблиц. Данный подэтап необходим для следующего подэтапа мэппинга полей и для отслеживания общего состояния дел по мэппингу.

· Мэппинг полей - сопоставление полей таблиц в рамках уже определенного мэппинга таблиц. Результатом данной работы является реестр мэппинга полей.

В рамках данного этапа также следует провести возможные работы по нормализации данных.

5.Подготовка правил трансформации

В отличие от предыдущих этапов, данный этап - технический и предполагает работу разработчика Исполнителя.

На основании согласованных реестров мэппинга полей специалисты Исполнителя разрабатывают правила трансформации данных.

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

При этом требования к данной среде включают в себя:

· Удобство и быстрота разработки правил трансформации;

· Скорость конвертации данных. Файлы на входе и на выходе могут быть и в сотни тысяч строк!

· Возможность работать с несколькими входными файлами одновременно;

· Возможность сохранения правил трансформации в отдельные файлы.

Для своих проектов миграции мы разработали специализированное АРМ разработчика, взяв за основу стандартную обработку «Консоль запросов» 1С.

Обработка «Консоль запросов» была доработана для возможности делать прямые запросы к файлам xls .

Приведем пример объединения двух исходных xls -файлов Сотрудники. xls

и Операции. xls со страницами:

Списания

и Поступления :

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

Технологическая последовательность операций трансформации здесь выглядит следующим образом:

С помощью языка запросов Access SQL (дающего существенные дополнительные возможности, по сравнению с языком запросов 1С) создается первоначальный запрос, извлекающий данные из файла xls в среду 1С. При этом уже на данном этапе возможны различные проверки и нормализации данных.

Технология доступа к данным ADO обеспечивает высокую скорость работы.

Рис. 3

2.Запрос на языке 1С - основной запрос, реализующий алгоритм мэппинга полей. А также: обогащение загружаемых данных данными из базы 1С, перегруппирование, объединение с результатами запросов к другим исходным xls -файлам и пр.

3.Постобработка результата запроса 1С при необходимости. Реализуется с помощью скрипта на языке 1С.

Для примера здесь реализуется добавление строки «ИТОГО» по колонкам сумм.

4.Запись итогового набора данных в xls -файл.

В общем случае на выходе мы получаем итоговые файлы для загрузки в целевую базу данных 1С.

Также данный инструмент позволяет сохранять правила конвертации данных в отдельный xml файл:

Кроме того, реализована возможность работать в пакетном режиме , что особенно актуально при большом количестве разнородных мигрирующих данных.

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

Следует отметить, что перед итоговой миграцией обязательно следует провести несколько тестовых. В ходе тестовых миграций Исполнитель совместно с Заказчиков выявляют:

· ошибки конвертации, ошибки загрузки данных

· проводят предварительную оценку качества загружаемых в целевую систему данных

· по итогам тестовых миграций составляют/актуализируют план итоговой миграции

7.Выверка данных

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

· Совпадения итоговых сумм по остаткам, по документам;

· Количественные совпадения, например количество ОС;

· Корректность заполнения отдельных выборочных сущностей;

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

Например:

· Проверка на дубли по ключевым полям. Можно и нужно проводить еще на исходных данных;

· Приведение типов полей;

· Ссылочная целостность;

· Математические нестыковки. Например, проверка на незаполненные численные поля, на которые запланировано деление при трансформации;

· В целом, проверки обязательной заполненности полей;

· Замена некорректных символов. Например, английские символы в кириллических полях («о», «а», «е» и т.п.) Особенно актуально это для ключевых полей!

· Проверка значений строковых полей на соответствие типов системы-приемника (Ограничения по длине)

После завершения итоговой миграции согласно заранее определенной стратегии миграции и плану миграции принимается решение о дальнейшей эксплуатации исторических систем.

Часто эксплуатация завершается сразу после финальных сверок данных и фиксирования успешности проведенной миграции - пользователи новой системы уже не ведут учет параллельно в двух системах, а полностью переходят в новую систему. При этом доступ к старой системе сохраняется в режиме чтения.

В некоторых случаях может происходить параллельная работа двух систем на время опытной эксплуатации (ОЭ) и даже более этого периода. Вопрос параллельной работы пользователей в двух системах тесно связан с вопросом возможности отката к старой системе, в случае если миграция (или же, в целом, работа новой системы!) будет признана неудовлетворительной.

Заключение

В заключении хотелось бы отметить, что когда речь идёт о миграции больших транзакционных систем, к которым относятся и многие конфигурации «1С:Предприятия», переход на новую систему может быть весьма трудоёмким.

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

Последнее обновление: 31.10.2015

Нередко возникает ситуация, когда модель меняется. Например, мы решили внести в нее новые свойства. Но при этом у нас уже имеется существующая база данных, в которой есть какие-то данные. И чтобы без потерь обновить базу данных ASP.NET MVC предлагает нам такой механизм как миграции. Например, у нас есть простая модель User:

Public class User { public int Id { get; set; } public string Name { get; set; } }

Соответсвенно есть контекст данных, через который мы работаем с бд:

Users { get; set; } }

И допустим, у нас есть вся инфраструктура для работы с этой моделью - представления, контроллеры, и у нас есть уже в базе данных несколько объектов данной модели. Но в какой-то момент мы решили изменить модельную базу приложения. Например, мы добавили еще одно поле в модель User:

Public class User { public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } }

Кроме того, мы решили добавить еще одну модель, например:

Public class Company { public int Id { get; set; } public string Name { get; set; } }

Таким образом, контекст данных у нас уже меняется следующим образом:

Public class UserContext: DbContext { public UserContext() : base("DefaultConnection") { } public DbSet Users { get; set; } public DbSet Companies { get; set; } }

Мы можем добавить в представления для модели User дополнительное поле для свойства Age, можем создать контроллер и представления для новой модели, но при попытке добавить новый объект в бд, мы будем получать ошибку:

Контекст данных изменился, и теперь нам надо провести миграцию от старой схемы базы данных к новой. И первым делом найдем внизу Visual Studio окно Package Manager Console, введем в нем команду: enable-migrations и нажмем Enter:

После выполнения этой команды Visual Studio в проекте будет создана папка Migrations, в которой можно найти файл Configuration.cs . Этот файл содержит объявление одноименного класса Configuration, который устанавливает настройки конфигурации:

Namespace MigrationApp.Migrations { using System; using System.Data.Entity; using System.Data.Entity.Migrations; using System.Linq; internal sealed class Configuration: DbMigrationsConfiguration { public Configuration() { AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; } protected override void Seed(MigrationApp.Models.UserContext context) { } } }

В методе Seed можно проинициализировать базу данных начальными данными. Теперь нам надо создать саму миграцию. Там же в консоли Package Manager Console введем команду:

PM> Add-Migration "MigrateDB"

После этого Visual Studio автоматически сгенерирует класс миграции:

Namespace MigrationApp.Migrations { using System; using System.Data.Entity.Migrations; public partial class MigrateDB: DbMigration { public override void Up() { CreateTable("dbo.Companies", c => new { Id = c.Int(nullable: false, identity: true), Name = c.String(), }) .PrimaryKey(t => t.Id); AddColumn("dbo.Users", "Age", c => c.Int(nullable: false)); } public override void Down() { DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); } } }

В методе Up с помощью вызова метода CreateTable создается таблица "dbo.Companies" и производится ее настройка: создание столбцов, установка ключей. И также добавляется новый столбец Age в уже имеющуюся таблицу. Метод Down удаляет столбец и таблицу на случай, если они существуют. Фактически эти методы равнозначные выражению ALTER в языке SQL, которое меняет структуру базы данных и ее таблиц.

И в завершении чтобы выполнить миграцию, применим этот класс, набрав в той же консоли команду:

PM> Update-Database

После этого, если мы посмотрим на состав базы данных, то увидим, что к ней были применены изменения в соответствии с выполненной миграцией:

Итак, миграция выполнена, и мы можем уже использовать обновленные модели и контекст данных.

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (, , и др.), так и в Интернете (преимущественно, англоязычном).

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

Терминология

Структура базы данных - совокупность всех объектов БД и статических данных. Пользовательские данные в понятие структуры БД не входят.

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

Миграция , в данном контексте, - обновление структуры базы данных от одной версии до другой (обычно более новой).

В этом смысле термин миграция, похоже, используется во многих источниках (особенно этому поспособствовали миграции из gem"а Active Record, входящего в состав Ruby on Rails). Однако при использовании этого термина возникает двусмысленность: человек, который не знает контекста, скорее подумает, что речь идет о переносе базы данных с одной СУБД на другую (MySQL => Oracle), а то и вовсе о миграции процессов/данных между нодами кластера. Поэтому предлагаю в случаях, когда контекст неочевиден, использовать более точный термин: версионная миграция баз данных.

Зачем это нужно?

Версия базы данных должна соответствовать версии приложения

1. Изменить тип поля на nullable:

ALTER myTable CHANGE COLUMN myField myField VARCHAR (255) NULL DEFAULT NULL ;

UPDATE myTable SET myField = NULL WHERE myField = "" ;

Из пункта 3 можно видеть, что приложение и база данных - неразрывные части одного целого. Это означает, что при поставке новой версии приложения в продакшн, нужно обязательно обновлять и версию базы данных, иначе приложение попросту не сможет правильно работать. В данном примере, если до новой версии будет обновлено только приложение, то в какой-то момент произойдет вставка NULL в необнуляемое поле, а это очевидная ошибка.

Таким образом, обновление версии приложения требует корректной версионной миграции базы данных .

Так ли это просто?

Тут снова обратимся к живому примеру. Допустим, программисты в процессе разработки записывают свои изменения структуры и данных БД в отдельный файл в виде SQL-запросов (как DDL -, так и DML -запросов). А при каждом деплое последней версии приложения вы одновременно обновляете до последней версии и базу данных, выполняя запросы из того самого SQL-файла… Но погодите, с какой версии вы обновляете БД до последней версии? «С прошлой»? Но так ли хорошо вы помните, что конкретно из себя представляла прошлая версия (её выпустили 2 месяца назад)? Если нет, то как вы собрались её обновлять? Ведь без точной информации о состоянии структуры и данных выполнить корректную миграцию невозможно: если вы непредумышленно выполните запросы, которые уже когда-то выполнялись, это может привести к потере данных или нарушению их целостности.
Простой пример - замена паролей на их MD5-суммы. Если повторно выполнить такой запрос, то данные можно будет восстановить только из бэкапа. Да и вообще, любые UPDATE "ы, DELETE "ы, и даже INSERT "ы, выполненные повторно, могут привести к крайне нежелательным последствиям. Не говоря уже о несвоевременных TRUNCATE "ах и DROP "ах (хотя такие случаи намного менее вероятны).
Кстати говоря, с этой точки зрения, недовыполнить - не меньшая опасность для работоспособности приложения, чем перевыполнить.

Таким образом, можно сделать вывод, что в процессе версионной миграции все запросы должны выполняться только один раз и, к тому же, в правильной последовательности . Последовательность важна потому, что одни изменения могут зависеть от других (как в примере с обнуляемым полем).

Общие принципы версионной миграции

• единоразовое выполнение каждого изменения (SQL-запроса);
• строго предустановленный порядок изменений.

• чтобы любую версию базы данных можно было обновить до любой (обычно, самой последней) версии;
• чтобы набор SQL-запросов, реализующих миграцию между любыми двумя версиями, можно было получить как можно быстрее и проще;
• чтобы всегда можно было создать с нуля базу данных со структурой самой последней версии. Это очень полезно как в процессе разработки и тестирования, так и при развертывании нового продакшн-сервера;
• чтобы, в случае работы над разными ветками, при последующем их слиянии ручное редактирование файлов БД было сведено к минимуму;
• чтобы откатить БД на более раннюю версию было так же просто, как и обновить на более новую.

Основание миграции

Попросту говоря, основание - это дамп структуры базы данных для версии, которая принята за базовую. Имея на руках основание , впоследствии всегда можно будет создать БД с нуля. После применения к этой БД всех миграций, созданных в процессе разработки, получим БД со структурой самой последней версии.

Метод инкрементных изменений

Структура файлов

Database
|- Baseline.sql
|- 0001.03 .01.sql
|- 0002.03 .01.sql
|- 0003.03 .01.sql
|- 0004.03 .02.sql
|- 0005.03 .02.sql
|- 0006.03 .02.sql
"- 0007.03 .02.sql

В любом случае, самый первый файл, который появится в такой папке, - основание (Baseline.sql). После этого любое изменение в БД сабмиттится в репозиторий в виде нового файла-миграции с именем вида [номер файла].[версия].[подверсия].sql .

Фактически, в этом примере в имени файла содержится полный номер версии БД. То есть после выполнения файла-миграции с именем 0006 .03.02.sql база данных обновится с состояния, соответствующего версии 03.02.0005 , до версии 03.02.0006 .

Хранение истории версий

CREATE TABLE MigrationHistory
Id INT ,
MajorVersion VARCHAR (2),
MinorVersion VARCHAR (2),
FileNumber VARCHAR (4),
Comment VARCHAR (255),
DateApplied DATETIME ,

PRIMARY KEY (Id)
)

В файле Baseline.sql в эту таблицу нужно будет добавить первую запись:

INSERT INTO
MigrationHistory (MajorVersion, MinorVersion, FileNumber, Comment, DateApplied)
VALUES ("03" , "01" , "0000" , "Baseline" , NOW())

Автоматическое выполнение миграций

Выполнять миграцию БД автоматически довольно просто, т.к. номер последней выполненной миграции можно получить из таблицы MigrationHistory, а после этого остается только применить все файлы с бо́льшими номерами. Сортировать файлы можно по номеру, поэтому с порядком выполнения миграций проблем не будет.

На такой скрипт также возлагается задача добавления записей о выполненных миграциях в таблицу MigrationHistory.

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

Плюсы, минусы, выводы

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

Метод идемпотентных изменений

Под идемпотентностью понимается свойство объекта оставаться неизменным при повторной попытке его изменить.
В тему вспоминается смешная сцена из «Друзей»:)

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

Эту идею проще всего уяснить на примере. Допустим, вам нужно добавить в БД новую таблицу. Если вы хотите, чтобы в том случае, если она уже существует, при выполнении запроса не возникло ошибки, - в MySQL для этих целей есть краткий синтаксис:

CREATE TABLE IF NOT EXISTS myTable
id INT (10) NOT NULL ,

PRIMARY KEY (id)
);

IF NOT EXISTS
SELECT *
FROM information_schema.tables
WHERE table_name = "myTable"
AND table_schema = "myDb"
THEN
CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);
END IF ;

Стоит отметить, что в MySQL по какой-то причине запрещено выполнять DDL -запросы внутри условных выражений. Но этот запрет легко обойти - достаточно включить все подобные запросы в тело хранимой процедуры:

DELIMITER $$

CREATE PROCEDURE sp_tmp() BEGIN

IF NOT EXISTS
--
-- Условие.
--
THEN
--
-- Запрос, изменяющий структуру БД.
--
END IF ;

END ;
$$

CALL sp_tmp();

DROP PROCEDURE sp_tmp;

Что за птица такая - information_schema?

Полный перечень таблиц с подробной информацией об их предназначении можно посмотреть в тексте стандарта . Краткий перечень можно увидеть в уже упоминавшейся выше статье Фила Хэка . Но самый простой способ, конечно же, - просто открыть эту базу данных на любом рабочем сервере БД и посмотреть, как она устроена.

Пример использования

Пример того, как в этом случае может выглядеть папка с sql-файлами:

Database
|- 3.01
| |- Baseline.sql
| "- Changes.sql
"- 3.02
|- Baseline.sql
"- Changes.sql

Предположим, в процессе разработки в разное время программистам понадобились следующие изменения в БД:
a) создать таблицу myTable;
b) добавить в нее поле newfield;
c) добавить в таблицу myTable какие-то данные.

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

К примеру, один из разработчиков создал на своей локальной копии БД таблицу myTable, записал изменение a) в хранящийся в общем репозитории кода файл Changes.sql, и на какое-то время забыл о нём. Теперь, если он выполнит этот файл на своей локальной БД, изменение a) будет проигнорировано, а изменения b) и c) будут применены.

Плюсы, минусы, выводы

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

Метод уподобления структуры БД исходному коду

Основная идея этого метода отражена в заголовке: структура БД - такой же исходный код, как код PHP, C# или HTML. Следовательно, вместо того, чтобы хранить в репозитории кода файлы-миграции (с запросами, изменяющими структуру БД), нужно хранить только актуальную структуру базы данных - в декларативной форме.

Пример реализации

В файле CreateDatabase.sql будут храниться команды CREATE TABLE , CREATE PROCEDURE , и т.д., которые создают всю базу данных с нуля. При необходимости изменений структуры таблиц, эти изменения вносятся непосредственно в существующие DDL-запросы создания таблиц. То же касается изменений в хранимых процедурах, триггерах, и т.д.

К примеру, в текущей версии репозитория уже есть таблица myTable, и в файле CreateDatabase.sql она выглядит следующим образом:

CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);

CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
newfield INT(4) NOT NULL ,
PRIMARY KEY (id)
);

Выполнение миграций между версиями

Миграция на свободное ПО подобна миграции на более новую операционную систему. Как пример, можно упомянуть появление первых вариантов Windows в нашей стране. Не менее яркий пример – миграция на Windows NT, идеология работы в которой резко отличалась от Windows 9x. Можно привести еще один пример -- каждая новая версия пакета MS Office отличается от предыдущей не только отличиями в интерфейсе, но и форматами файлов. Итак, задача миграции является актуальной даже в таком случае, когда используется ПО от единственного производителя.

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

создание рабочей группы (кто делает)

При осуществлении миграции необходимо предусмотреть решение вопросов как технического, так и нетехнического характера.

Важно рассмотреть правовые проблемы, которые в последнее время черезвычайно актуально стоят для некоторых стран СНГ, в частности, Украины. В некоторых случаях осмысленно обсудить административные задачи взаимоотношений "работодатель-пользователь-администратор". Исторически сложилось, что эти отношения недостаточно регламентированы внутрикорпоративными правилами и инструкциями.

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

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

Любой проект, в том числе проект миграции, может столкнуться с недооценкой человеческого фактора. Естественно, потребуется применение методов управления человеческими ресурсами. Большинство известных автору системных администраторов и ИТ менеджеров не являются специалистами в областях управления персоналом или финансов. Подобную комплексную задачу невозможно решить силами одного ИТ-департамента.

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

Целью проекта является построение экономически оправданной ИТ-инфраструктуры. Хорошим кандидатом на должность руководителя рабочей группы будет топ-менеджер предприятия или организации, к примеру – финансовый директор. Естественно, в данную группу входит начальник ИТ-департамента, который владеет видением всей ИТ-инфраструктуры как на данный момент, так и в перспективе. В составе группы обязателен опытный системный администратор, желательно с опытом эксплуатации свободного ПО. Размер группы невозможно оценить – в некоторых случаях привлекаются при необходимости иные сотрудники фирмы. Возможно привлечение стороннего консультанта с опытом, или – специализирующейся на подобных решениях фирмы. Результатом работы данной группы является развернутый план миграции с оценкой стоимости миграции. Либо – пояснения неэффективности миграции на свободные решения для организации.

исследование (что есть)

Первым этапом должен быть аудит – описание существующей (унаследованной) системы.

Не секрет, что, при годами применявшейся "авральной" информатизации без учета окупаемости затрачиваемых на ПО средств результатом являлись, как правило, не только экономически, но и технологически несбалансированные системы. Аудит программного обеспечения предприятия представляет собой ревизию установленных программ, определение соответствия их требованиям бизнеса.

Результатом процесса аудита являются:

Описание технических характеристик установленного ПО;

Список выявленных рисков, связанных с использованием нелицензионного ПО;

Подсчет стоимости приобретения лицензий на установленное ПО;

Подсчет стоимости удаления нелицензионного и установки лицензионного ПО;

Определение целесообразности дальнейшего использования ПО;

Список выявленных рисков, связанных с использованием ПО;

инвентаризация ПО

Некоторые исследования показывают, что большинство руководителей организаций большее внимание уделяют функциональности используемого ПО и гораздо меньше – соблюдению прав на используемые продукты.

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

Инвентаризация ПО позволяет выявить нелицензионное ПО в организации. Следует подчеркнуть, что данное мероприятие всегда выгодно. Результатом инвентаризации можно воспользоваться для оценки затрат на легализацию ПО как с использованием свободного, так и с использованием несвободного ПО.

Руководители организаций часто заинтересованы в четком финансовом планировании затрат на использование и развитие программного обеспечения. Заинтересованность топ-менеджеров в такой подобной детализации вполне понятна – топ-менеджмент компаний заинтересован в превращении ПО в актив компаний, который учитывается, контролируется и развивается аналогично другим видам активов.

Аудит ПО – процедура, занимающая, как правило, достаточно много времени, требующая на этапе анализа информации высокой квалификации персонала и знание различной специфической информации. Рекомендацией может быть обращение в специализирующуюся на данных услугах фирму. Тем не менее, вполне возможно провести аудит силами ИТ департамента.

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

Можно рассмотреть два варианта проведения аудита. Первый вариант – полный аудит, про котором производится исследование всех вычислительных средств, локальной сети и переферии. Достоинство данного метода – высокая точность, недостаток – большая стоимость, высокие затраты времени и неудобство для пользователей. Дополнительными достоинствами данного метода является возможность выявить самостоятельно установленное пользователями ПО и изучить требования пользователей к ПО на их рабочих местах, используя специально подготовленные анкеты. Второй вариант – аудит некоторых типичных вычислительных средств, локальной сети и переферии. При этом выбор объектов аудита диктуется, как правило, функциональными обязанностями пользователей. Такой метод аппроксимации значительно удешевляет стоимость инвентаризации, но обладает большой погрешностью.

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

Для средних и крупных можно рекомендовать использование специализированного ПО или пригласить стороннюю организацию, специализирующуюся на подобных услугах. В процессе создания документа были проведены работы по обзору средств автоматической инвентаризации программного и аппаратного обеспечения (известны программы GASP, PC inventory, MSIA). Рекомендацией может стать eXponent Navigator (http://www.e-x.ru/pages/expnav.html), производства eXponent.

Exponent Navigator

Продукт предназначен для ревизии оборудования и программного обеспечения по сети. Сведения о компьютерах включают в себя данные о комплектующих (процессор, материнская плата, винчестеры, модули памяти, видео-карта, сетевые карты, принтера и другие устройства), операционной системе, драйверах и программном обеспечении.

По утверждению создателей программы, после организации автоматического сбора сведений о компьютерах есть возможность просматривать и упорядочивать эту информацию, подготавливать печатные отчеты и веб-публикации, выгружать данные в Microsoft Excel, XML и другие форматы. Возможности:

Автоматическая диагностика конфигурации компьютеров;

Автоматический сбор информации о компьютерах по сети;

Определение установленного оборудования;

Определение установленных программ;

Определение файловых характеристик;

Расширенные возможности сортировки, поиска и отбора данных;

Подготовка печатных отчетов;

Экспорт данных в MS Excel;

Автоматическая генерация веб-публикаций.

В бесплатном варианте программы существует ограничение – учет до 25 компьютеров; стоимость лицензии составляет $1 за 1 компьютер.

проектируем (что хотим)

Обработанные результаты исследования существующей системы являются основанием для моделирования новой, целевой системы. Этот вопрос черезвычайно важен и сложен. Усложняет рассмотрение данного вопроса и исторически сложившийся недостаток знакомства со свободным ПО, в частности Linux, большинства ИТ менеджеров и системных администраторов.

Существует масса литературы, в том числе русскоязычной, о Linux, в которой описано преимущество этой платформы с технологической точки зрения. Однако, все эти преимущества имеют значение вместе с главным вопросом – существованием широкого спектра прикладного ПО разного направления. Достаточно давно и широко распространен миф о том, что под платформу Linux существует ограниченное количество прикладного программного обеспечения для корпоративного пользования, в том числе офисной автоматизации. В подавляющем большинстве эти мифы создаются и подпитываются создателями и продавцами проприетарного ПО и имеют мало общего с действительностью. Развенчание данного мифа не является главной целью данной книги. Тем не менее, стоит заметить, что, к примеру, широта прикладного ПО является абсолютным фантомом с учетом сложившихся исторически стандартов на обмен документов. Так, к примеру, фактическим стандартом офисного редактора является Microsoft Office, редактором растровой графики – Adobe Photosop, а в качестве векторной графики черезвычайно распространен Corel Draw.

Еще одним вопросом является, зачастую, избыточная функциональность проприетарных продуктов, продиктованная не потребностями рынка, а мнением маркетологов. И за эту избыточную функциональность пользователь выплачивает достаточно большие деньги: стоимость лицензии на право использования программ, повышающуюся сложность эксплуатации и повышенные требования к аппаратному обеспечению.

В последнее время ситуация изменяется – появляется масса информации, посвященной прикладному применению Linux. Вероятно, наилучшим материалом будет данный документ:-), в котором планируется осветить множество административных и технических вопросов.

Однако, в данный момент документ только создается и информацию можно найти в разных источниках. Невозможно пройти мимо материалов Valery V. Kachurov, Несов Артем “Аналоги Windows-программ в Linux – таблица соответствий.” (http://linuxshop.ru/linuxbegin/win-lin-soft/). Этот ресурс содержит массу ценной информации. К сожалению авторы, кажется, забросили этот труд. Данный раздел сайта регулярно недоступен, но копию таблицы можно найти по адресу http://www.blif.net/modules.php?name=LinWin. Можно посоветовать ресурсы Open Source Applications Foundation
(http://www.osafoundation.org/), особенно http://www.osafoundation.org/desktop-linux-overview.pdf.

Результатом являются:

Создания прототипа рабочих станций;

Подсчет стоимости лицензий на предлагаемое ПО;

Обучения пользователей;

Создание примерного календарного плана внедрения;

Список рисков при внедрении свободного ПО;

Поддержки свободных решений;

Подсчет экономической эффективности новой системы на срок до пяти лет.

пилотный проект (проверка боем)

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

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

На данном этапе также производится обучение системных администраторов и конечных пользователей: предоставляются прототип методических материалов, документация, ресурсы в сети Интернет. Рекомендуется пользователей, которые участвуют в пилотном проекте «разгрузить» и дать возможность часть времени использовать на освоение новой системы.

Экспериментальный этап особенно востребован:

Если не была доказана возможность миграции пользователей от унаследованной системы к новой системе;

Если есть пользовательский скептицизм, который будет способен затормозить процесс миграции;

Организация испытывает недостаток корпоративной культуры (что, к сожалению распространено на территории СНГ);

Если есть ограниченные ресурсы для крупномасштабной миграции;

Организация большая, и в экспериментальный проект не вовлечено много пользователей;

Если унаследованные проприетарные системы стремительно эволюционировали как в - техническом плане, так и в снижении стоимости;

Не выяснен полностью экономический эффект миграции.

Чтобы преуспеть, пилотный проект:

Не должен относиться к критическому участку бизнеса;

Должен быть достаточно важен для бизнеса;

Не должен требовать черезмерного ресурса людей, которые уже ограничены во времени;

Должен иметь существенную группу поддержки;

Должна быть обеспечена обратная связь с пользователями (системы Help Desk);

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

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

Описание прототипа рабочих станций;

Описание специфических настроек пользователя:

Средние затраты на развертывание типов станций;

Переноса данных из наследованной системы в новую;

Обучения пользователей;

Подсчет стоимости внедрения ПО;

Поддержки свободных решений.

планирование (что и как)

1. Создание плана миграции. План миграции должен отвечать на вопросы:

Описание фаз построения системы;

Определение потребностей поддержки;

Описание завершения миграции.

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

2. Описание фаз построения системы. Должна быть сделана оценка фаз построения системы, которые лучше всего поддерживают приоритеты пользовательских потребности.

План должен отвечать на следующий вопросов:

В какой степени и какими этапами система должна быть установлена и развернута, чтобы максимально удовлетворять потребностям пользователей?

Что необходимо для каждой фазы миграции на новую систему от клиентов организации и пользователей системы?

Каково будет воздействие и риск использования системы на каждом этапе приращения?

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

3. Определение потребностей поддержки. Нужно обеспечить оптимальный уровень поддержки, чтобы помочь пользователям в использовании новой системы. Кроме того, пользователи часто требуют, чтобы служба поддержки помогла им понять общие способности(возможности) целевой системы.

Вопросы, которые необходимо решить, включают:

Какого обучения и помощи в эксплуатации пользователи будут требовать?

Каков общий уровень поддержки миграции, которая будет требоваться пользователям, чтобы гарантировать успешную миграцию?

Как достигнуть принятия целевой системы пользователями и избежать сопротивления пользователей внедрению новой системы?

Каким образом будут сообщаться клиентам и пользователям неизбежные изменения в особенностях систем и услугах?

Возможна ли поддержка свободного решения ИТ подразделением организации или лучшим вариантом будет аутсорсинг?

План миграции должен сосредоточиться на решении этих вопросов, планируя поддержку пользователей в областях:

Система сообщения неприятностей;

Службы технической помощи для новых систем;

Техническая помощь пользователям, мигрирующим к новым системы;

Руководства пользователей на переходной и последующий периоды;

Обучение для пользователей в изучении и приспосабливании к новой системе, к выполнению тех же самых типов задач;

Возможность испытания использования новых систем;

Демонстраций использования новых систем, чтобы показать существующим пользователям унаследованных систем, как новая система работает и как они могут исполнять сопоставимые задачи;

Преодоления текущих эксплуатационных проблем.

На этапе обучения пользователей уделите особое внимание тем, кто является приверженцем старой системы и/или противником новых систем.

4. Описание завершения миграции. После окончания каждой новой фазы развертывания и обучения, разработчики и внедренцы должны гарантировать, что пользователи максимально комфортно мигрируют к новой целевой системе. План миграции должен предусмотреть, чтобы ускорить усилие миграции и к удалению унаследованной системы как только возможно.

Необходимо предусмотреть дополнительное усилие, которое может быть необходимо для "последних адептов" и других пользователей, кто испытывают непредвиденные проблемы. Другой аспект этой деятельности оценивает время и стоимость, чтобы закончить переход всех пользователей к новой системе и к удалить старые системы, построенные на нелицензионном проприетарном ПО.

Руководство организации, разработчики и внедренцы должны рассмотреть включение нескольких подходов, чтобы помогать мигрировать пользователям унаследованных систем:

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

Установить стимулы к действиям полностью перейти на новую свободную систему и устранить зависимости от унаследованных систем;

Предусмотреть помощь (программное обеспечение и дополнительный персонал) для преобразования унаследованных данных в новую систему; - порядок вывода из эксплуатации унаследованных систем;

Архивирование данных унаследованных систем и их хранение.

миграция (делаем)

Все, что остается на последнем этапе – работать согласно плану.

Активно управляйте и контролируйте процессы миграции:

Установите критерии измерения и отслеживайте этапы миграции и затраты ресурсов на миграцию;

Делайте периодические обзоры ситуации и ознакомливайте с ними, согласно полномочий и организационной политикой, заинтересованных людей (руководство, менеджеров проектов и спонсором);

Устанавливайте систему отслеживания (tracking), чтобы управлять продвижением процессов (прогрессом), проблемами, решениями, и другими деловыми вопросами, которые относятся к планированию миграции и выполнению планов.

Вадим Машков, UA-FOSS, [email protected]

Миграция данных

Миграция данных – многоэтапный процесс перемещения баз данных, программного обеспечения, финансовых или других бизнес-данных между различными ИТ-системами. Продуманный план перехода позволит плавно перенести базы данных, программы и приложения, а также любые иные данные в облако провайдера без неожиданных рисков простоя бизнес-процессов. DEAC обеспечивает надежный пошаговый перенос данных из собственного или размещенного у третьих лиц ИТ-оборудования в инфраструктуру дата-центров DEAC .

Пошаговый план миграции
Эксперты DEAC контролируют и документируют весь процесс миграции данных, поддерживая прозрачность и эффективность проекта

Миграция в облако или сервер
Вне зависимости от географического расположения и используемых систем хранения данных, DEAC обеспечит полную интеграцию данных без риска потери данных

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

Дата-центры стали критическим элементом бизнеса, когда для его развития требуется надежная миграция данных и перемещение рабочих нагрузок. Миграция между дата-центрами, консолидация, план аварийного восстановления или перестройка облачной инфраструктуры - DEAC обеспечит опытную команду, инструменты и знания для успешного проведения проекта. DEAC сотрудничает с ведущими мировыми поставщиками и вендорами, обеспечивая клиенту единую точку контакта на всех этапах миграции.
Такой подход гарантирует выгодную, защищенную от рисков стратегию миграции как для виртуальной, так и для физической миграции данных.

Выберите опытного поставщика услуг и получите качественный
и бесперебойный процесс миграции данных.

Многолетний опыт DEAC , сертифицированные эксперты и гибкая инфраструктура гарантируют надежную миграцию данных в дата-центры повышенного уровня безопасности. Для обеспечения непрерывности процессов, особое внимание экспертов DEAC во время миграции направлено на успешное перемещение, целостность, приватность и безопасность данных и приложений. Ваши данные могут быть размещены как в частном , публичном или гибридном облаке , так и на выделенном или виртуальном сервере , с высокоскоростными соединениями. Наши эксперты помогут подобрать индивидуальное или уже готовое к работе решение, которое соответствует требованиям вашей ИТ-системы.

Миграция облака

Миграция базы данных

Миграция приложений

DEAC предоставляет полный процесс миграции из собственной инфраструктуры клиента в облако или из одной облачной среды в другую (cloud-to-cloud migration ). Перемещение данных, информационных хранилищ, приложений, и других ИТ-элементов бизнеса в облако позволяет сохранить безопасность и доступность без неожиданных простоев процессов. DEAC использует специализированные облачные инструменты для полноценной интеграции данных или систем.

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

Приложения имеют собственную архитектуру данных и специфическую конфигурацию платформы, которая может отличаться от новой среды, поэтому при миграции собственных приложений необходимо создавать пошаговый план перехода. Комплексный подход перенесения приложений позволяет сохранить важные данные, не отставать от плана и придерживаться проектного бюджета. Для каждого клиента DEAC разрабатывает индивидуальный план миграции, который соответствует необходимому объему данных, типу приложений, исходным технологиям и выбранной ИТ-инфраструктуре заказчика.

УЗНАТЬ БОЛЬШЕ О ДРУГИХ УСЛУГАХ: