В основном на наших проектах и большинстве проектов клиентов хватает окружений под фронтенд-фичи. Задачу с базами мы решали с помощью data transfer и самописных скриптов
Так что отнюдь, за скобками мы это не оставляли и даже записали курс совместно с Яндексом, в котором рассказали о том как это делать более детально
Насчет того, что нужно иметь для того чтобы это всё завелось согласен. Фича-бренчи это сейчас гигиена на уровне "использовать гит в разработке", а окружение под фичу и деплой фичи на окружение это как раз то, что нужно сделать
Насчет "стабильная версия" + "желтый фон" -- намеренно упрощенный пример для того чтобы показать, как может одна фича повлиять на другую. И да, собрать стабильную версию + новая фича это же задача на уровне создать ветку в гите и написать весь код в этой новой ветке. Поэтому исходил из того, что это все умеют. На эту часть тоже можем распространить консалтинг, учим этому джунов в нашей школе https://metaclass.kts.studio/
Насчет выделения окружения для сборки согласен, если проект состоит из тонны микросервисов или монолит прям огромный, то есть куча нюансов, которые нужно будет решить. Но в большинстве проектов такого количества нюансов нет и поэтому динамические окружения сетапятся быстро
Ну а насчет Jenkins не спорю абсолютно, на нём можно сделать кучу всего, сами его использовали до того как перешли на Gitlab, но порог вхождения сильно выше гитлаба
В итоге статья как раз о том, что поднимать среды - это не что-то супер сложное и странно что до сих пор есть компании, в которых уже есть несколько разработчиков, а этого инструмента нет
Про второй кейс скорее соглашусь, но про первый -- часы разработчиков и прочих сотрудников, задействованных в разработке в абсолютном большинстве случаев дороже, чем доп затраты на сервера для динамических окружений
Как часто фичи затрагивают сразу несколько компонентов, которые пишут разные команды? Обычно это происходит редко, потому что для этого и делят одну большую команду на несколько небольших кроссфункциональных
В обычном случае ваша задача решается очень просто и понятно -- одна команда выкатывает тестовую версию, которая "смотрит" в стейджевую версию других компонентов
А насчет баз, действительно это сложнее чем просто развернуть отдельно ветку фронта, но тестирование на больших базах каждой фичи это тоже что-то выходящее за рамки обычных фич в разработке
В целом уверен, что бывают редкие проекты, где проще тестить на одном сервере, но относительно подавляющего большинства это небольшой процент
тимлидом, который видит только User story, но не видит дизайн-макеты, которые будут реализовывать фронтендеры
и разработчиком, который делает то, что сказали предыдущие 2 человека без права изменений,
То что же в итоге получится? На сколько вообще этот процесс будет гибким? На сколько качественным получится продукт?
Мы за качество и командную работу. Если в работу идут дизайн макеты, то по ним сразу понятен не только внешний вид, но и взаимодействие пользователя с интерфейсом. Максимально эффективно в момент старта работ над этой функцией привлечь все стороны процесса: и аналитика, и фронтендера, и бэкендера.
Аналитик расскажет, как это будет использоваться и зачем это нужно, фронтендеры прикинут, какие методы в какой момент будут дергать, а бэкендеры -- какие данные откуда будут брать и как обрабатывать. На выходе получается оптимальное решение, а не "ну это до меня решили, придется делать как сказали, а не как по-нормальному"
Так что в идеальном мире как раз все участники знают, какую фичу захотел бизнес, зачем он ее захотел, почему мы реализуем именно так и это наиболее оптимальная реализация исходя из всех вводных
Пробовал так тоже сделать, но на сколько я помню, автоматом в гугл мит не получилось залететь, даже если меня пригласили во встречу
Ну и справедливости ради, полноценно пользоваться календарем в таком случае не получится. Приглашения, приходящие на корп почту не будут попадать в этот акк
Если у вашей компании уже есть Google Workspace, то моя инструкция получается не нужна
Настроил отправку писем через мейлрушный SMTP (у нас там корп почта), отправил письмо коллеге на корп почту, всё пришло, в спам не попало
Отправил на другой свой гугловый ящик, тоже пришло, в спам не попало
Ну и самый важный момент -- добавление корп почты как дополнительной не равно получению писем с корп почты и отправки от имени корп ящика. Это просто алиас для гугл акка. Чтобы отправлять и получать нормально надо настраивать интеграцию как с десктопными клиентами, то есть например по POP3 и SMTP
Возможно, вы немного не о том, о чем написано в статье. Инкрементальный подход - это подход, при котором работа над продуктом бьется на инкременты и для каждого инкремента (блока функций) проходится полноценный водопадный процесс: написание полноценной непротиворечивой документации -> разработка -> тестирование
То, что описано в статье это именно подходы к документированию, аспекты в обоих подходах остаются теми же самыми
Документацию можно вести в едином месте и постоянно работать над контролем непротиворечивостью требований ЛИБО просто создавать новые артефакты так, что в них могут быть приняты решения, противоречащие предыдущим артефактам
Не соглашусь и в этом и был посыл статьи -- всё это можно назвать документацией, потому что все эти артефакты описывают поведение системы на разных этапах создания продукта.
Не понимаю вашу логику и не вижу аргументации, почему же нельзя задачи в таск-трекере назвать документацией
Не всё так однозначно, как с родом слова кофе :) Язык -- живая субстанция и тот факт, что этот термин часто употребляется в нашей среде при общении, в статьях и законах именно в том контексте, в котором я его употребил, говорит о том, что рано или поздно просто все признают, что теперь так тоже правильно
Так это же собеседование, как иначе?:)
"Говоришь, что умеешь, а, ну ладно, верим на слово!"?
Лучше поздно, чем никогда!:)
:)
На эту тему у нас есть отдельная статья:) https://habr.com/ru/companies/kts/articles/767224/
В основном на наших проектах и большинстве проектов клиентов хватает окружений под фронтенд-фичи. Задачу с базами мы решали с помощью data transfer и самописных скриптов
Так что отнюдь, за скобками мы это не оставляли и даже записали курс совместно с Яндексом, в котором рассказали о том как это делать более детально
Насчет того, что нужно иметь для того чтобы это всё завелось согласен. Фича-бренчи это сейчас гигиена на уровне "использовать гит в разработке", а окружение под фичу и деплой фичи на окружение это как раз то, что нужно сделать
Насчет "стабильная версия" + "желтый фон" -- намеренно упрощенный пример для того чтобы показать, как может одна фича повлиять на другую. И да, собрать стабильную версию + новая фича это же задача на уровне создать ветку в гите и написать весь код в этой новой ветке. Поэтому исходил из того, что это все умеют. На эту часть тоже можем распространить консалтинг, учим этому джунов в нашей школе https://metaclass.kts.studio/
Насчет выделения окружения для сборки согласен, если проект состоит из тонны микросервисов или монолит прям огромный, то есть куча нюансов, которые нужно будет решить. Но в большинстве проектов такого количества нюансов нет и поэтому динамические окружения сетапятся быстро
Ну а насчет Jenkins не спорю абсолютно, на нём можно сделать кучу всего, сами его использовали до того как перешли на Gitlab, но порог вхождения сильно выше гитлаба
В итоге статья как раз о том, что поднимать среды - это не что-то супер сложное и странно что до сих пор есть компании, в которых уже есть несколько разработчиков, а этого инструмента нет
Может мы просто про разное говорим
Чтобы тестировщик смотрел фичу на своём компе, он же не должен разворачивать на своем компе полную версию сервиса?
А насчет тестового сервера - хоть 2, хоть 4 проблемы те же самые, что описаны в статье:
Фичи влияют друг на друга
Если какие-то фичи откладываются или зависают, то их надо руками отрывать с тестового стенда и не забыть еще это сделать до того как всё разломается
Про второй кейс скорее соглашусь, но про первый -- часы разработчиков и прочих сотрудников, задействованных в разработке в абсолютном большинстве случаев дороже, чем доп затраты на сервера для динамических окружений
Мощности же постоянно дешевеют
вы всерьез рассматриваете вариант, в котором тестировщики и менеджеры смотрят фичу на компе разработчика?:)
Это хорошая возможность для какого-нибудь пет проекта, но для продакшна это ж моветон
Как часто фичи затрагивают сразу несколько компонентов, которые пишут разные команды? Обычно это происходит редко, потому что для этого и делят одну большую команду на несколько небольших кроссфункциональных
В обычном случае ваша задача решается очень просто и понятно -- одна команда выкатывает тестовую версию, которая "смотрит" в стейджевую версию других компонентов
А насчет баз, действительно это сложнее чем просто развернуть отдельно ветку фронта, но тестирование на больших базах каждой фичи это тоже что-то выходящее за рамки обычных фич в разработке
В целом уверен, что бывают редкие проекты, где проще тестить на одном сервере, но относительно подавляющего большинства это небольшой процент
По ссылке будет развернутый на сервере проект
Отличное название, возьмем на вооружение:)
Это как раз пункт про нативный интерфейс:)
По нашим данным новость на хабре генерирует нам наибольшую долю заявок :)
С вас 20$
Если жестко разделить работу между:
аналитиком, который не будет сам писать этот код,
тимлидом, который видит только User story, но не видит дизайн-макеты, которые будут реализовывать фронтендеры
и разработчиком, который делает то, что сказали предыдущие 2 человека без права изменений,
То что же в итоге получится? На сколько вообще этот процесс будет гибким? На сколько качественным получится продукт?
Мы за качество и командную работу. Если в работу идут дизайн макеты, то по ним сразу понятен не только внешний вид, но и взаимодействие пользователя с интерфейсом. Максимально эффективно в момент старта работ над этой функцией привлечь все стороны процесса: и аналитика, и фронтендера, и бэкендера.
Аналитик расскажет, как это будет использоваться и зачем это нужно, фронтендеры прикинут, какие методы в какой момент будут дергать, а бэкендеры -- какие данные откуда будут брать и как обрабатывать. На выходе получается оптимальное решение, а не "ну это до меня решили, придется делать как сказали, а не как по-нормальному"
Так что в идеальном мире как раз все участники знают, какую фичу захотел бизнес, зачем он ее захотел, почему мы реализуем именно так и это наиболее оптимальная реализация исходя из всех вводных
Если это враньё, то откуда тогда появилось интервью Филиппа, выпускника курса?:)
Пробовал так тоже сделать, но на сколько я помню, автоматом в гугл мит не получилось залететь, даже если меня пригласили во встречу
Ну и справедливости ради, полноценно пользоваться календарем в таком случае не получится. Приглашения, приходящие на корп почту не будут попадать в этот акк
Спасибо, изучу подробности
Если у вашей компании уже есть Google Workspace, то моя инструкция получается не нужна
Настроил отправку писем через мейлрушный SMTP (у нас там корп почта), отправил письмо коллеге на корп почту, всё пришло, в спам не попало
Отправил на другой свой гугловый ящик, тоже пришло, в спам не попало
Ну и самый важный момент -- добавление корп почты как дополнительной не равно получению писем с корп почты и отправки от имени корп ящика. Это просто алиас для гугл акка. Чтобы отправлять и получать нормально надо настраивать интеграцию как с десктопными клиентами, то есть например по POP3 и SMTP
Отвечу по пунктам:
Речь о документации вида юзерстори, юзкейсах, ЧТЗ
Возможно, вы немного не о том, о чем написано в статье. Инкрементальный подход - это подход, при котором работа над продуктом бьется на инкременты и для каждого инкремента (блока функций) проходится полноценный водопадный процесс: написание полноценной непротиворечивой документации -> разработка -> тестирование
То, что описано в статье это именно подходы к документированию, аспекты в обоих подходах остаются теми же самыми
Документацию можно вести в едином месте и постоянно работать над контролем непротиворечивостью требований ЛИБО просто создавать новые артефакты так, что в них могут быть приняты решения, противоречащие предыдущим артефактам
Не соглашусь и в этом и был посыл статьи -- всё это можно назвать документацией, потому что все эти артефакты описывают поведение системы на разных этапах создания продукта.
Не понимаю вашу логику и не вижу аргументации, почему же нельзя задачи в таск-трекере назвать документацией
Не всё так однозначно, как с родом слова кофе :)
Язык -- живая субстанция и тот факт, что этот термин часто употребляется в нашей среде при общении, в статьях и законах именно в том контексте, в котором я его употребил, говорит о том, что рано или поздно просто все признают, что теперь так тоже правильно