Организации процесса разработки на java

    Доброго времени суток, хабралюди…
    Хочу у вас спросить совета, о том как лучше огранизовать работу коллектива, занимающегося разработкой серверных приложений на java. Не могли бы вы описать полный цикл разработки(можно кратко :-) ) при средней детализации: куда кладутся сырцы, как это связать с документацией и багтрекингом, как потом эти сырцы собрать, как их отлаживать (unit-тесты какие-нибудь) с учетом серверной природы проекта. можно даже с именами программных продуктов.
    Как это делается в вашей конторе?
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 13

      0
      Свой сервер, SVN+Bugzilla
        +6
        Не важно на каком языке программирования ведется разработка. Процессы, принятые в разных компаниях, отличаются. Но в общем все они более или менее похожи.

        1. Сырцы, хранятся в какой-либо системе управления версиями. Вероятно, что не у всех есть права на commit. Зависит от размера команды и уровня специалистов.

        2. Каждый должен быть способен воссоздать собственный энвайрнмент для разработки и отладки приложения на локальной машине. Если этого сделать нельзя, например по причине гетерогенности используемых энвайрнментов, то создайте специальный сервер, на котором разработчики могли бы разворачивать и отлаживать приложение (каждый свою копию).

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

        4. Регулярные сборки с прогоном юнит-тестов (именно юнит-тестов, а не функциональных или интеграционных). Например раз в час. Если коммиты не частые, или ифнраструктура позволяет делать это чаще, то можно настроить сборку по коммиту. Так же можно обязать разработчиков делать это на своей машине перед коммитом. Но люди - они же не совершенны.

        5. Так же подумайте на тему брэнчевания вашего VCS на ветки для разработки , тестирования и продакшна. Когда срочно понадобится поставить хот-фикс, это вам поможет сэкономить время и силы.

        6. Интегрируйте багтрекер с VCS и выработайте правила заполнения комментариев к каждому коммиту.

        7. Из VCS я бы предпочитал те, которые имеют атомарный коммит (например VCS) или более строгое разделение изменений (например changelist в perforce).

        8. В VCS должен храниться всегда компилируемый и рабочий код.

        Говорить о связке документации и багтрекинга можно долго и нудно. И при этом не уверен, что вас устроит услышанное. У одних багтрекер является одновременно и хранилищем требований, другие используют большие дорогие и сложные системы отслеживания требований. Все зависит от объема требований и документации.
          0
          4,5,6 — зачем?
            0
            4. чтобы всегда выполнялся пункт 8 :)
            5. чтобы шоустоппер можно было фиксать ровно там, где это необходимо. при этом срочно.
            6. удобно остлеживать изменения. всегда есть связь между багом в трекере и всеми коммитами.
          0
          Какойто слишком обширный вы вопрос задали, вариантов разработки есть вагон и маленькая тележка. Да даже больше. Все зависи от конкретной ситуации.
          Вы бы уточнили какие именно процессы вы хотите улучшить, у вас ведь чтото уже есть. Иначе создается впечатление что в вашей команде никто до этого не пробовал разрабатывать софт и начинаете с нуля.
            0
            фактически так и есть - начинаем все с нуля (в рамках этой команды).
            +1
            Для конфигурации проекта мы используем Maven(разбивка на модули, управление зависимостями между модулями, репозитарий библиотек). Багтрекинг и координация работы команды через Issue Tracker(у нас это Jira). Ну и соответствено SVN для контроля версий. По хорошему если проект долго играющий не помешает ещё и wiki, ну и конечно тесты(TestNG или JUnit). А вообще если я не ошибаюсь это всё называется continuos integration.
              0
              Еще пара инструментов:
              Trac = SVN + wiki + Bag tracker
              СruiseСontrol - для сборки, запуска тестов и пр.
                0
                Сорри, правильные ссылки:
                http://trac.edgewall.org/
                http://cruisecontrol.sourceforge.net/
                  0
                  Использовал много треак-систем, в том числе и питоновский трак, но лучше этого http://www.redmine.org/
                  пока не нашел
                    0
                    Да, я тоже к этому пришел. Скажите, коллега, а удалось ли Вам связать svn и redmine? если да, то не поделитесь опытом.
                      0
                      Да, связать удалось без особых проблем, просто указал путь к репозиторию, логин и пароль и все заработало.
                        0
                        давайте по этому вопросу пообщаемся лично. напишите мне в личку. у меня возникли сложности.

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

              Самое читаемое