Как устроен процесс веб разработки в крупных/промышленных компаниях?

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

Возможно тут будет сразу ответ: "Для каждого проекта по разному" но хотелось бы знать какие тенденции в общем ключе.

1.Какими средствами разработки пользуются программисты?
2.Программирование ведется на локальных или удаленных машинах. Если на локальных то что делают если приложение использует тяжеловесные сервисы(возможно разработанные самой компанией), если на удаленных то как обеспечивается синхронизация кода со средствами разработки?
3.Как устроен процесс работы с СКВ и выкатки на пром?
4.Как устроен процесс тестирования, все ли используют selenium для автоматизации?
5.Как устроен процесс распределения задач и с помощью чего?
6.Есть ли разделение ролей на разработку новых фич и проектов и поддержку запущенных?

Прошу прощения за большое количество подвопросов, но считаю что их будет не корректно разделять, т.к. вопрос комплексный.
  • Вопрос задан
  • 4912 просмотров
Пригласить эксперта
Ответы на вопрос 3
jakulov
@jakulov
Ну вообще в разных компаниях видел разную организацию, общие моменты обычно такие:

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

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

3. Процесс работы с VCS часто от продукта зависит, но обычно можно использовать общепринятые стандарты и соглашения, вот читайте habrahabr.ru/post/106912

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

5. Тут тоже полно инструментов, выбирают основываясь на списке функций, которые нужны для работы. Мне чаще всего приходилось работать с redmine, phabricator.

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

Ну и, конечно, нужно учитывать специфику проектов и команды, если что-то из этого только мешает, может и стоит отказаться от него. И зачастую что-то свое приходится внедрять, чтобы повысить эффективность работы команды, допиливать стандартные инструменты разработки и контроля задач, разные хуки на git навешивать и т.п.
Ответ написан
akubintsev
@akubintsev
Опытный backend разработчик
1. Какими удобно.
2. На локальных. Для тяжеловесных серверов есть девелопмент-сервера. Но вообще всё может работать и локально.
3. Используем git. Есть мастер бранч для разработки. Для выкатки на продакшн собираются версионные бранчи после полного цикла тестирования. В перспективе на любой таск будет создаваться свой бранч и сливаться в мастер. Прикручен jenkins для ci + системы контроля качества кода. Выкладка происходит через phing в ручном режиме.
4. В основном phpunit для юнит-тестов. Он же применяется и для интеграционных тестов, но они проводятся в ручном режиме из-за своей специфики. Есть API-тесты на java. Пробовали и поведенческие тесты behat для проверки матриц доступа к объектам в зависимости от ролей - не понравилось. Selenium пока не используем, нет необходимости.
5. Redmine. Даже не знаю, что прокомментировать, вроде и так всё понятно.
6. Нет. Пока не тот ещё уровень.
Ответ написан
Комментировать
alexbaum
@alexbaum
JS-разработчик, наставник.
Среды разработки: от vim до webStorm. Компы – в основном MBA 13'.
Удобно, что можно домой взять поработать, полноценный unix (то есть с node, imagemagiс и прочими инструментами нет проблем). Приятная операционка.
Git+github как хранилище кода и разработка через пул-реквесты с ревью.
Для прогона тестов и сборки примеров: TeamCity + selenium grid.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы