[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-liquibase-kakie-best-practices-sushchestvuyut-pri-rabote-s-liquibase":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":15,"progress":16,"seo":17},961,"kakie-best-practices-sushchestvuyut-pri-rabote-s-liquibase",29,"liquibase","Liquibase","💧","Какие best practices существуют при работе с Liquibase?","Best practices Liquibase — это набор проверенных правил, которые предотвращают типичные проблемы с миграциями в командной разработке и на продакшене.\n\n### 1. Один changeset — одно изменение\n\nКаждый changeset должен содержать одно логическое изменение. Это упрощает rollback и отладку.\n\n```xml\n\u003C!-- Плохо: два изменения в одном changeset -->\n\u003CchangeSet id=\"bad-1\" author=\"dev\">\n    \u003CcreateTable tableName=\"orders\">...\u003C\u002FcreateTable>\n    \u003CcreateTable tableName=\"order_items\">...\u003C\u002FcreateTable>\n\u003C\u002FchangeSet>\n\n\u003C!-- Хорошо: каждое изменение в отдельном changeset -->\n\u003CchangeSet id=\"1\" author=\"dev\">\n    \u003CcreateTable tableName=\"orders\">...\u003C\u002FcreateTable>\n\u003C\u002FchangeSet>\n\u003CchangeSet id=\"2\" author=\"dev\">\n    \u003CcreateTable tableName=\"order_items\">...\u003C\u002FcreateTable>\n\u003C\u002FchangeSet>\n```\n\n### 2. Никогда не изменять уже применённые changeset-ы\n\nПосле того как changeset выполнен на любом окружении — его содержимое нельзя менять. Это приведёт к ошибке checksum. Если нужно исправление — создавайте новый changeset.\n\n### 3. Всегда указывать rollback\n\nДаже если Liquibase может сгенерировать rollback автоматически, явное указание повышает предсказуемость.\n\n### 4. Именование файлов\n\nИспользовать последовательную и понятную схему именования:\n\n```\ndb\u002Fchangelog\u002F\n├── db.changelog-master.xml\n├── changes\u002F\n│   ├── 001-create-users-table.xml\n│   ├── 002-create-accounts-table.xml\n│   ├── 003-add-email-to-users.xml\n│   └── 004-create-transactions-table.xml\n```\n\n### 5. Использовать осмысленные id\n\n```xml\n\u003C!-- Плохо -->\n\u003CchangeSet id=\"1\" author=\"dev\">\n\n\u003C!-- Хорошо -->\n\u003CchangeSet id=\"2025-01-15-create-users-table\" author=\"ivanov\">\n```\n\n### 6. Не использовать runAlways и runOnChange без необходимости\n\nЭти атрибуты допустимы для хранимых процедур или представлений, но не для DDL-операций.\n\n### 7. Использовать logicalFilePath\n\nПри переносе файлов changelog в другую директорию указывайте `logicalFilePath`, чтобы не нарушить уникальность changeset:\n\n```xml\n\u003CdatabaseChangeLog logicalFilePath=\"db\u002Fchangelog\u002Finitial.xml\">\n```\n\n### 8. Тестировать миграции\n\nИспользовать `updateTestingRollback` для проверки, что rollback работает корректно. Запускать миграции на чистой БД в CI.\n\n### 9. Разделять структурные и data-миграции\n\nСтруктурные изменения (DDL) и загрузку данных (DML) лучше разделять в разные changeset-ы.\n\n### 10. Использовать preconditions для безопасности\n\nОсобенно полезно при работе с уже существующими БД или при деплое на разные окружения.\n\n> **На собеседовании:** не нужно перечислять все 10 пунктов. Достаточно уверенно назвать три главных: один changeset = одно изменение, не менять применённые changeset-ы, всегда писать rollback. Частая ошибка — не упомянуть правило неизменяемости changeset-ов.","","middle",[7],[],null,{"title":18,"description":19,"ogTitle":18,"ogDescription":20,"keywords":21,"schemaAnswer":19,"featuredSnippetReady":22},"Какие best practices существуют при работе с Liquibase? — Gymterview","Best practices Liquibase — это набор проверенных правил, которые предотвращают типичные проблемы с миграциями в командной разработке и на продакшене.","Best practices Liquibase — это набор проверенных правил, которые предотвращают типичные проблемы с миграциями в командно",[7,13],true]