да нет, потому что это часто дешевле и не тратит ресурсы

Вопрос кто это разрулит или кого (человека купить) - проще всё из коробки

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

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

начали про менеджеров, закончили за вендоров

тут всё зависит от конкретной ситуации, компании, сервиса, того, сколько людей и чем они занимаются

Или как говорят - начали за здоровие а закончили за упокой

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

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

всё просто. Человек утверждает что программерский опыт делает менджера хорошим, а его отсутсвие плохим.

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

но опыт программирования - это плюс, хорошо, если он есть

В наших реалиях, есть два типа менеджеров - те кто умеют программировать и те кто не умеют вообще ничего. Даже не знаю какой тип страшнее

менеджмент проекта - это вот про это , например, https://www.youtube.com/watch?v=I5xhs3T2jX8

если человек плохо решает этот тип задач - он плохой менеджер проекта, если хорошо решает - хороший) если он умеет программировать - это ему поможет)

кроме менеджеров проекта есть много других видов менеджмента

да тут никто не ебет такого, ты чо

погодь. но чтобы быть девопсоминадо часть про дев хотя бы предстпвлять?

Посоны управлять это ебаный дар

Талант

Это не опыт

Если у тебя нет таланта - ты хоть обосрись

Хоть в чем бэкграунд приобрети

знали бы - давно ответили, а так, ты просто срач очередной

ну вообще кстати ответили. просто кроме меня никто не заметил

Хоть, сука, Макиавелли обчитайся

Хоть Форда

Талант это, братва

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

так. стой. тормози. ты помнишь откуда меня знаешь?

лучший бэкграунд для управления - управление

Посоны управлять это ебаный дар

+

так. стой. тормози. ты помнишь откуда меня знаешь?

))

так. стой. тормози. ты помнишь откуда меня знаешь?

нубом ты себя называл? я не считаю тебя нубом если что)

))

про нубов он мне тут втирает ))

нубом ты себя называл? я не считаю тебя нубом если что)

но гет стартед просил я доя себя. мне кстати норм все ответили

ну вот, Чистяков поавильно говорит

но гет стартед просил я доя себя. мне кстати норм все ответили

зависит от направления) по каждому направлению там своё будет)

зависит от направления) по каждому направлению там своё будет)

да любое. вот тут пр git-flow говорили, про tdd, какое-то слово на "с" сказали, но это перебор для команды из целого меня

Гит-флоу херня, там все быстро поймешь

ну вот, Чистяков поавильно говорит

про менеджмент? думаю, тут всё вместе нужно, и знания и предрасположенность/взгляды на мир

да любое. вот тут пр git-flow говорили, про tdd, какое-то слово на "с" сказали, но это перебор для команды из целого меня

git flow хорошая практика, по ней есть статья на Хабре, 1 статья и ты в теме

Гит флоу полностью ортогонален хорошей практике

Хорошая практика - делать pull —rebase в локальных ветках

да любое. вот тут пр git-flow говорили, про tdd, какое-то слово на "с" сказали, но это перебор для команды из целого меня

а вот про youtube gitlab говорили

tdd - это разработка через тестирование, сначала написал тесты, тест завалился, потом сделал так, чтобы не завалился, подрефакторил ... это повышает надёжность системы, но замедляет темпы разработки

про менеджмент? думаю, тут всё вместе нужно, и знания и предрасположенность/взгляды на мир

да

Скажем так - гитфлоу лучше, чем никакого флоу

git flow мне нравится)

точнее, я вообще git не использую, у меня оно называется hg flow

но суть та же

http://nvie.com/img/git-model@2x.png

Гит флоу полностью ортогонален хорошей практике

так. ок. какая хорошая практика? я не в курсе. я делаю F7 myproject999 в mc, и побежали. ну да, ещё git init. а по вечерам git commit; git push. вот и весь мой флоу. ок, до 2006 не было никакого vcs. т.е. было вечером F5 myproject333-200401012230

так. ок. какая хорошая практика? я не в курсе. я делаю F7 myproject999 в mc, и побежали. ну да, ещё git init. а по вечерам git commit; git push. вот и весь мой флоу. ок, до 2006 не было никакого vcs. т.е. было вечером F5 myproject333-200401012230

Ты если в одно лицо пишешь, то и нарм

А так ваще нам надо бы с пацанами собраться статью написать

Ты если в одно лицо пишешь, то и нарм

ну я всю жизнь в одно лицо пишу. более того, в одно лицо все гениальное пишется. что, теперь пожизненно mc F7 F5, ай лайк ту мув ит?

ну я всю жизнь в одно лицо пишу. более того, в одно лицо все гениальное пишется. что, теперь пожизненно mc F7 F5, ай лайк ту мув ит?

я большинство проектов веду по hg flow, но реально там 2 потока

стабильный и девелоп

это если я 1 программирую и я имею возможность не прыгать с задачи на задачу, а всегда имею запас времени

то есть 1 ветка всегда стабильная, из неё можно делать докер-образы или что-нибудь там ешё, а в другой я разрабатываю и делаю пуш каждые сутки, если там что-то поменялось за сутки (она может не быть стабильной)

но в пределах суток я всё равно разбиваю на разные коммиты (по задачам), если их было несколько

ну, а git flow особенно удобен, если у тебя не 1 человек, а команда побольше, какой-нибудь стартап, большинство задач малого бизнеса отлично укладывается в эту модель, а эта схема с 2 ветками как у меня - это частный (урезанный) случай flow

то есть в самом простом случае у тебя 2 потока(ветки), кодишь в develop, коммитишь, потом hg flow develop promote -t "1.1.3" и hg push и он в основной ветке делает новый релиз, дальше твоя CI система видит этот релиз, делает образ, тестирует его, деплоит (если тесты ок) или скидывает на почту/в ТГ/в HipChat/в Slack сообщение с ошибками

https://docs.gitlab.com/ee/workflow/gitlab_flow.html вот еще такое есть

а есть какое-нибудь гет стартед цикла разработки для одного-двух человек? прямо воо методичка для начинающего? что когла куда комитить, что где ci, что где cd

Джез Хамбл, Дэвид Фарли. Непрерывное развёртывание ПО. В чате @devops_ru по ссылке можно найти.

https://docs.gitlab.com/ee/workflow/gitlab_flow.html вот еще такое есть

они там как-то по-детски наехали на Git Flow

> "The first problem is that developers must use the develop branch and not master, master is reserved for code that is released to production. It is a convention to call your default branch master and to mostly branch from and merge to this. " можно по умолчанию выбрать любой бранч, они могут называться как угодно и быть какими угодно, при инициализации в hg flow можно выбрать это (в git flow, полагаю, аналогично) > "The second problem of git flow is the complexity introduced by the hotfix and release branches. These branches can be a good idea for some organizations but are overkill for the vast majority of them. " ну, не нравится - не используйте, никто не заставляет все потоки использовать, в простых проектах их вообще два может быть, почему бы и нет?..

https://docs.gitlab.com/ee/workflow/gitlab_flow.html вот еще такое есть

O!

они там как-то по-детски наехали на Git Flow

зато смотри как полезно, чатик и я узнали git flow, о gitlab flow, и о том, что они ещё и разные

Джез Хамбл, Дэвид Фарли. Непрерывное развёртывание ПО. В чате @devops_ru по ссылке можно найти.

А в этом просто в shared media лежит. Там очень много общей воды и конечно же очень много слов "команда"

А в этом просто в shared media лежит. Там очень много общей воды и конечно же очень много слов "команда"

Да, и совсем нет картинок. Что-бы ушла "вода" нужо прочитать несколько раз.

ERROR: S client not available

https://docs.gitlab.com/ee/workflow/gitlab_flow.html вот еще такое есть

кстати, если уже понимать что гуглить, то гуглится https://habrahabr.ru/company/softmart/blog/316686/

Чтобы разруливать авралы и чтобы на одном языке с программистами говорить

Ох блеать. Вот это бомбануло. Короче, я после 11+ лет программирования внезапно обнаружил себя в сумрачном лесу^W^W менеджером

Дак вот, дорогие друзья

чтобы стать хотя бы ПЛОХИМ менеджером, а не говном, мне пришлось перечитать дохуя литературы

понять ДОХУЯ неочевидных вещей

которые никакого отношения не имеют к программированию

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

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

Скрам и канбан это не новые слова для того, как вы раньше работали

я извиняюсь, но канбан появился, когда 99% этого чата ещё в планах не было

и это совсем неочевидная штука

не надо обманываться

скрам это какой-то жупел просто, сколько я вижу стенаний на тему "скрам плохо, митинги плохо"

а у нас всё заебись, прикиньте?

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

географ и толпа программистов

Кстати, хотел как раз когда все остынут сказать - а вы помните да, как мы к менеджменту пришли? Судя по всему, программист может придти к циклу разработки только став менеджером )

Не только, но в целом да

очень тяжело мозг сдвинуть

Но при должном старании можно постараться объяснить разработчикам эту невероятно сложную концепцию

и они, возможно, даже поймут

Ну т.е. без начальника надо пойти завернуться в саван и в морг? Вот беда-то

Ну т.е. без начальника надо пойти завернуться в саван и в морг? Вот беда-то

Вовсе нет

есть очень простой способ

рискуй своим баблом

у меня в команде вот на 30 января 2017 года нет ни одного начальника

Ну так в этом и был вопрос. Я вообще хотел только вот этих git* flow. А вы мне тут скрамов с кабанами развели

никто не говорит что нужно делать, от какого забора и до какого обеда

команда сама решает, обсуждает и делает

ей от заказчика приносят пачку пожеланий, они их прорабатывают, общаются с заказчиком и всё такое

а у меня в команде на 30 января 2017 года один я. и сам обсуждаю, решаю и делаю )))

Ну так в этом и был вопрос. Я вообще хотел только вот этих git* flow. А вы мне тут скрамов с кабанами развели

может тебе канбан хватает, а кому-то и гит флоу мало