Простая стратегия разработки / тестирования / производственной среды для команды из 2 человек - PullRequest
1 голос
/ 22 ноября 2010

Я только что закончил писать базовое веб-приложение и загрузил его на свой VPS.До этого момента я разрабатывал все на своем локальном домашнем сервере.В дальнейшем я буду работать с 2 или, возможно, даже с 3 людьми, которые будут разрабатывать приложение дальше.У меня нет средств для физически отдельных сред.Я просто хочу иметь возможность разрабатывать в одной среде, тестировать ее в этой среде и продвигать код в производство.Я даже не вижу необходимости в отдельной тестовой среде.

Я бы предположил, что это миллионы сольных кодеров, подобных мне, каково общее решение этой проблемы?Кроме того, я знаю, что должен, но я не использую какой-либо источник контроля версий, такой как GIT, это необходимо для того, чего я пытаюсь достичь?

Ответы [ 3 ]

2 голосов
/ 22 ноября 2010

Я бы порекомендовал SVN для контроля версий.Он прост, прост в настройке, имеет хороший Windows-клиент (черепаха), если это то, что вы используете, и очень прост для использования небольшими командами разработчиков.

Имейте центральный «сервер разработчика», которыйили 3 разработчика, которые будут размещать SVN-репозиторий.Разработка будет проводиться и тестироваться на локальных машинах и передаваться на сервер dev по мере готовности (в идеале небольшие функции в течение рабочего дня).

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

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

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

Конечно, это можетвсе будет излишним для ваших нужд.Все в порядке.Уберите TeamCity из уравнения и просто разверните его вручную на локальном компьютере и выполните тестирование оттуда.Ничего страшного, в то время как ваша команда маленькая и достаточно близкая для открытого и устного общения.Но определенно не берите контроль над исходным кодом из уравнения.То, что вы все на одной машине, не означает, что вы не можете наступить друг другу на ноги и взломать код.Если ничего другого, контроль версий предоставляет большой журнал аудита изменений, внесенных в код.Возможно, вы хотите отменить то, что вы делали несколько месяцев назад, или посмотреть, что было до этого, чтобы вспомнить, как вы что-то сделали и т. Д. Даже один разработчик на одной машине в небольшом проекте должен абсолютно использовать систему контроля версий.

0 голосов
/ 23 ноября 2010

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

Я бы порекомендовал git для контроля версий.Просто, гибко и делает ветвления и слияния очень легкими.

Возможные настройки: Имейте основной репо, куда все подталкивают.Как только вы довольны (и это было протестировано), и вы готовы переместить его в prod ' tag ', репозиторий с номером версии и из среды prod извлеките помеченную версию проекта, которую вы хотите.

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

0 голосов
/ 22 ноября 2010
  • Вы должны использовать контроль версий для любого нетривиального проекта.

  • Для команды из 2 человек Git по-прежнему подходит,Одним рабочим процессом будет иметь «благословенное» git-репо, которое будет отражать продуктивность, и каждый разработчик будет делать git push для благословенного репозитория после того, как он проверит свои изменения (в своем блоке разработки).1012 *

    Но многое зависит от среды, которую обеспечивает ваш VPS.Например, некоторые старые версии CentOS не имеют git (вам придется самостоятельно устанавливать git).

    Возможно, вам следует добавить немного больше контекста в вопросе?

...