Построение правильного процесса веб-разработки

Всем привет! Компания, в которой я тружусь, сейчас находится в процессе перестройки. С ростом количества работы и приходом на обслуживание больших проектов появилось понимание, что надо «шоб как у всех» с Gitом, Scrumом и т.д.

Поэтому решил попросить у сообщества поделиться опытом, как правильно организовать процесс веб-разработки? При разработке используем CMS Bitrix (на PHP).

Особенно интересуют вопросы:

1. С помощью каких практик уменьшать количество багов при разработке (до тестирования)?

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

3. Насколько автотестирование влияет на себестоимость проекта? Стоит ли внедрять его везде, или предлагать заказчику сделать выбор?

4. Как развивать разработчиков? Конференции — это конечно прекрасно, но их очень мало по теме веб (Днепропетровск). Курсы — сами понимаете.

5. Как выглядит сама архитектура процесса? У каждого разработчика своя виртуалка, откуда он сливает код на тестовую копию, а оттуда уже на продакшн? Или все пишут код локально, потом он заливается на тестовую копию?

6. Рефакторинг кода стоит продавать клиентам или делать бесплатно, как дополнительую плюшку?

7. При настроенной системе контроля версий как решается вопрос с базой данных? У тестовой копии должна быть своя база(тогда как настроить процесс ее актуализации) или она должна быть подключена к рабочей(тогда как быть с задачами, затрагивающими изменения в БД) ?

8. Как у вас построен бизнес процесс? Кто принимает задачу, кто ее уточняет, общаются ли разработчики с заказчиками?

P.S. Я понимаю, что возможно ответы уже есть в какой-то замечательной статье/книге. Но хотел бы услышать, как это работает на практике от опытных коллег.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Два слова — тестирование и кодревью.

что надо «шоб как у всех» с Gitом
ого, в компании не юзают гит? Даже в фрилансе его уже все юзают, кто пишет чуть больше скрипта. Ну вы храбрые конечно)

Ну если так то да. Но он же ж вроде не тру на сегодняшний день.

я верстальщиков на нем держу.
потому что он много проще гита.

вполне согласен с
меркуриал — это гит после того как убрать с него навороты и издержки эволюции.

хотя для программного кода гит все же предпочтительней.

как правильно организовать процесс веб-разработки?
способов много, несмотря на ограниченный набор основных подходов.
возможно ответы уже есть в какой-то замечательной статье/книге.
налаживая работу своего отдела начал писать Сам себе ПиэМ.
но до версии 1.0 похоже дойду не скоро. но вам могут пригодиться ссылки оттуда.
1. С помощью каких практик уменьшать количество багов при разработке (до тестирования)?
зависит от причины багов. анализировали их?

например частая — плохая коммуникация и распределение ролей.

или — коллективная безответственность.

или наоборот — жесткая ответственность на менеджерах, и полное бесправие винтиков-исполнителей.

2. Есть небольшие клиенты, которые приносят мало денег, а затраты на подключение их к системе контроля версий, актуализацию тестовых копий их сайтов уходит много ресурсов. Что делать в таких случаях?
автоматизировать конечно. искать-писать скрипты.

и регламентировать то что дорого автоматизировать. например для CMSок порою сложно автоматизировать некоторые действия которые в пару кликов делаются из их админки. значит — должно быть написано — что и как кликать.

Насколько автотестирование влияет на себестоимость проекта?
что такое — автотестирование?
Как развивать разработчиков?
придумывать эвалюэйшн планы И(!) выделять время на их выполнение.
5. Как выглядит сама архитектура процесса?
от выбранного процесса зависит.

ниже вкратце уже дали рецепт, вполне годный.

6. Рефакторинг кода стоит продавать клиентам или делать бесплатно, как дополнительую плюшку?
В общем случае — рефакторинг НЕ получится продать клиенту.
Поэтому «за свой счет».
И, помня, что чисто не там где убирают, а там где не мусорят. конечно, любой код со временем начинает пахнуть.
но, ошибки в архитектуре — самые дорогие в исправлении.
то же и с рефакторингом — что именно приходится рефакторить — настолько и будут затраты.
7. При настроенной системе контроля версий как решается вопрос с базой данных?
плохо решается. очень плохо. хотя рецепты есть конечно. и схему даже версионируют, и пишут скрипты которые следят за соответствием схемы и кода.
У тестовой копии должна быть своя база(тогда как настроить процесс ее актуализации) или она должна быть подключена к рабочей
скорее должна быть своя база

хотя бы потому что — а как при подключении рабочей базы тестить фичи, требующие другой схемы БД?

и даже по поводу контента — например вполне можно держать в тестовой базе контент который пытается сломать верстку. на своей девовской машине у меня обязательно такой имеется :)

Как у вас построен бизнес процесс? Кто принимает задачу, кто ее уточняет, общаются ли разработчики с заказчиками?
неважно как у нас, важно —

1. а кто у вас отвечает за существующий процесс? кто у вас обладает полномочиями его менять?

2. у тех у кого есть полномичия — какой vision этих процессов сейчас, и главное — в будущем? и насколько они сами, по своим убеждениям способны изменить процессы?
например они авторитарны, тогда никакие советы по усилению горизонтальных связей управления приняты ими не будут.

достичь же успешной деятельности, повторюсь, можно тьмой способов. и авторитарными в том числе.
например я не сошелся с руководством в vision, и поэтому вынужден был уйти.

а зависит от того что вы возможно сами не замечали. не говоря о том, что НЕ написали всего о вашей команде :)

Поэтому решил попросить у сообщества поделиться опытом, как правильно организовать процесс веб-разработки? При разработке используем CMS Bitrix (на PHP).

Перестать использовать CMS Bitrix :)

Не так просто это. Хотя хотим. Но пока не можем. Репутация, клиенты и все такое только на рынке Bitrix, в других местах надо все с нуля начинать.

Спасибо, все очень доходчиво. Взять лида — заманчивое предложение, но наш лид против ))
Вопрос вот в чем:

За деплой через фтп веток, кроме develop на стейджинг и master на прод
Тоесть все-таки есть случаи, когда кто-то берет лапками файлы и закидывает их на прод через FTP и это нормально?Или я не правильно понял?

на проде проект тоже может быть под гитом, легко откатиться на предыдущую версию, если произошел факап, но надо следить что бы конфиги были исключены из гита

не очень нормально, но если автоматический деплой не настроен, то, в принципе, можно, только круг лиц, которые таки могут это сделать должен быть жестко ограничен, ну и естественно деплоить так можно только то, что уже закоммиченно в репозиторий

Тоесть все-таки есть случаи, когда кто-то берет лапками файлы и закидывает их на прод через FTP и это нормально?
в этом и есть сила PHP. особенно для починки прода.

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

по поводу автоматизации — гит упоминали. и отмазки — а не все хостеры предоставляют — забудьте.
выбирайте тех что предоставляют. а клиентов — переубеждайте всеми доступными способами сменить хостера без гита на хостера с гитом.
кстати и по поводу версий PHP. что за — «а у хостера только PHP 5.3» — на йух такого хостера!

Даже если хостер не предоставляет деплой через гит, ничего не мешает написать скрипт,
да, сам думал найти-наваять такой.
заюзать какое-то готовое решение на эту тему, я почему-то уверенна в его существовании.
конечно. задача-проблема у пыхеров частая.
например:
deployer.org
github.com/dg/ftp-deployment

но потом передумал. потому что — а полно хостеров с гитом :)

Подписаться на комментарии