Меню
Что нового?

Деплоймент

гемоглобин

Новичок
Деплоймент

Ситуация следующая

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

На каждом этапе код тестируется соотв. отделом.

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

Мы не можем всё сразу слить с preview на production, потому что фичи утверждаются клиентом в разное время, а некоторые вообще отвергаются.

Вопрос: как облегчить жизнь?

Если хранить каждое изменение в своей ветке svn, то веток будет до хрена, и после каждого выкладывания фичи на продакшн, надо будет накатывать эти изменения на все ветки, и опять же тестировать (нанять больше тестеров??). В общем, что-то я запутался. Как люди-то делают?
 
Зачем делать то, что клиенту не особо нужно и он это будет утверждать когда-то потом а может вообще никогда? По-нормальному сначала feature request, а потом уже любой код. Делите разработку на итерации. 1 итерация = прогнозируемый в разработке набор фич. Сделали, скопом сдали, выложили. Таки образом и заказчик будет сосредотачиваться на том, что ему реально нужно в работе, а не на том, что ему бы хотелось там видеть.

ЗЫ. а время, освобидившееся от реализации фич сомнительной-необходимости, с большей пользой можно потратить на автоматизированное тестирование.
 
Если с клиента берутся хорошие деньги - почему он не может поразмышлять, такая ему фича нужна, или не совсем такая. Имхо навязывать клиенту заморочки (итерации и т.д.) из-за того, что разработчикам что-то там неудобно деплоить - это неправильно. Всё равно что приходишь ты например покупать мобильник, а тебе говорят, что мобильники продаются только партиями по 10 штук, так что ждите еще девятерых потенциальных покупателей - иначе нам неудобно отгружать.

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

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

Доступ к галочкам можно дать клиенту, а кнопку оставить только для себя :)

-~{}~ 18.02.10 14:35:

С другой стороны, поскольку клиент всеравно платит. То почему не сделать фичи отключаемыми в настройках проекта?
И деплоить все скопом, но скажем с отключенными пунктами в ностройках.
 
гемоглобин интересный у вас подход. Сказали бы шо за продукт хоть. Вдруг и правда вам так надо. В большинстве случаев доделка-переделка обходится гораздо дороже, чем планирование. Возвращаясь к вашему примеру с телефонами, все равно сначала требования клиента анализируется. Где вы видели сотовые телефоны совмещенные с зонтиками и рулем? Или может вы видели что траншеи станачал копают, а потом предлагают заказчику - не хотите ли тут трубу проложить? :) А чо, любой товар найдет своего покупателя. Но нет, таких телефонов нет и так не копают, что как-бе намекает нам.
 
prodaction.ru - домен для продакшена и всех-всех-всех
fichi.prodaction.ru - сюда сваливаем все экспериментальные ветки, доступ только для заказчика.
пишем ситему так, чтоб можно было переключиться двумя строчками в конфиге.
 
Alexandre
а чем поможет от
Мы не можем всё сразу слить с preview на production, потому что фичи утверждаются клиентом в разное время, а некоторые вообще отвергаются.
Нажмите для раскрытия...
Половину фитч утвердили, половину нет, как и куда переключать?
 
Автор оригинала: whirlwind
Или может вы видели что траншеи станачал копают, а потом предлагают заказчику - не хотите ли тут трубу проложить? :)
Нажмите для раскрытия...
Не совсем так, у нас зачастую фича, предложенная клиенту, была сделана изначально для другого клиента под заказ. Так что тут не надо копать, просто немножко напильником подхреначить
 
нанять грамотного менеджера, который будет грамотно планировать и рулить списком фич, которые должны быть сделаны к определенному сроку
 
Войдите или зарегистрируйтесь для ответа.
Сверху