Да, а что? Я пользовался и тем, и тем и считаю, что геррит куда удобнее, нежели гитхаб.
Геррит гибче в настройке workflow, геррит гибче и удобнее в ревью кода — например, такая маленькая фича, как возможность выделить кусок кода и оставить комментарий к нему, очень удобна. Я уж не говорю про все остальное.
У вас негативный опыт его использования? Расскажите, пожалуйста.
Так же интересно было бы узнать про то, как у вас реализуются пункты 5-9. Автоматизированы ли они? Что используете?
Немного вот об этом:
Ревьюшница — разработанная в Яндексе система, которая призывает в PR двух рандомных людей с экспертизой в изменяемом коде и с учетом отпусков и отсутствий.
Смотрели ли вы сторону open-source решений, таких как Gerrit, например? То же Openstack-сообщество на его основе построило довольно удобное и функциональное воркфлоу. Конечно, одним герритом там не обошлось, рядом есть еще парочка других инструментов (Zuul и Jenkins, например).
Огромный плюс геррита в том, что у него имеется довольно простой API, вокруг которого можно построить довольно удобные CI/CD процессы. Кроме того, геррит позволяет гибко настроить workflow, благодаря использованию дополнительных плагинов и лейблов/оценок.
Kubespray, насколько мне известно, не в активной стадии разработки и разработчики не гарантируют поддержку свежих фич Kubernetes'а в коде. Так что я тут согласен, что использование Kubeadm или установка компонентов один за другим больше подходят.
После того как мастер инициализируется, kubeadm выведет на экран служебную информацию. В ней будет указан token и хэш для инициализации других членов кластера. Обязательно сохраните строчку вида: kubeadm join --token XXXXXXXXXXXX 172.26.133.21:6443 --discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXXXXXXX, где нибудь отдельно, так как данная информация выводится один раз; если токены будут утеряны, их придется генерировать заново.
Совсем не обязательно это делать. :) Всегда можно воспользоваться командой на любом из мастеров (если мне не изменяет память):
kubeadm token create --print-join-command.
Сам каждый раз сохранял ее, а потом покопался в доках немного и был счастлив. :)
Имею опыт работы в разных компаниях с разным подходом к организации рабочего времени. И, честно говоря, пока лидируют те, в которых, условно говоря, 100500 менеджеров не пытаются повесить сопоставимое количество метрик на своих подчиненных. Во многом, это зависит от процессов и правильно набранных в команды людей — если у них есть интерес к тому, что они делают, то и никакие трекеры не нужны. Как правило, поставленные задачи выполняются в срок и не на «отстаньте».
Теперь для меня наличие такого рода систем или скурпулезного контроля время другими способами является, своего рода, лакмусовой бумажкой для конторы.
Да, в случае с 1-2 серверами этот подход окей. Но когда их уже становится даже больше 10, то идти на них и ставить python2.7 становится утомительно. :)
И первый сюрприз: в коробке Ubuntu 16.04 нет python по умолчанию!
Если речь идет именно об Ubuntu 16.04, то там там уже python3 по умолчанию. В самом ansible это можно поправить, например, указав у нужного хоста переменную вот таким образом:
Присоединяюсь к автору комментария — пунктуация ломает глаза. Статья, быть может, и хорошая, но удовольствие от чтения снижается, когда какое-либо предложение приходится перечитывать, чтобы верно вникнуть в ее смысл.
Геррит гибче в настройке workflow, геррит гибче и удобнее в ревью кода — например, такая маленькая фича, как возможность выделить кусок кода и оставить комментарий к нему, очень удобна. Я уж не говорю про все остальное.
У вас негативный опыт его использования? Расскажите, пожалуйста.
Так же интересно было бы узнать про то, как у вас реализуются пункты 5-9. Автоматизированы ли они? Что используете?
Немного вот об этом:
Смотрели ли вы сторону open-source решений, таких как Gerrit, например? То же Openstack-сообщество на его основе построило довольно удобное и функциональное воркфлоу. Конечно, одним герритом там не обошлось, рядом есть еще парочка других инструментов (Zuul и Jenkins, например).
Огромный плюс геррита в том, что у него имеется довольно простой API, вокруг которого можно построить довольно удобные CI/CD процессы. Кроме того, геррит позволяет гибко настроить workflow, благодаря использованию дополнительных плагинов и лейблов/оценок.
Как варинт, еще вот проект: blog.getpelican.com.
Совсем не обязательно это делать. :) Всегда можно воспользоваться командой на любом из мастеров (если мне не изменяет память):
kubeadm token create --print-join-command.
Сам каждый раз сохранял ее, а потом покопался в доках немного и был счастлив. :)
Теперь для меня наличие такого рода систем или скурпулезного контроля время другими способами является, своего рода, лакмусовой бумажкой для конторы.
Если речь идет именно об Ubuntu 16.04, то там там уже python3 по умолчанию. В самом ansible это можно поправить, например, указав у нужного хоста переменную вот таким образом:
Сколько использую, пока не встретил проблем с этим.
Как дополнение: активность той или иной компании в сообществе можно посмотреть тут: http://stackalytics.com/.
И как всегда новый велосипед на подходе, хотя один готовый уже есть: ГУЦ.