Не так давно наша компания получила на сопровождение и доработку достаточно большой интернет-магазин на 1С-Битрикс. Проект пару месяцев, как был запущен в промышленную эксплуатацию, но при этом имел ряд серьезных проблем. Кроме того, заказчик планировал выполнить задачи по доработке нового функционала в максимально сжатые сроки. Передо мной была поставлена задача организовать эффективную работы по проекту с минимальным временем простоя сайта и максимальным удовлетворением потребностей заказчика.
Далее опишу основные проблемы, с которыми пришлось столкнуться в этом, и нескольких похожих, проектах, апробированные мною решения и результаты работ.
Разработкой программного обеспечения в целом, и web-проектов в частности, занимаюсь около 8 лет. За это время сталкивался с проектами различной сложности и, на первый взгляд, задаче не показалась мне слишком трудной. При выполнении проектов в нашей компании, как правило, применяется методология SCRUM. От нее я и начал отталкиваться.
Первым делом, получил доступ исходному коду проекта. Поверхностно проанализировал. Согласовал с заказчиком список первостепенных задач. Составил план разработки для 3х разработчиков и, как сказал Гагарин, поехали!
Как это обычно и бывает, во всем виноваты все, кроме заказчика. Дизайнер сделал макет, который слишком много весит, хостер предоставил сервер, который медленно работает, разработчики сделали сайт, который все время глючит и ломается, менеджеры выполнили какие-то задачи, которые мы выполнять не просили, после перехода со старой версии сайта на 1С-Битрикс произошло резкое снижение поискового трафика и т.д. Ситуация не однозначная. С одной стороны основная ответственность конечно же должна лежать на компании разработчике. Нужно было донести до заказчика последствия всех действий с сайтом и подготовить к результату. При выполнении работы предложить целостную архитектуру будущей системы и план разработки, которого нужно придерживаться до завершения основных этапов. Провести тщательное тестирование функционала и сдать работу. С другой стороны, не редко сталкиваюсь с ситуацией, когда заказчик все сам лучше знает, потому что у него мама когда-то рисовала, а посему является лучшим дизайнером, и его 7ми летний сын прекрасно разбирается в SEO-оптимизации, потому что все время проводит за компьютером, играя в GTA.
Кто виноват, кто прав судить не нам. В данном случае, предыдущим подрядчиком была достаточно известная надежная компания и ничего плохого об их разработке сказать не могу. Да и заказчик, объективно, переживает за свой продукт и старается его улучшить. Как оно было не знаю, для себя я нашел объяснение в недостаточном количестве аналитики предоставленной исполнителем заказчику.
В результате:
Решение проблему вижу только одно: постепенно планомерно вычищать все модули сайта по очереди для доведения продукта до требуемого состояния. Какие-то ошибки были вынесены в отдельные задачи и выполнены немедленно, что-то удалось поправить параллельно с разработкой нового функционала. Результат — с каждым апдейтом, после оперативного вычищения вылезших багов, сайт становится все лучше и стабильнее.
В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки. Проблема заключается в том, что разработка ведется несколькими, в моем случае, тремя, разработчиками непрерывно. В случае с классической разработкой все просто. Каждый разработчик занимается своим модулем. Затем проводится функциональное тестирование каждого модуля, все доработки сливаются в репозиторий какой-нибудь системы контроля версий, дальше это тестируется все вместе (интеграционное тестирование). Если результат нормальный –тестовая версия презентуется заказчику. После принятия тестовой версии происходит обновление продакшен-сервера. В соответствии с методологией SCRUM я определил, чтоб буду выкладывать новые версии на боевой сайт раз в неделю. Соответственно, есть 3-4 дня на основную разработку. 1 день на тестирование и исправление ошибок и пол дня на обновление боевого сервера. Сроки конечно колеблются, но правила «релиз каждый четверг» старался четко придерживаться.
Первое с чем столкнулся, в 1С-Битрикс есть ситуации, в которых один и тот же файл одновременно задействован в разном функционале в разных концах сайта. Самое простое и очевидное решение – использовать систему контроля версий, в моем случае, SVN, которым пользуюсь во всех остальных проектах. Но для использования контроля версий необходимо, чтоб у каждого разработчика была своя собственная версия кода, которую он правит и затем сливает общий репозиторий.
Как же быть с лицензией? Обратился в техническую поддержку 1С-Битрикс. Получил предложение докупить доп. лицензии для разработки. Мягко сказать, не обрадовался, но других предложений не получил. Выход нашел достаточно быстро. Решил использовать NFR-ключи. Благо, партнерский статус позволяет. В результате создал 5 исталяций интернет-магазина:
Со временем пошел еще дальше. Появилась еще отдельная инсталляция для тестера. Оказалось, что с моим везением заказчик всегда заходит на тестовый сервер в момент, когда там что-то обновляется. В багтреке возникает много лишних задач, которые уже и так выполнены, а у заказчика возникает впечатление, что мы плохо делаем свою работу.
Сейчас использую следующую схему:
Из очевидных минусов такого подхода хочу выделить низкий уровень вовлеченности заказчика в разработку. Результат виден заказчику уже только на финальной стадии. Такой подход применим если у вас есть хороший аналитик, который редко ошибается и находится в постоянно контакте с заказчиком. Иначе, многие задачи придется переделывать с нуля.
По мере построения схемы столкнулся с еще одной проблемой. Проект занимает на диске около 80Гб. Без кеша и временных файлов – около 60. Пытался по началу убрать картинки и видео из контроля версий – не получилось. Информация на сайте меняется постоянно. Тестировать нужно на актуальных данных. Первый комит сайта в репозиторий у меня шел кусками более 2х суток. Первый чекаут в папку для разработки проходит несколько часов (SVN сервер в локальной сети разработки). Если, не дай бог, случайно сделать полный апдейт папки проекта – можно уходить курить, обедать, играть в пинг-понг или керлинг. Комит только выбранных файлов или папок проходит достаточно быстро. Решение: выполнил задачу – закомить сразу десяток измененных файлов.
Проблема самая важная, сложная и, до конца, не решенная. Ведь если остальные проблемы относятся к внутренней кухне проекта, то от работы сайта зависит репутация и доход заказчика, а, следовательно, и мой доход.
Тут отлично работают законы Мерфи:
Я, конечно, утрирую, но в каждой шутке есть доля шутки. Минимальная нагрузка на сайт с 4 до 6 утра. Обновлять в это время конечно бы лучше, но уж очень не хочется.
В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части:
В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут. Можно конечно апдейтить только измененный файлы, но тогда теряется весь смысл репозитория. Во-вторых, и это куда более печально, часто при апдейте приходится делать ручные изменения и настройки через админку. А это всегда медленно, нужно помнить все изменения, которые необходимо выполнить, велика вероятность случайно ошибиться. Можно, конечно, написать SQL скрипт, который сам внесет все нужные изменения в базу. В простейших случаях, разумеется, так и делаем. Но в большинстве случаев написание и отладка такого скрипта занимает больше времени чем сама разработка и намного больше времени, чем выполнение всех действий вручную с последующей проверкой.
Хорошего решения проблемы пока не нашел. Сейчас обновляем настройки в базе вручную. Для минимизации ошибок составляется чек-лист со списком что нужно сделать при апдейте. Обновление стараемся производить максимально внимательно и аккуратно. После обновления всей командой проверяем основной функционал продакшен сервера и проводим дополнительное тестирование. Количество ошибок минимизировано, но полностью от багов и простоев при обновлении избавиться пока не получилось.
Второе, с чем столкнулся, это совместная работа с заказчиком. Т.к. проект большой, над ним постоянно трудится около 30 человек. Контент-менеджеры, менеджеры по продажам, SEO-оптимизаторы, маркетологи и много еще кого. Естественно, каждый вносит в страницы сайта и настройку модулей какие-то изменения. Первым решением было забрать права у заказчика на внесение изменений в программный код сайта. Решение абсолютно правильно, но стало только хуже. Если раньше заказчик предполагал, что он так же может зайти на сайт и случайно что-то сломать, то теперь все шишки стали сыпаться только на нас. При чем. Даже если контент-менеджер криво отредактировал текст на странице и не закрыл какой-то тег – все равно виноват разработчик. Решение нашлось довольно простое. В маркетплейсе есть бесплатны модуль по контролю версий страниц. Проблему это не убрало, все равно кто-нибудь время от времени что-то да наплужит, но зато теперь появилась возможность посмотреть в любой момент времени кто менял, что менял и почему все сломалось. Результат, конечно, не ice, но кучу нервов мне экономит.
Дополнительно приняли решение перед каждым обновлением тестового сервера берем на него копию с боевого. На это тоже уходит много времени. Заархивировать проект, перенести на другой сервер, разархивировать. Все это занимает несколько часов. Зато, новые доработки проверяются практически в боевых условиях. Если настройки тестового и продакшен сервера идентичны, разница в работе будет минимальна и количество ошибок существенно сокращается. Как показал опыт, за неделю продакшен сервер может измениться настолько, что часть нового функционала, работающего без проблем на копии недельной давности, на свежей копии может не заработать вообще.
Проблема относится не столько к 1С-Битрикс, сколько к доработке и поддержке работающих проектов. Часто у заказчика возникает желание сделать какую-то мелочь, но срочно и сразу на боевом сайте. Результат всегда один – ничего хорошего из этого не выходит. В лучшем случае, об этой доработке просто забудут при очередном релизе, в худшем – сервер просто упадет и его придется несколько часов восстанавливать из бекапа.
Решение нашел только одно – никогда не идти на поводу у заказчика в ущерб надежности и безопасности. Как бы заказчик не просил, виноват всегда будет разработчик. Как говорил мне мой бывший начальник: «Я же тебя не просил сделать плохо».
И раз уж затронули тему бекапов, хочу заметить. Бекап средствами 1С-Битрик это конечно хорошо и удобно, но очень медленно. В случае, если срочно нужно восстановить 1-2 файла или несколько значений в базе, приходится ждать пока разархивируются все 60 Гб. Здесь наиболее эффективной мне кажется следующая схема:
Спасибо всем, кто дочитал до конца. Надеюсь, мой опыт будет вам полезен. Буду рад предложениям по более удачным способам решения озвученных проблем в комментариях или в личку. Сейчас я постарался озвучить основные проблемы доработки и поддержки уже запущенных проектов с высокими требованиями к надежности. Если материал окажется интересным, планирую написать продолжение об особенностях архитектуры 1С-Битрикс, которые отличают разработку сайта на Битриксе от разработки других веб-проектов.
Далее опишу основные проблемы, с которыми пришлось столкнуться в этом, и нескольких похожих, проектах, апробированные мною решения и результаты работ.
Исходные данные:
- Есть интернет-магазин на 1С-Битрикс
- Проекту несколько лет, но только несколько месяцев назад сайт перевели на 1С-Битрикс
- Посещаемость 10-15 тыс. человек в день
- Каталог магазина содержит около 12 000 позиций товаров
- Простои и отключения сайта недопустимы
- Проект в течении полугода разрабатывался другой компанией:
- Есть ТЗ, примерно на 100 листов, соответствующее выполненной работе примерно на 40%
- Никакой документации проекта
- Отсутствие понимания, почему предыдущие разработчики использовали именно такие архитектурные решения.
Разработкой программного обеспечения в целом, и web-проектов в частности, занимаюсь около 8 лет. За это время сталкивался с проектами различной сложности и, на первый взгляд, задаче не показалась мне слишком трудной. При выполнении проектов в нашей компании, как правило, применяется методология SCRUM. От нее я и начал отталкиваться.
Первым делом, получил доступ исходному коду проекта. Поверхностно проанализировал. Согласовал с заказчиком список первостепенных задач. Составил план разработки для 3х разработчиков и, как сказал Гагарин, поехали!
Проблема №1 – во всем виноваты разработчики
Как это обычно и бывает, во всем виноваты все, кроме заказчика. Дизайнер сделал макет, который слишком много весит, хостер предоставил сервер, который медленно работает, разработчики сделали сайт, который все время глючит и ломается, менеджеры выполнили какие-то задачи, которые мы выполнять не просили, после перехода со старой версии сайта на 1С-Битрикс произошло резкое снижение поискового трафика и т.д. Ситуация не однозначная. С одной стороны основная ответственность конечно же должна лежать на компании разработчике. Нужно было донести до заказчика последствия всех действий с сайтом и подготовить к результату. При выполнении работы предложить целостную архитектуру будущей системы и план разработки, которого нужно придерживаться до завершения основных этапов. Провести тщательное тестирование функционала и сдать работу. С другой стороны, не редко сталкиваюсь с ситуацией, когда заказчик все сам лучше знает, потому что у него мама когда-то рисовала, а посему является лучшим дизайнером, и его 7ми летний сын прекрасно разбирается в SEO-оптимизации, потому что все время проводит за компьютером, играя в GTA.
Кто виноват, кто прав судить не нам. В данном случае, предыдущим подрядчиком была достаточно известная надежная компания и ничего плохого об их разработке сказать не могу. Да и заказчик, объективно, переживает за свой продукт и старается его улучшить. Как оно было не знаю, для себя я нашел объяснение в недостаточном количестве аналитики предоставленной исполнителем заказчику.
В результате:
- Проект не доведен до логического завершения. Многие задачи брошены на середине пути
- Проект не задокументирован. Работа части функционала не очевидна. При разработке нового функционала оказывается, что перестал работать функционал, который раньше работал и о существовании которого новый разработчик и не подозревал
- Часть написанного предыдущим исполнителем кода приходится переписывать с нуля
- Задуманная архитектура проекта в первые недели/месяца работы новому подрядчику не ясна. Доработка функционала одного модуля приводит к потере работоспособности функционала никак не связанного с ним модуля
- Заказчик нервничает, исполнитель нервничает, посетители не довольны, посещаемость уменьшается, продажи падают
Решение проблему вижу только одно: постепенно планомерно вычищать все модули сайта по очереди для доведения продукта до требуемого состояния. Какие-то ошибки были вынесены в отдельные задачи и выполнены немедленно, что-то удалось поправить параллельно с разработкой нового функционала. Результат — с каждым апдейтом, после оперативного вычищения вылезших багов, сайт становится все лучше и стабильнее.
Проблема №2 – параллельная разработка.
В соответствии с лицензионной политикой 1С-Битрикс, каждая лицензия на сайт позволяет использовать 2 копии системы. Одну, как продакшен сайт, вторую – для разработки. Проблема заключается в том, что разработка ведется несколькими, в моем случае, тремя, разработчиками непрерывно. В случае с классической разработкой все просто. Каждый разработчик занимается своим модулем. Затем проводится функциональное тестирование каждого модуля, все доработки сливаются в репозиторий какой-нибудь системы контроля версий, дальше это тестируется все вместе (интеграционное тестирование). Если результат нормальный –тестовая версия презентуется заказчику. После принятия тестовой версии происходит обновление продакшен-сервера. В соответствии с методологией SCRUM я определил, чтоб буду выкладывать новые версии на боевой сайт раз в неделю. Соответственно, есть 3-4 дня на основную разработку. 1 день на тестирование и исправление ошибок и пол дня на обновление боевого сервера. Сроки конечно колеблются, но правила «релиз каждый четверг» старался четко придерживаться.
Первое с чем столкнулся, в 1С-Битрикс есть ситуации, в которых один и тот же файл одновременно задействован в разном функционале в разных концах сайта. Самое простое и очевидное решение – использовать систему контроля версий, в моем случае, SVN, которым пользуюсь во всех остальных проектах. Но для использования контроля версий необходимо, чтоб у каждого разработчика была своя собственная версия кода, которую он правит и затем сливает общий репозиторий.
Как же быть с лицензией? Обратился в техническую поддержку 1С-Битрикс. Получил предложение докупить доп. лицензии для разработки. Мягко сказать, не обрадовался, но других предложений не получил. Выход нашел достаточно быстро. Решил использовать NFR-ключи. Благо, партнерский статус позволяет. В результате создал 5 исталяций интернет-магазина:
- Продакшен-сервер
- Тестовый сервер
- 3 сервера разработки (по одному на разработчика)
Со временем пошел еще дальше. Появилась еще отдельная инсталляция для тестера. Оказалось, что с моим везением заказчик всегда заходит на тестовый сервер в момент, когда там что-то обновляется. В багтреке возникает много лишних задач, которые уже и так выполнены, а у заказчика возникает впечатление, что мы плохо делаем свою работу.
Сейчас использую следующую схему:
- Каждый разработчик использует для работы только свою локальную копию
- В оговоренное время все завершенные доработки сливаются в общую ветку в репозитории
- QA забирает себе «смердженную» версию для тестирования
- После тестирования и исправления ошибок происходит обновление демонстрационного сервера для заказчика
- После проверки и акцепта заказчиком, доработки переносятся на боевой сервер.
Из очевидных минусов такого подхода хочу выделить низкий уровень вовлеченности заказчика в разработку. Результат виден заказчику уже только на финальной стадии. Такой подход применим если у вас есть хороший аналитик, который редко ошибается и находится в постоянно контакте с заказчиком. Иначе, многие задачи придется переделывать с нуля.
По мере построения схемы столкнулся с еще одной проблемой. Проект занимает на диске около 80Гб. Без кеша и временных файлов – около 60. Пытался по началу убрать картинки и видео из контроля версий – не получилось. Информация на сайте меняется постоянно. Тестировать нужно на актуальных данных. Первый комит сайта в репозиторий у меня шел кусками более 2х суток. Первый чекаут в папку для разработки проходит несколько часов (SVN сервер в локальной сети разработки). Если, не дай бог, случайно сделать полный апдейт папки проекта – можно уходить курить, обедать, играть в пинг-понг или керлинг. Комит только выбранных файлов или папок проходит достаточно быстро. Решение: выполнил задачу – закомить сразу десяток измененных файлов.
Проблема №3 – обновление продакшен-сервера и совместная работа с заказчиком
Проблема самая важная, сложная и, до конца, не решенная. Ведь если остальные проблемы относятся к внутренней кухне проекта, то от работы сайта зависит репутация и доход заказчика, а, следовательно, и мой доход.
Тут отлично работают законы Мерфи:
- Если что-то плохо работает на тестовом сервере – на боевом сервере это обязательно сломается.
- Если что-то отлично работает на тестовом сервере – на боевом сервере это все равно обязательно сломается.
- Если баг на сайте существует всего 5 секунд, его обязательно найдет кто-то из посетителей и обязательно напишет об этом в отзывах или в форме обратной связи.
- Если сайт не работает 1 минуту во время обновления, то именно в эту минуту владелец компании будет показывать его своему другу или конкуренту (и это не смотря на согласование времени и процедуры обновления).
Я, конечно, утрирую, но в каждой шутке есть доля шутки. Минимальная нагрузка на сайт с 4 до 6 утра. Обновлять в это время конечно бы лучше, но уж очень не хочется.
В случае большинства веб-приложений есть четкая структура разделения приложения на слои и обновление сайта можно разделить на 2 части:
- Обновление программного кода
- Обновление базы данных с помощью SQL-скриптов
В случае с 1С-Битрикс все немного сложнее. Во-первых, файлов много. У меня в проекте их более миллиона. Обычный апдейт из репозитория проходит никак не меньше 20-30 минут. Можно конечно апдейтить только измененный файлы, но тогда теряется весь смысл репозитория. Во-вторых, и это куда более печально, часто при апдейте приходится делать ручные изменения и настройки через админку. А это всегда медленно, нужно помнить все изменения, которые необходимо выполнить, велика вероятность случайно ошибиться. Можно, конечно, написать SQL скрипт, который сам внесет все нужные изменения в базу. В простейших случаях, разумеется, так и делаем. Но в большинстве случаев написание и отладка такого скрипта занимает больше времени чем сама разработка и намного больше времени, чем выполнение всех действий вручную с последующей проверкой.
Хорошего решения проблемы пока не нашел. Сейчас обновляем настройки в базе вручную. Для минимизации ошибок составляется чек-лист со списком что нужно сделать при апдейте. Обновление стараемся производить максимально внимательно и аккуратно. После обновления всей командой проверяем основной функционал продакшен сервера и проводим дополнительное тестирование. Количество ошибок минимизировано, но полностью от багов и простоев при обновлении избавиться пока не получилось.
Второе, с чем столкнулся, это совместная работа с заказчиком. Т.к. проект большой, над ним постоянно трудится около 30 человек. Контент-менеджеры, менеджеры по продажам, SEO-оптимизаторы, маркетологи и много еще кого. Естественно, каждый вносит в страницы сайта и настройку модулей какие-то изменения. Первым решением было забрать права у заказчика на внесение изменений в программный код сайта. Решение абсолютно правильно, но стало только хуже. Если раньше заказчик предполагал, что он так же может зайти на сайт и случайно что-то сломать, то теперь все шишки стали сыпаться только на нас. При чем. Даже если контент-менеджер криво отредактировал текст на странице и не закрыл какой-то тег – все равно виноват разработчик. Решение нашлось довольно простое. В маркетплейсе есть бесплатны модуль по контролю версий страниц. Проблему это не убрало, все равно кто-нибудь время от времени что-то да наплужит, но зато теперь появилась возможность посмотреть в любой момент времени кто менял, что менял и почему все сломалось. Результат, конечно, не ice, но кучу нервов мне экономит.
Дополнительно приняли решение перед каждым обновлением тестового сервера берем на него копию с боевого. На это тоже уходит много времени. Заархивировать проект, перенести на другой сервер, разархивировать. Все это занимает несколько часов. Зато, новые доработки проверяются практически в боевых условиях. Если настройки тестового и продакшен сервера идентичны, разница в работе будет минимальна и количество ошибок существенно сокращается. Как показал опыт, за неделю продакшен сервер может измениться настолько, что часть нового функционала, работающего без проблем на копии недельной давности, на свежей копии может не заработать вообще.
Проблема №4 – «сделайте мне срочно, это же задача на 5 минут»
Проблема относится не столько к 1С-Битрикс, сколько к доработке и поддержке работающих проектов. Часто у заказчика возникает желание сделать какую-то мелочь, но срочно и сразу на боевом сайте. Результат всегда один – ничего хорошего из этого не выходит. В лучшем случае, об этой доработке просто забудут при очередном релизе, в худшем – сервер просто упадет и его придется несколько часов восстанавливать из бекапа.
Решение нашел только одно – никогда не идти на поводу у заказчика в ущерб надежности и безопасности. Как бы заказчик не просил, виноват всегда будет разработчик. Как говорил мне мой бывший начальник: «Я же тебя не просил сделать плохо».
И раз уж затронули тему бекапов, хочу заметить. Бекап средствами 1С-Битрик это конечно хорошо и удобно, но очень медленно. В случае, если срочно нужно восстановить 1-2 файла или несколько значений в базе, приходится ждать пока разархивируются все 60 Гб. Здесь наиболее эффективной мне кажется следующая схема:
- Должен происходить ежесуточный бекап файлов и базы данных в виде архива на внешний источник данных.
- Всегда делаем бекап непосредственно перед обновлением в одном из 2х вариантов:
- Вариант light – Копируем всю папку проекта в соседнюю папку на сервере. Базу данных в виде дампа сохраняем в отдельный файл. Ничего не архивируем. В случае, если нужно будет восстановить какое-то значение в базе или один из файлов, все будет под рукой и легкодоступно
- Вариант strong – аналогично предыдущему, только базу копируем в другую базу данных MySQL. Это позволит в случае полного краха за 1-2 минуты исправить в файле хостов корневую папку сайта и проект начнет работать из соседней папки с копией базы.
Заключение
Спасибо всем, кто дочитал до конца. Надеюсь, мой опыт будет вам полезен. Буду рад предложениям по более удачным способам решения озвученных проблем в комментариях или в личку. Сейчас я постарался озвучить основные проблемы доработки и поддержки уже запущенных проектов с высокими требованиями к надежности. Если материал окажется интересным, планирую написать продолжение об особенностях архитектуры 1С-Битрикс, которые отличают разработку сайта на Битриксе от разработки других веб-проектов.
