Comments 13
Свой сервер, SVN+Bugzilla
Не важно на каком языке программирования ведется разработка. Процессы, принятые в разных компаниях, отличаются. Но в общем все они более или менее похожи.
1. Сырцы, хранятся в какой-либо системе управления версиями. Вероятно, что не у всех есть права на commit. Зависит от размера команды и уровня специалистов.
2. Каждый должен быть способен воссоздать собственный энвайрнмент для разработки и отладки приложения на локальной машине. Если этого сделать нельзя, например по причине гетерогенности используемых энвайрнментов, то создайте специальный сервер, на котором разработчики могли бы разворачивать и отлаживать приложение (каждый свою копию).
3. Сборка и деплоймент проекта как минимум должны делиться на девелоперскую и продакшн. Первое подразмумевает упрощенную и возможно неполную сборку из локальной копии сырцов. Второе предполагает полную сборку с предварительной очисткой энварнмента от всего лишнего, полным чекаутом сырцов, компиляцией и сборкой. Важно, чтобы эта процедура выполнялась очень просто, с помощью одной команды.
4. Регулярные сборки с прогоном юнит-тестов (именно юнит-тестов, а не функциональных или интеграционных). Например раз в час. Если коммиты не частые, или ифнраструктура позволяет делать это чаще, то можно настроить сборку по коммиту. Так же можно обязать разработчиков делать это на своей машине перед коммитом. Но люди - они же не совершенны.
5. Так же подумайте на тему брэнчевания вашего VCS на ветки для разработки , тестирования и продакшна. Когда срочно понадобится поставить хот-фикс, это вам поможет сэкономить время и силы.
6. Интегрируйте багтрекер с VCS и выработайте правила заполнения комментариев к каждому коммиту.
7. Из VCS я бы предпочитал те, которые имеют атомарный коммит (например VCS) или более строгое разделение изменений (например changelist в perforce).
8. В VCS должен храниться всегда компилируемый и рабочий код.
Говорить о связке документации и багтрекинга можно долго и нудно. И при этом не уверен, что вас устроит услышанное. У одних багтрекер является одновременно и хранилищем требований, другие используют большие дорогие и сложные системы отслеживания требований. Все зависит от объема требований и документации.
1. Сырцы, хранятся в какой-либо системе управления версиями. Вероятно, что не у всех есть права на commit. Зависит от размера команды и уровня специалистов.
2. Каждый должен быть способен воссоздать собственный энвайрнмент для разработки и отладки приложения на локальной машине. Если этого сделать нельзя, например по причине гетерогенности используемых энвайрнментов, то создайте специальный сервер, на котором разработчики могли бы разворачивать и отлаживать приложение (каждый свою копию).
3. Сборка и деплоймент проекта как минимум должны делиться на девелоперскую и продакшн. Первое подразмумевает упрощенную и возможно неполную сборку из локальной копии сырцов. Второе предполагает полную сборку с предварительной очисткой энварнмента от всего лишнего, полным чекаутом сырцов, компиляцией и сборкой. Важно, чтобы эта процедура выполнялась очень просто, с помощью одной команды.
4. Регулярные сборки с прогоном юнит-тестов (именно юнит-тестов, а не функциональных или интеграционных). Например раз в час. Если коммиты не частые, или ифнраструктура позволяет делать это чаще, то можно настроить сборку по коммиту. Так же можно обязать разработчиков делать это на своей машине перед коммитом. Но люди - они же не совершенны.
5. Так же подумайте на тему брэнчевания вашего VCS на ветки для разработки , тестирования и продакшна. Когда срочно понадобится поставить хот-фикс, это вам поможет сэкономить время и силы.
6. Интегрируйте багтрекер с VCS и выработайте правила заполнения комментариев к каждому коммиту.
7. Из VCS я бы предпочитал те, которые имеют атомарный коммит (например VCS) или более строгое разделение изменений (например changelist в perforce).
8. В VCS должен храниться всегда компилируемый и рабочий код.
Говорить о связке документации и багтрекинга можно долго и нудно. И при этом не уверен, что вас устроит услышанное. У одних багтрекер является одновременно и хранилищем требований, другие используют большие дорогие и сложные системы отслеживания требований. Все зависит от объема требований и документации.
Какойто слишком обширный вы вопрос задали, вариантов разработки есть вагон и маленькая тележка. Да даже больше. Все зависи от конкретной ситуации.
Вы бы уточнили какие именно процессы вы хотите улучшить, у вас ведь чтото уже есть. Иначе создается впечатление что в вашей команде никто до этого не пробовал разрабатывать софт и начинаете с нуля.
Вы бы уточнили какие именно процессы вы хотите улучшить, у вас ведь чтото уже есть. Иначе создается впечатление что в вашей команде никто до этого не пробовал разрабатывать софт и начинаете с нуля.
Для конфигурации проекта мы используем Maven(разбивка на модули, управление зависимостями между модулями, репозитарий библиотек). Багтрекинг и координация работы команды через Issue Tracker(у нас это Jira). Ну и соответствено SVN для контроля версий. По хорошему если проект долго играющий не помешает ещё и wiki, ну и конечно тесты(TestNG или JUnit). А вообще если я не ошибаюсь это всё называется continuos integration.
Еще пара инструментов:
Trac = SVN + wiki + Bag tracker
СruiseСontrol - для сборки, запуска тестов и пр.
Trac = SVN + wiki + Bag tracker
СruiseСontrol - для сборки, запуска тестов и пр.
Sign up to leave a comment.
Организации процесса разработки на java