AstonMartin

Если нужны разные валюты ввода, нужна русскоговорящая поддержка, а бенефициары компании или директор связаны с СНГ, посмотрите OrangePay, ChronoPay и EcommPay. Они международные с набором различных валют и более пластичны европейских и американских коллег.

счет от payoneer на компанию открыт?
если документы на компанию и у директора все в порядке - stripe, adyen, braintreepayments.

Если бесплатно, то весь зоопарк придется у себя разворачивать, некоторые не развернешь(в том плане что в ci хрен интегрируешь), тесты писать вручную, есть утилиты, которые упрощают их написание:
https://github.com/checkly/puppeteer-recorder
https://github.com/SeleniumHQ/selenium-ide
но сложные сценарии писать вручную. А те сценарии где что-то ломается на одном из бразуером обычно всегда сложные. Если у вас ломается только верстка, то это отдельная песня: galenframework.com

Если за денюжки, то https://www.browserstack.com/ и https://saucelabs.com/

Если делать по дешману, то проще просто выписать список критически важных страниц, и перед релизом их вручную чекать. Т.е. развернуть в virtual box, кучу виртуалок с браузерами, туды заходишь и все проверяешь. Так даже лучше. На самом деле все e2e тесты сложны, капризны, имеют свойство периодически ломаться, по разным малообъяснимым причинам.

Или писать полноценное тесты или аутсорсить. Если релизы редкие, то дешевле аутсорсить тестирование.

О, да. Я разработчик и надо мной есть начальники и у меня обратная ситуация, что считают, что я слишком много уделяю внимания обработке ошибок.)))
Видимо кто-то не очень готов к своей работе. Поясню. Любая программа решает не меньше двух задач. Первая - сделать всё правильно при правильных исходных данных и Вторая - не делать первой работы при неправильных исходных данных.
Поскольку первую часть работы сделать относительно просто в силу очевидности, то делать вторую всегда качественно сложнее по причине именно неочевидности. Ну и ещё этому обычно не учат. Обычно все заканчивается на try/catch и думают, что этого достаточно.
Что касается программистов, то обычно с них трудно спросить, почему они не предусмотрели ту или иную обработку ошибок, т.к. они могут быть не в курсе контекста решаемой задачи и что там могут быть за ошибки и за это скорее должен отвечать руководитель проекта (единственная очевидная ошибка - деление на ноль. Всё остальное нужно рассматривать в контексте).
С другой стороны, когда вы выбирали программистов, то стоило бы проверить у них чувство «вкуса» на ошибки, так что тут вопрос тоже к вам.
Не могу дать именно вам однозначного совета, но я бы пообщался с разработчиками на предмет желания делать качественно свою работу, обозначил срок проверки и довёл бы прозрачные параметры оценки работы (возможно и с субъективной оценкой, вы же начальник))). После окончания срока самого слабого увольняете. Ещё до окончания срока оценки можно начать искать сотрудника на бушующее вакантное место, ну, чтобы лучше мотивировать остальных. Понятно, что это стресс для всех, но вполне себе радикальное средство, как химиотерапия, к которому можно прибегнуть, когда ситуация критическая.
Но вам тоже нужно и над собой поработать, чтобы научиться избегать таких проблем, чем их решать. Если вы человек опытный, то делитесь своими знаниями, чтобы ваши разработчики учились у вас, но и вы тоже должны у них учиться, т.к. их опыт тоже постоянно увеличивается и его можно позаимствовать. В общем у вас сейчас слабая обратная связь, раз вы узнаете о проблеме уже после выполнения работы. Я бы какое-то время посидел бы с разработчиками, чтобы посмотреть как они вообще работают, но, чтобы не отсвечивать делал бы какую-то задачу. Вдруг у вас в технологии разработки какая-то проблема, которая мешает качеству?

Мы ожидали увидеть приложение с использованием готовых библиотек для работы с HTTP, базой данных, работы с консолью. А также легко расширяемое и поддерживаемое.

Теперь понятно, что они хотят — но в ТЗ не было указано:

• Под HTTP понимают либы, работающие с PSR 7 или близкие по «духу», например Symfony HTTP Foundation
  
• Под БД понимают Doctrine 2 или Eloquent
  
• По консольным — на рынкке используют как правило Symfony Console
  

Именно это и хотели, предлагаю вам либо объяснить и написать уже на компонентах, либо послать к черту, НО отметить этот момент и на будущее таки делать уточнение, каковы ожидания от задания...
Нескольких людей встречал до фанатизма не принимающих сторонние пакеты, и наоборот... Это нужно учитывать... видел задания на PHP 5.3, видел задания строго на Codeigniter...

Тут на Тостере был пример, когда человек применил композер даже не для сторонней либы, а для внутренних, так на него тимлид сокрушился...
Разве Composer бесполезен в 2017?

Люди разные :)


Материал по компонентной разработке

Елена,
не нужно Symfony ассоциировать с фреймворком — это в первую очередь компоненты — потрясающие компоненты:

• Symfony Console
  
• Symfony HTTP Foundation
  
• Syfony Routing (к слову очень быстрый, недавно ускорили его в 70 раз ребята и сделали самым шустрым компонентом)
  
• Twig
  
• Debug
  

[*!*] В некоторых вакансиях даже указывают, что нужно уметь работать с некоторыми выше перечисленными компонентами :) Пруф: https://novosibirsk.hh.ru/vacancy/25367906

Doctrine — совсем не из Symfony и этот компонент можно использовать где угодно

Zend к слову пошел по тому же пути, например

• для HTTP Request/Response PSR 7 у него есть отличный компонент Zend Diactoros,
  
• для работы с PSR 15 Middleware есть компонент Zend Expressive,
  
• для работы с ролями и правами крутое решение Zend ACL
  

Laravel уже да — фреймворк, и опять же на компонентах, и можно использовать его куски, например у него замечательная ORM (Active Record) — в отличие от AR в Yii2 ее можно (и нужно) использовать в любом кастомном проекте вне фреймворка Laravel или вообще фреймворка там , где Доктрина лишняя


Почитать и посмотреть:

Современный PHP без фреймворков (статья Mail.ru на Хабре)
Консольное приложение (мастер-класс) — собрано из компонента Symfony Console и ORM Eloquent (от Ларавел)
PSR-7 фреймворк от Д.Елисеева

Друзья, все придумано давным давно.
Нет никаких коэффициентов творчества и коэффициентов правок, не нужно городить отсебятину.

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

Далее для каждой из задач выбирается что более приоритетно - ресурсы или результат.
Если результат - то это классический Time&Material - дизайнер пашет пока заказчик не будет удовлетворен результатом, далее счет выставляется по факту.

Если важнее уложиться в ресурсы - делается оценка в стиле "ну за 40 часов я точно нарисую логотип", умножается на количество вариантов дизайна по договору, умножается на юридические и прочие риски.
Расчеты между студией и дизайнером как правило все равно T&M, но если студия верно учла все риски - проблемы в этом нет.

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

PS + Какое должно быть ценообразование для ИТ услуг (разработка)?

Самый простой, в т.ч. по возможностям и только для веба - hellotars.com
Посложнее, пофичастее, для веба и мессенджеров - flowxo.com
Но оба со своими граблями и индусами.

Конечно ставить, склейку в вебмастер сделать и редирект, позиции не потеряются, переводил крупные сайты с большими Тиц в несколько тысяч никаких падений в трафике или тиц не было

"Хочется поменять процесс и на базе TeamCity добавить авто-тесты и некоторую автоматизацию чтобы было так (feature-ветки думал не использовать, так как у нас много небольших правок, а ветки добавляют оверхед):"

В том-то и дело, что авто-тесты без фича веток не очень хорошо будут работать.

Подробнее:
Автотесты обычно должны триггериться на коммит. Но это также означает, что разработчик не тестирует у себя локально приложение, а просто коммитит и ждет ответа от автотеста.
А если он будет коммитить в мастер - то один разработчик может сломать билд для всех.

Если использовать отдельную ветку для автотеста, опять же в нее может закоммитить несколько разработчиков и будет неясно кто кому что сломал.
Поэтому и используется фичабренчи - каждый разработчик создал себе фичабренч типа feature/lalala, и автотест реагирует на коммит в любой бренч по маске feature/*

Если тест успешен - тогда можно мержить в мастер - обычно для этого используется какой-то промежуточный инструмент перед гитом - gitlab, gerrit, bitbucket, где удобно настроить создание pull request-ов так, чтобы они не позволяли мержить, пока нет 1 ревью и 1 успешного билда.

https://habrahabr.ru/company/piter/blog/337170/

Посмотреть
https://www.youtube.com/watch?v=gRmEpUYaS20

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

Если другие разработчики делают git pull и не обращают внимания на изменения - это их проблемы. Хорошим тоном является уведомление от автора правок в composer.json, что остальным стоит его обновить.

Список библиотек и версии обновляются не очень часто, а при каждом релизе, приходится выкачивать одни и те же либы

Вообще говоря композер умеет в кэш и одни и те же версии либ тянутся с кэша.

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

Если нужно именно поднять окружение с проектом - настройте vagrant и пропишите в README как им пользоваться конкретно для вашего проекта.
Что касается людей:
* верстальщики - vagrant
* технические писатели - я конечно не в курсе вашего проекта, но я бы доступ даже к репозиторию не дал, максимум - завел отдельный репозиторий для них.
* ревьюер кода (безопасности) - ревьюер, который не может в composer / консоль?? Шутка не удачная.
* сюда же и вопрос оплаты специалиста - лолшто? Это вообще не связано с окружением вашего проекта, ну вот ни капли.

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

Если у вас проект НЕ opensource - то такого делать в принципе нельзя. Доступ к репозиторию должны иметь специалисты, которые работают с кодом этого проекта и ни кто другой, а composer тут вот ни капли ни при чем!

Вопрос в том, можно ли сохранять папку vendor в git

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

насколько это противоречит принятому стилю

на полностью

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

1. Вы становитесь вендором кода, который взяли где-то, как следствие вы следите за его обновлением, у изначального вендора и вы проводите аналогичные правки в своем проекте. Если так не делать - баги, найденные в этой зависимости сами себя не пофиксят и этот код будет быстро устаревать.
2. В код зависимости появляется соблаз провести собственные наработки - это то, что делать нельзя, иначе процесс обновления будет сложнее на порядки.
3. Ваш репозиторий разбухнет.
4. Композер вашу зависимость придется явно прописать иначе автолоад может ее не подтянуть.

Использует ли кто-нибудь такую практику в своих проектах ?

Пару лет назад работал на крупном проекте, который начинался до появления композера. Когда зависимостей тьма и ты не знаешь, какие из них содержат артефакты собственных наработок, какие обновляются синхронно с официальными вендорами, а какие тянутся из вне приходится тратить кучу времени на выяснение. Это просранное время.

Про git flow знаю, но считаю, что полноценный флоу сейчас для нас не нужен.

как максимально просто реализовать процесс мерджа протестированных фич из дева в мастер?

Вы себе противоречите

В идеале чтобы это делалось прямо из Jira

Конфликты тоже jira править будет?))

По моему вы пытаетесь автоматизировать то, что вам ненужно. Это конечно же хорошо может выглядеть, но опять же, какой в этом смысл? Ну сэкономите вы 5 минут, что с того?

А вот на счет флоу с ветками я бы на вашем месте по раньше разобрался.

как максимально просто реализовать процесс мерджа протестированных фич из дева в мастер?

1. На тестовом сервере резетимся до origin/develop
2. Накатываем ветку с фичей
3. Тестируем
4. Убирам за собой тестовом сервере и опять резетимся до origin/develop
5. Если все ок - ТЛ мерджит фичу в develop

Шаги 1, 2, 4, 5 в сумме занимают минут 5.

На вопрос сложно ответить, не зная на чем вы разрабатываете. Когда я разрабатываю на Django, то у меня в каждом проекте есть пакет settings с тремя модулями: production, development и local. Если для разработки требуются миграции, изменяющие схему, я делаю копию базы (pg_dump | psql) с соответствующим названиям, и в local_settings прописываю название копии.

В одном проекте, где у меня очень много веток и заказчику важно, чтобы все они были независимы (он делает скрупулезный code review по каждой и мержит каждую по отдельности), я немного автоматизировал этот процесс:

database = 'frobnicator'
branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref', 'HEAD']).decode('ascii').strip()
if branch.startswith('python-3'):
    database = 'frobnicator-python3-port'
elif branch == 'master' or branch.startswith('FB-472'):
    database = 'frobnicator-filestack-integration'
else:
    raise RuntimeError('Please, update configuration file to use correct database')

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': database,
        'USER': '',
        'PASSWORD': '',
        'HOST': 'localhost',
        'PORT': '5432',
    }
}

А что вы ему и куда пишете? Если в группу, то по умолчанию он принимает сообщения начинающиеся на / и где упоминают имя бота. Чтобы принимал весь текст /setprivacy disabled сделайте у BotFather

Исключаете конфиг БД из гита (и добавляете его в .gitignore) и оставляете только bd.config.example.
Разработчик копирует example и прописывает свои настройки и этот конфиг не попадёт в гит никогда.

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

Как создание БД у вас устроено я не вкурсе, то-ли вы структуру руками импортируете толи миграции используете, тут сами уж думайте, если руками то разраб. так-же вносит изменения в файлы с структурой.

P.S. Тут в самый раз использование Docker.