Отправляет email-рассылки с помощью сервиса Sendsay

Разработка проектов и управление командой разработчиков

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Левитас: Больше денег от Вашего бизнеса" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Август 2004   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Александр Левитас

Статистика

2.032 подписчиков
-1 за неделю
←   Все выпуски   →

Разработка проектов и управление командой разработчиков


Информационный Канал Subscribe.Ru 
Здравствуйте, уважаемые подписчики!
 

Процесс разработки проекта 2 (продолжение).

 

Начнем с разработки проекта. У проекта свой отдельный каталог, который тоже выкладывается в CVS. Руководитель проекта выкладывает проект в CVS периодически в начале и конце рабочего дня.

 

После того как проект помещается в CVS на него ставится метка, что бы в случае аврала можно было извлечь эту версию целиком из CVS.

 

Метка ставиться по определенным правилам. Мда, это еще не все.

 

После того как проект помещен в CVS он так же выкладывается на удаленный тестовый сервер, где QA ребята разбирают его по косточкам. Я помню  моменты, когда получал пачку замечаний от тестировщиков, когда они строчку за строчкой проверяли работу системы согласно спецификации, и в эти моменты я жалел, что так детально все описывал.

 

На процессе тестирования следует немного задержаться. Что бы QA смогли видеть, что изменилось, и что именно в этой версии надо тестировать мы делаем следующее: 1) выводим номер версии на страницах проекта – он равен имени метки CVS; 2) в задачах на тестирование указываем в какой версии было применено исправление или изменение.

 

Работает этот цикл так: разработчики получают задачи через систему назначения задач; решают задачи и когда задача завершена, то в кэйсе ставиться номер версии проекта, в который это исправление включено.

 

Затем в конце рабочего дня версия выкладывается в CVS и на тестовый сервер. Когда тестировщик получает кэйс, то он сразу смотрит номер версии, в которой тот реализован.

 

Если на тестовом сервере еще лежит более молодая версия, то кэйс откладывается и ждет своей версии. Есть так же возможность особо активным ребятам из QA подписаться на спам, который рассылается, когда новая версия проекта выкладывается на тестовый сервер.

 

Рассмотрим отдельно процесс разработки БД и ее обновление.

 

Используем мы ErWin для проектирования БД. Он уже очень хорошо себя зарекомендовал у нас. Мы его применяли для MS SQL всех версий и мастей, и теперь вот для Oracle.

 

Все тонкости настройки фильтров диаграмм, описаний и отчетов может рассказать наш архитектор БД, который съел не одну БД на этом продукте.

 

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

 

Бывает и такое что БД претерпевает не один рефакторинг еще на стадии проектирования логической модели. А тут нервы, возмущения, обвинения. Приходится постоянно искать компромиссы и принимать решения, порой только догадываясь к чему они могут привести.

 

Ну вот получили мы модель. Довольные! Затем распечатали и назначили физические атрибуты. И все!

 

Теперь пару кликов и БД как новенькая, готовая в смысле. А потом изменения, исправления и т.д.

 

Но что важно!!!  Мы не выкидываем в мусорку ErWin модель, после того как она стала на сервер. Она постоянно обновляется! И на основании модели выпускаются новые версии БД.

 

Используя версионный подход и CVS мы можем установить любую версию своей БД с нуля на любой сервер.

 

Устанавливается версия БД батниками, кликнул раз и готово, т.е. версия применена. А серверов у нас не один и не два.

 

Теперь осталось описать лишь подготовку версий проекта, тестирование, и, пожалуй, все.

 

Работа над версиями происходит приблизительно так.

 

У нас есть следующие сервера: производственный (на котором «развлекаются» конечные пользователи системы); тестовый (на котором проводят согласно букве спецификации тестирование QA ребята); локальный производственный (это копия производственного, но на нем «мучаются» разработчики, если обнаружена ошибка); локальный тестовый (это сервер, на котором происходит подготовка версии к выпуску), ну и сервер архитектора БД (на котором практикуется в мастерстве сам архитектор БД).

 

Пока готовился сделать выпуск добавилось еще два типа сервера. Т.е. пока живем, – развиваемся.

 

Ну и заправляет всеми этими серверами – системный администратор. Можете себе представить диаграммы и алгоритмы доступа к засекъюриным серверам.

 

А разбираемся со всем этим мы следующим образом.  После того как версия проекта была подготовлена на локальном тестовом сервере, и протестирована на удаленном тестовом, она выкладывается на производственный сервер.

 

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

 

Опять же пока готовил статью, мы добавили еще одно усложнение в разработку – так называемую замороженную версию. Т.е. это версия, которая вот-вот была разработана и теперь передана на тестирование.  А мы тем временем уже работаем над новой версией, пока тестировщики мучают замороженную версию.

 

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

 

В последующих выпуска я постараюсь детализировать каждый из процессов и описать некоторые правила, которые помогают нам хоть как-то не запутаться во всем этом.

 

До встречи. Пока!

 

 

оу, а это маленькая рекламка моей домашней странички: http://onlive.nm.ru 

С уважением,

Сергей

prj_management@list.ru

 

 

http://subscribe.ru/
http://subscribe.ru/feedback/		 Адрес подписки
 Отписаться
В избранное