За 3 года работы мы нашли ряд схем разработки сайтов, которые оптимальны для разных условий:

1. Простая — один сайт

Самая простая схема, это когда сайт работает и все изменения вносятся по ходу через FTP в реальном времени.

Минимум действий, максимум результата. Но сайт постоянно падает.

Это подходит для сайтов не критичным к падениям и не подходит если сайт боевой и там много посетителей.

2. Сайт продукт + сайт для разработки

Второй вариант, когда есть боевой сайт на котором все работает и поднимается его дубль для разработки.

Дубль может не точно повторять боевой сайт, может вообще не повторять, а может повторять точь в точь — это зависит от задачи.

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

На боевом уже может стоять GIT, а может не стоять.

Чуть более затратная схема, но более надежная.

3. Продукт, тестовый и для разработки

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

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

Например два разработчика правили стили темы, сначала один, а потом второй и при сохранении второй разработчик затерет правки первого.

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

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

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

Как правило тут уже рекомендуется использовать GIT для боевого и для тестового. На сайтах разработки можно не использовать.

Эта схема затратней чем 1 и 2, но все еще оперативна. Риски ошибок сильно снижаются, но никуда не деваются.

4. Все по уму

Есть еще одна схема, в которой могут добавляться дополнительные этапы тестирования. Команды тестирования. Юнит-тесты и многое другое.

Затраты на эту схему ростут с геометрической прогрессией. Каждый новый элемент может вызывать удвоение и утроение затрат.

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

Резюме

Проблема только одна — как тут не ухитряйся, а ошибки все равно проскочат. Многие корпорации типа Apple, Google, Microsoft — используют многослойные схемы тестирования разработок, которые могут повышать стоимость разработки в 2 и более раз. Но мы знаем что ошибок в их продуктах преодстаточно. Все равно что то пролетает и приходится отправтья письма в техподдержку.

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

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

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


Поделитесь страницей в социальных сетях: