В развитието на съвременните уеб приложения е трудно да се подценяват ползите от използването на система за контрол на версиите. Що се отнася до файловете на разработения продукт, ние сме в състояние да проследят всички етапи на производството, по всяко време, тъй като първата одита. Инструменти, които ни помагат в това, досега популяризирана, се считат в задължителен в развитието, а в много случаи успешното производство без използването им невъзможно по принцип. И какви възможности имаме, когато е необходимо, за да се проследяват промените в файлове и бази данни на проекта? В рамките на разреза, аз ще споделя информация за съществуващите съоръжения, с които бях чел.
1. PHP SQLDIFF, а.к.а. SQLDiff
А PHP-скрипт, който ви позволява да видите пълният размер на разликата (структура, така и данни) между всеки две таблици на базата данни. Инструментът не разполага с никакви средства за автоматична синхронизация или структура на данни - е осигурена визуална информация. Друг съществен недостатък - способността да се свързва само с база данни, която може да бъде достъпен директно (не чрез SSH-тунел). Бавна скорост на големи обеми от данни (работа чрез круша-модул, който не притежава нито нови скорост). Мисля, че сценарият е много полезна за предприемача в случаите, когато трябва да разберат визуалното представяне на различията между различни таблици - има удобен интерфейс, бърза настройка. Характеризират повече като полезен инструмент джоб трябва да е идентична за бързо разбиране на кос плочи, които на теория, отколкото като сериозен инструмент, който може да се използва за автоматизиране на процеса на синхронизация.
2. LIQUIBASE
Удобен многофункционален и лесен за използване Migrator база данни структура Java. Аз се убедите сами в това, плюс това, ако се използва заедно с Дженкинс.
Пример (хост1 - сървър, от който да се копират структурата на базата данни; HOST2 - сървър, към който да се премести на структура host1):
Генерира changeset във формат XML, което води до по-нататъшно миграция на структурата на базата данни, за да HOST2 в състояние идентичен хост1.
След миграцията, че има смисъл да се провери отново, че changeset празна.
Той е не само да синхронизирате таблици и полета, но и надписи, ключовете. Не съм сигурен за запомнените процедури - Не съм проверила.
Changeset също може да се образува в други формати - в SQL, в JSON (не само в XML). Образуване changeset'a в SQL ще бъде полезна в случаите, когато средствата са използвани за мигриране на другите комунални услуги.
3. schemasync
Инструмент за синхронизация на структурата на базата данни. За да работите нужната питон и подходящата визия за MySQL.
От основните разлики с liquibase:
- schemasync chenzhset не само създава, но и файла, което позволява промени намаление на цените (най-важният и най-ценното предимство, макар че, по мое мнение, не премахват необходимостта да направите резервно копие преди синхронизация)
- liquibase ви позволява не само да се chenzhset, но незабавно да започне миграцията означава самата полезност. Може би не е убиец-функцията, но все пак удобно и полезно
синхронизация на данни 4. MAATKIT
Приложение 1:
Тези инструменти имат голям недостатък, който е по-малко важно в deploe на производство-сървър, но постоянно напомня за себе си в процеса на развитие - от скоростта на изпълнение. Първоначално задачата беше да се изгради механизъм, който ще автоматизира sihnronizatsiyu между обекти в "разработчиците на веригата - тест сървър - етап - производство». Тъй като (в горната верига) е съвсем проста, за да тествате сървъри - от ресурсите само отнема време, натоварването е минимално. Ако процесът се извършва автоматично по график през нощта, а след това няма значение колко време е било изпълнено, и че, за да не се създава тежест и че сутринта е завършена задачата. Ако синхронизацията е редовен, промени в списъците, никога няма да бъде прекалено големи, и товарът ще бъде незначително. Друго нещо, когато става въпрос за синхронизация между платформата и сървърът на тест разработчик. В този случай, синхронизацията, която работи 01:00, винаги ще има възможно, и ще предизвика неудобство. Тези обстоятелства накарали да синхронизирате средства №5:
5. "Полуавтоматичното синхронизация".
Отношение на описаното по-горе, по-голям (малко по-малко от пълно) на времето, необходимо за формирането на списък с различия. Нанесете един и същ скрипт след това да се отстранят различията - действието достатъчно бързо (отново, не аксиома, но в повечето случаи, в процес на развитие). Това предполага, че е възможно да се работи на потребителя формирането на списъка на различия в и автоматизират само неговото прилагане. Най-очевидният начин намери само две:
а) във всеки продукт, има техники за работа с бази данни - няма значение дали използвате популярна рамка или вашата домашна ядро продукт. Достатъчно, за да улови всички искания (освен ако stuktura интерес - DDL, ако данните са едно и също - актуализира и изтрива, например) в собствената си магазин;
б) ако си рамка (и дори по този грях CMS) не е в състояние да се разширява методите на един клас, работа с базата данни и дори не разполагат с манипулатор събитие в начина на вземане на искането до базата данни, можете да направи разбор на дневника на всички заявки (надявам се, възможност за включване на този дневник е цялата целева софтуера) и записа само необходимите действия от този дневник.
Това "полу-автоматична синхронизация" със създаването на свой собствен регистър на промените има право да съществува, но трябва да насърчава разработчикът да извършват с помощта на тест инструменти, споменати по-горе, след синхронизацията, че маса прави същото (дори ако тя се извършва най-малко по разписание нощта, за да се гарантира, че човешките фактор не е довело до промени в синхронизацията на данни).
Приложение 2:
Резултати от изпитите и не забравяйте да направите резервни копия!
Свързани статии