Норм коммент) Наименование не соответствует. Статья в целом не про деплой, а про гит, composer, laravel, переменные окружения и пр. Web-приложенния это не только php и laravel. Есть java spring, flask, django, rails, go, js и др. Деплой это не только копирование по ftp, git push и pull и выполнение команд. Есть специальные библиотеки, docker, docker-compose, kubernetes, ci/cd разные.
Проводите дизайн ревью. Совокупность проверки кода и требований позволяет отловить до 70% багов.
Проводите код ревью. Хорошо проверенный код на 90% проще поддерживать. Один час рецензирования сохранить вам 33 часа поддержки. Программисты, которые проводят код ревью на 20% более продуктивны.
Используйте TDD подход. Он сокращает количество багов на 30-40 процентов.
Всё зависит от проекта и от ПМ в команде. У нас сейчас вредный заказчик, мало того, что я комбинирую методологии, так я помимо стараюсь ими гибко управлять. Используем SCRUM и waterfall.
SCRUM
В зависимости от настроения заказчика, которое по моим наблюдениям меняется периодически, то хотят видеть долгосрочный план проекта, перед этим начитавшись и пересказав книги по SCRUM. В данном случае разработчики довольны, ПМ доволен, заказчик доволен. Есть время прогнозировать риски. Работы выполняются по плану. Все с хорошим настроением.
Waterfall или Kanban (в зависимости от ситуации. Если возможно решение только в чёткой последовательности, то waterfall)
Приходит время, часть системы введена в эксплуатацию. Заказчику всё нравится, но он начинает осознавать, что многих фич, которые были убраны из базового функционала изобретаемого в первую очередь и перенесены в долгий ящик в самый низ бэклога, катастрофически не хватает, доказывая что без этого никак нельзя, и это нужно вчера, но согласен чтобы это было завтра, игнорируя все составленные и утверждённые планы. В кратчайшие сроки теперь требуется получить множество мелкого дополнительного (не важного) функционала, мы временно переходим на waterfall, сдвигая спринты и сроки по задачам заложенным в них, до тех пор пока заказчик не будет удовлетворён. Таким образом забывая SCRUM, мы бережём нервы всех заинтересованных лиц, участвующих в проекте, отбрасывая споры и воспоминания о каких-либо договорённостях и инструкциях.
SCRUM и Waterfall(Kanban).
Но в большинстве случаев на приходится комбинировать 2 методологии, подстраивая JIRA под интересы всех сторон. С некоторыми игрушками запущенными в продакшене, заказчик не успевает наиграться и считает, что это помогает бизнесу, поэтому требует выполнить определённое количество задач оставленных в беклоге, которые должны были делаться в последнюю очередь, но соблюдая и двигаясь по поставленным задачам заложенным в спринты минимально сдвигая сроки. В этом случае для меня по практике является выделение одного или нескольких разработчиков на задачи по kanban и перенося или сдвигая задачи которые были запланированы в спринтах. Таким образом создаётся возможность контролировать оперативную работу, задачи, а также следовать составленному плану с минимальными изменениями.
В заключение хочу сказать, что нет идеальной методологии. Есть много факторов влияющих на работу, включая погоду. Нужно просто подбирать оптимальные и действенные инструменты, лавировать между запросами, предупреждать и обсуждать цели и задачи своевременно с заинтересованными сторонами.
Спасибо за интересную статью!
Спасибо за ваши вопросы, они очень интересны и я тоже хочу обратить внимание, что мы никак не против iiko, а всего лишь хотим представить наше решение в качестве альтернативы, ну и быть конечно же лучше)) Буду отвечать по порядку:
1) iiko предоставляет, а у нас уже все развернуто и настроено. Всё, что нужно — это зарегистрироваться в нашей системе. Нам не нужны специалисты для установки и настройки программного обеспечения. А чтобы изменить архитектуру или важные элементы нашей экосистемы, нам не потребуется всех умолять обновить по или сопровождать версионность продуктов (кроме версионности апи разумеется).
2) Возможность управлять ресторанами из любого устройства, телефон, планшет… и с любого места без установки специализированного по. Сравнивать показатели ресторанов/открытых смен и все-конечно же риал-тайм. Но и в тоже время никто нам не запрещает выпускать приложения для устройств общающихся через API сервис. Также мы всегда может открыть свое api для общества.
3) iiko обладает бесспорно широким функционалом и интегрирован со множеством различных сервисов. Насколько это сделано неплохо у них, конечно решать вам. Но с моей точки зрения, так как мы с этого начали, то в этом мы преуспеваем. Я не анализировал плотно насколько хорошо устроена в iiko архитектура. В нашей системе есть общие таблицы для ресторанов, различные методы для моделей осуществляющие такие операции как, финансы, операции связанные с персоналом, которые перемещаются между ресторанами, перемещение между складами различных ресторанов. Хотелось бы дополнить это тем, что в случае успешного роста нашего продукта, перед нами открываются огромные возможности предоставления средних и других показателей среди всех ресторанов подключенных к нашей системе, по регионам, по поставщикам, анализу закупок и прочее.
Наша первоочередная цель сделать надежную масштабируемую инфраструктуру, покрыть ее тестами и выпускать обновления и новые фичи как можно чаще за короткий промежуток времени, не ежемесячно, а ежедневно и еще чаще.
Если немного отойти от разговора, то для меня это как взять любую существующую CRM в оболочке толстого клиента и потом попробовать в использовании облачную AmoCRM, которая проста как 2 пальца, постоянно развивающаяся и обновляющаяся, в большинстве случаев не требующая обучения пользователей и поддержки техническими специалистами, не смотря на функциональную схожесть всех CRM. Так и мы, нацелены на простоту и удобство, но с мощным сердцем и движком внутри, и возможностью радовать конечных пользователей ежедневно.
Если брать в расчет сложность и стоимость обслуживания по сравнению с iiko, то нам не нужно развертывать отдельную бд для компаний или плодить экземпляры веб приложений под разных тенантов, мы следим только за нагрузкой http запросов к одному серверу, учитывая, что наибольшую нагрузку создают POS терминалы, но даже для одного ресторана с плотным приходом гостей в течение дня это копеечная нагрузка. Из чего следует, что большая часть нашего времени нашей команды проходит в улучшении и разработке сервиса, не тратя большую часть ресурсов на обслуживание системы. Также при пользовании системой пользователями, любой случившейся эксепшен моментально попадает нам в багтрекинговую систему сообщая всю информацию о файлах, коде и передаваемых параметрах, где произошла ошибка, с помощью чего разработчики также моментально устраняют выявившиеся проблемы и пользуются возможностью покрыть тестами выявленные места.
Соглашусь с вами, что перегруженность информации и интерфейса плохо сказывается на использовании!
Мы очень сосредоточены на качестве нашего продукта, а также его гибкости. Но не смотря на то, что можно создавать кучу параметров для всех процессов, мы всячески избегаем этого, делая интерфейс простым и интуитивным, выявляя полезные фичи и не используемые. Если что-то не зашло, мы это не оставляем, а смело избавляемся. А также на протяжении поддержки уже введенных в эксплуатацию модулей мы постоянно что-то рефакторим, постоянно меняем и получаем обратную связь, делая все проще, лучше и полезнее. Прислушиваемся к мнению и идеям как и пользователей, так и разработчиков и всех остальных принимающих участие в жизни нашего растущего коллектива. И спасибо за ваши комментарии!
Если сравнивать функционал, то конечно же, мы еще уступаем iiko. Но на мой взгляд все системы автоматизации ресторанного бизнеса достаточно примитивны и имеют схожий функционал, и я не могу честно рассказать, что именно есть у нас и чего нет у iiko, так как в подробностях не знаком со всем функционалом iiko. Признаюсь, что мы заглядываем иногда в документацию iiko и rkeeper, чтобы подчерпнуть для себя, что-то уже устоявшееся или удостовериться в качестве нашего продукта, опираясь на собственные разработки. И в первую очередь я хотел бы обратить ваше внимание не на обширность функционала в текущей версии системы, а построение архитектуры и все потенциальные возможности данного подхода.
Если не брать в расчет разработку клиентских приложений для POS терминалов, то:
1) Мы сосредоточены на бэкенде в облаке, без промежуточных серверов, которые нужно устанавливать в каждый ресторан.
2) Мы веб-сервак, что дает нам возможность, изобретать API, webhooks, и нам не тяжело поддерживать кроссплатформенность, в связи с тем, что все использование происходит через браузер.
3) Изначально наша архитектура сводится к работе компании управляющей несколькими ресторанами, а не изолированность каждого ресторана, что дает нам гораздо больше интересных метрик и показателей, что как раз дает нам еще больше интересных фич)
На фотографии изображён наш ресторан, находящийся на Бол. Никитская 22/2. С радостью ждем вас в гости! Также вы можете на сайте cafereceptor.ru ознакомиться с другими нашими ресторанами и забронировать столик)
Команда внутренняя, супер умы, команду очень ценим и любим!
Из основного вот это:
Бэк: nginx, ruby on rails, puma, redis, postgresql, sidekiq, mailgun, iqsms, devise, cancancan, milia…
Фронт: bootstrap, backbone, ember, haml, jquery…
Остальное: git, newrelic, logentries, jira, trello, omniplan, moqups, lucid, uml иногда, ну и все это замыкается на lita с ботиками:)
Вы можете следить за нами на http://receptorlife.ru. Это наш блог о нашей сети. Также надеюсь я буду публиковать нашу историю, результаты и исследования здесь. Спасибо, что проявляете интерес!))
Когда, есть где тестировать продукт, он растет очень быстро. У нас сейчас 4 ресторана и управляем ими из одного аккаунта. Без этого уже не можем представить нашу работу. А идей уже на 10 листов, и появляются каждый день. И очень приятно ненароком услышать от официантов, что стало гораздо удобнее работать с системой. :)
Да, iiko же нас и мотивирует много делать работы. Только мы на тонком клиенте и делаем управление простым, удобным и интуитивным, и у нас будет не такой зоопарк интеграций и мы сосредоточены на облаке.
Многим нужен мозг) Интеграции — это наша мечта до них добраться и мы в скором времени будем их делать. Архитектура приложения строится исходя из масштабируемости, адаптированности, и возможности интеграций со всеми интересующими нас вопросами.
Сопровождение системы нам дается легкой кровью благодаря инновационным подходам к получению обратной связи и распределением задач. Один человек может спокойно сопровождать и обслуживать систему на данный момент. Другое дело вопрос разработки, и мы все еще находимся в агрессивной стадии разработки, в которой находится 5 человек.
Для внедрения такой системы, нам достаточно зарегистрировать вашу компанию в системе и вам придет приглашение на почту, где вы сможете пройти регистрацию до конца и указать себе пароль. После вы можете создавать и управлять ресторанами, пользователями, номенклатурой, складами и прочими плюшками.
И соответственно потребуется установить клиенты для POS терминалов (на данный момент поддерживается только Windows) и один агент в котором нужно указать выданный вам авторизационный ключ(токен), общающийся с нашим сервером через API и передающий все данные продаж при наличии интернета.
Все, что вам потребуется наличие терминалов с Виндой на борту. Это SaaS приложение, соответственно если мы решим предоставить наши услуги, то это будет подписка на сервис за промежуток времени.
Норм коммент) Наименование не соответствует. Статья в целом не про деплой, а про гит, composer, laravel, переменные окружения и пр. Web-приложенния это не только php и laravel. Есть java spring, flask, django, rails, go, js и др. Деплой это не только копирование по ftp, git push и pull и выполнение команд. Есть специальные библиотеки, docker, docker-compose, kubernetes, ci/cd разные.
Откуда такие данные в % и чем они подкреплены?
SCRUM
В зависимости от настроения заказчика, которое по моим наблюдениям меняется периодически, то хотят видеть долгосрочный план проекта, перед этим начитавшись и пересказав книги по SCRUM. В данном случае разработчики довольны, ПМ доволен, заказчик доволен. Есть время прогнозировать риски. Работы выполняются по плану. Все с хорошим настроением.
Waterfall или Kanban (в зависимости от ситуации. Если возможно решение только в чёткой последовательности, то waterfall)
Приходит время, часть системы введена в эксплуатацию. Заказчику всё нравится, но он начинает осознавать, что многих фич, которые были убраны из базового функционала изобретаемого в первую очередь и перенесены в долгий ящик в самый низ бэклога, катастрофически не хватает, доказывая что без этого никак нельзя, и это нужно вчера, но согласен чтобы это было завтра, игнорируя все составленные и утверждённые планы. В кратчайшие сроки теперь требуется получить множество мелкого дополнительного
(не важного)функционала, мы временно переходим на waterfall, сдвигая спринты и сроки по задачам заложенным в них, до тех пор пока заказчик не будет удовлетворён. Таким образом забывая SCRUM, мы бережём нервы всех заинтересованных лиц, участвующих в проекте, отбрасывая споры и воспоминания о каких-либо договорённостях и инструкциях.SCRUM и Waterfall(Kanban).
Но в большинстве случаев на приходится комбинировать 2 методологии, подстраивая JIRA под интересы всех сторон. С некоторыми игрушками запущенными в продакшене, заказчик не успевает наиграться и считает, что это помогает бизнесу, поэтому требует выполнить определённое количество задач оставленных в беклоге, которые должны были делаться в последнюю очередь, но соблюдая и двигаясь по поставленным задачам заложенным в спринты минимально сдвигая сроки. В этом случае для меня по практике является выделение одного или нескольких разработчиков на задачи по kanban и перенося или сдвигая задачи которые были запланированы в спринтах. Таким образом создаётся возможность контролировать оперативную работу, задачи, а также следовать составленному плану с минимальными изменениями.
В заключение хочу сказать, что нет идеальной методологии. Есть много факторов влияющих на работу, включая погоду. Нужно просто подбирать оптимальные и действенные инструменты, лавировать между запросами, предупреждать и обсуждать цели и задачи своевременно с заинтересованными сторонами.
Спасибо за интересную статью!
1) iiko предоставляет, а у нас уже все развернуто и настроено. Всё, что нужно — это зарегистрироваться в нашей системе. Нам не нужны специалисты для установки и настройки программного обеспечения. А чтобы изменить архитектуру или важные элементы нашей экосистемы, нам не потребуется всех умолять обновить по или сопровождать версионность продуктов (кроме версионности апи разумеется).
2) Возможность управлять ресторанами из любого устройства, телефон, планшет… и с любого места без установки специализированного по. Сравнивать показатели ресторанов/открытых смен и все-конечно же риал-тайм. Но и в тоже время никто нам не запрещает выпускать приложения для устройств общающихся через API сервис. Также мы всегда может открыть свое api для общества.
3) iiko обладает бесспорно широким функционалом и интегрирован со множеством различных сервисов. Насколько это сделано неплохо у них, конечно решать вам. Но с моей точки зрения, так как мы с этого начали, то в этом мы преуспеваем. Я не анализировал плотно насколько хорошо устроена в iiko архитектура. В нашей системе есть общие таблицы для ресторанов, различные методы для моделей осуществляющие такие операции как, финансы, операции связанные с персоналом, которые перемещаются между ресторанами, перемещение между складами различных ресторанов. Хотелось бы дополнить это тем, что в случае успешного роста нашего продукта, перед нами открываются огромные возможности предоставления средних и других показателей среди всех ресторанов подключенных к нашей системе, по регионам, по поставщикам, анализу закупок и прочее.
Наша первоочередная цель сделать надежную масштабируемую инфраструктуру, покрыть ее тестами и выпускать обновления и новые фичи как можно чаще за короткий промежуток времени, не ежемесячно, а ежедневно и еще чаще.
Если немного отойти от разговора, то для меня это как взять любую существующую CRM в оболочке толстого клиента и потом попробовать в использовании облачную AmoCRM, которая проста как 2 пальца, постоянно развивающаяся и обновляющаяся, в большинстве случаев не требующая обучения пользователей и поддержки техническими специалистами, не смотря на функциональную схожесть всех CRM. Так и мы, нацелены на простоту и удобство, но с мощным сердцем и движком внутри, и возможностью радовать конечных пользователей ежедневно.
Если брать в расчет сложность и стоимость обслуживания по сравнению с iiko, то нам не нужно развертывать отдельную бд для компаний или плодить экземпляры веб приложений под разных тенантов, мы следим только за нагрузкой http запросов к одному серверу, учитывая, что наибольшую нагрузку создают POS терминалы, но даже для одного ресторана с плотным приходом гостей в течение дня это копеечная нагрузка. Из чего следует, что большая часть нашего времени нашей команды проходит в улучшении и разработке сервиса, не тратя большую часть ресурсов на обслуживание системы. Также при пользовании системой пользователями, любой случившейся эксепшен моментально попадает нам в багтрекинговую систему сообщая всю информацию о файлах, коде и передаваемых параметрах, где произошла ошибка, с помощью чего разработчики также моментально устраняют выявившиеся проблемы и пользуются возможностью покрыть тестами выявленные места.
Мы очень сосредоточены на качестве нашего продукта, а также его гибкости. Но не смотря на то, что можно создавать кучу параметров для всех процессов, мы всячески избегаем этого, делая интерфейс простым и интуитивным, выявляя полезные фичи и не используемые. Если что-то не зашло, мы это не оставляем, а смело избавляемся. А также на протяжении поддержки уже введенных в эксплуатацию модулей мы постоянно что-то рефакторим, постоянно меняем и получаем обратную связь, делая все проще, лучше и полезнее. Прислушиваемся к мнению и идеям как и пользователей, так и разработчиков и всех остальных принимающих участие в жизни нашего растущего коллектива. И спасибо за ваши комментарии!
Если не брать в расчет разработку клиентских приложений для POS терминалов, то:
1) Мы сосредоточены на бэкенде в облаке, без промежуточных серверов, которые нужно устанавливать в каждый ресторан.
2) Мы веб-сервак, что дает нам возможность, изобретать API, webhooks, и нам не тяжело поддерживать кроссплатформенность, в связи с тем, что все использование происходит через браузер.
3) Изначально наша архитектура сводится к работе компании управляющей несколькими ресторанами, а не изолированность каждого ресторана, что дает нам гораздо больше интересных метрик и показателей, что как раз дает нам еще больше интересных фич)
Из основного вот это:
Бэк: nginx, ruby on rails, puma, redis, postgresql, sidekiq, mailgun, iqsms, devise, cancancan, milia…
Фронт: bootstrap, backbone, ember, haml, jquery…
Остальное: git, newrelic, logentries, jira, trello, omniplan, moqups, lucid, uml иногда, ну и все это замыкается на lita с ботиками:)
И соответственно потребуется установить клиенты для POS терминалов (на данный момент поддерживается только Windows) и один агент в котором нужно указать выданный вам авторизационный ключ(токен), общающийся с нашим сервером через API и передающий все данные продаж при наличии интернета.
Все, что вам потребуется наличие терминалов с Виндой на борту. Это SaaS приложение, соответственно если мы решим предоставить наши услуги, то это будет подписка на сервис за промежуток времени.