Дело в том, что применение DevOps практик должно обеспечить как раз противоположный эффект и лучше вчера.
Это если у программистов уже имеется необходимый скиллсет — например, навык писать тестируемый код. Иначе пока они научатся и будет та самая просадка 20-30% производительности.
С pull request сложнее. Для меня основная причина их отсутствия — они не сделают процесс удобнее. Сейчас вы делаете изменения, копируете их и добавляете в интерфейс. Не нужно создавать специальных веток нигде.
Считаем на пальцах.
Сейчас, как понимаю, что-то типа такого:
1. Выводим дифф на экран (кстати, как это делается у вас?)
2. Копируем в буфер
3. Открываем броузер
4. Открываем страницу с «интерфейсом»
5. Вставляем дифф и жмакаем кнопку «Готово»
6. Если забыли что-то добавить, то или забиваем или повторяем всю операцию для хотфикса
С обычными гитовскими ветками процесс будет примерно в три команды: git branch my-new-feature
###.... правим код
git commit -a --verbose
git push
По-моему, написать три команды — более удобный процесс, чем жонглирование окнами броузера и буферами обмена, нет?
> Скорее нам надо будет потратиться на поддержание отдельного типа веток для патчей.
Можно вот это пояснить, пожалуйста? Ветки в гит – базовая фича, какая еще поддержка нужна?
> А в чем преимущества у использования git-format-patch перед отдельной формой на сайте?
Они вообще о разном.
Я видимо неверно прочитал «чтобы она позволяла любому разработчику присылать свои изменения в Git и раскладывать их на серверы».
Я посчитал, что у некоторых людей прямого доступа к репе нет (например, у находящихся на необитаемом острове) и им приходится отправлять свои патчи по е-мейл, эти две команды для того и сделаны.
Если же линк до сервера с репой есть, то конечно, для всех удобнее будет делать пуш в репу напрямую.
Почему не пользуетесь стандартным функционалом git (или аналогов)?
Create branch, commit, push, merge.
Даже если у вас разработчики на диалапе и имеют доступ только к е-мейлу, есть же git format-patch и git am.
Если кому-то блокировка мешает работать, дружно пишем жалобу _своим провайдерам_ на то, что не можешь получить доступ к таким то и таким то ресурсам сети, можно с приложением скриншотов о том, что ресурсы принадлежат тебе, а не телеграмму.
Про собственный опыт ответ все же не принимается :-)
Совещаниями, почтой, коммуникациями и т.п. я часов по 10 в день практически без перерыва вполне могу заниматься (правда, справедливости ради стоит сказать, что такой деятельностью заниматься целый день длительно не приходилось, максимум пару дней подряд, и таймером я ее не замерял).
А вот для технических задач, если заниматься ими целый день не вставая и не отвлекаясь получается 6ч максимум.
Потому и был вопрос о более-менее рядовых сотрудниках — сколько они времени показывают, и сколько тратят реально?
Есть ли у вас возможности карьерного роста? Или миграция только между подразделениями? Вышеупомянутый юнит-тестировщик может стать лидом, например, или архитектором (в своем направлении)? Или только докерщиком и младшим питонистом?
При восьмичасовом рабочем дне реальная производительность человека 4-5 часов, у меня больше 6 ни разу не удалось показать. Значит ли это, что у вас люди реально логируют часов по 5 в день, или же они колбасят в день часов по 10, чтобы получить те самые залогированные 8 часов?
Архитектура однослойная или многослойная? Иными словами, эти сервера с какими-то своими бакендами разговаривают (например, через очереди), или только с базой?
После полугода экспериментов с тестами я пришел к такому выводу:
юнитами тестируем подстановки/склейки переменных (в т.ч. в конфигах) и подобное
юнитами тестируем всякие хелперы
логику в рецептах лучше вообще не держать, но если все же есть, можно попробовать ее тоже юнитами протестировать
интеграционными тестируем относящееся к описываемому сервису — состояние системного сервиса, наличие процессов в памяти, доступность портов, наличие и выполнимость команды (для всяких cli-штук)
И пара общих, но очень важных штук:
Тестируем в изоляции. Если для теста кукбука X нужно настроить кукбук Y, это часто означает, что у вас ошибка компоновки.
И самое главное, пожалуй: тестируем не все, а только важное
Chef в виде бандла не сразу появился, а как ответ на постоянную боль с установкой гемов.
Какой у нас на хосте руби? Системный 1.8? Завернутый в магию RVM? Зашимленный в rbenv? Какой-нибудь странный самосбор в /usr/local? А на маке? А на винде?
С контролем этого хозяйства раньше были реальные проблемы. Сейчас просто притаскивает с собой все что нужно и работает. Лишние 200Мб на диске проблемой редко когда будут.
Terraform по-немногу подтягивается.
У нас VSphere с DRS и машинки создаем им прекрасно.
Но провайдер пока еще глючноватый — не подтягивает в стейт изменения со стороны VMWare, кое-какие вещи делает не совсем верно.
В целом пользоваться вполне можно, просто сперва попрактикуйтесь на тестовых средах.
Нас учили, что премию нужно давать, если люди делают больше, чем обычно, и не чаще пары раз в год.
В данном случае премию, похоже, они не заслужили, впрочем, как и первая команда (если, конечно, провал сроков и бюджета проекта для вас не является желаемой нормой).
Исключением будет, если проект быстрыми шагами начал идти к провалу (причем, не по их вине — это центральный момент), и они проявили чудеса героизма его спасая.
Бонус/подарок сотрудникам по результатам работы всей компании/проекта можно дать, но нужно дать понять, что это именно подарок, а не результат их заслуг, и не что-то, что будет происходить постоянно.
Если память не изменяет, в рассылках Rob и товарищи советовали не использовать RegexSplitter, т.к. он медленный.
А вместо него сделать сплиттер на LPEG.
Но они к производительности подходили очень серьезно — лишнюю инструкцию в цикле в фильтре не вставляли, чтобы скорость не падала.
Это если у программистов уже имеется необходимый скиллсет — например, навык писать тестируемый код. Иначе пока они научатся и будет та самая просадка 20-30% производительности.
Считаем на пальцах.
Сейчас, как понимаю, что-то типа такого:
1. Выводим дифф на экран (кстати, как это делается у вас?)
2. Копируем в буфер
3. Открываем броузер
4. Открываем страницу с «интерфейсом»
5. Вставляем дифф и жмакаем кнопку «Готово»
6. Если забыли что-то добавить, то или забиваем или повторяем всю операцию для хотфикса
С обычными гитовскими ветками процесс будет примерно в три команды:
git branch my-new-feature
###.... правим код
git commit -a --verbose
git push
По-моему, написать три команды — более удобный процесс, чем жонглирование окнами броузера и буферами обмена, нет?
Можно вот это пояснить, пожалуйста? Ветки в гит – базовая фича, какая еще поддержка нужна?
> А в чем преимущества у использования git-format-patch перед отдельной формой на сайте?
Они вообще о разном.
Я видимо неверно прочитал «чтобы она позволяла любому разработчику присылать свои изменения в Git и раскладывать их на серверы».
Я посчитал, что у некоторых людей прямого доступа к репе нет (например, у находящихся на необитаемом острове) и им приходится отправлять свои патчи по е-мейл, эти две команды для того и сделаны.
Если же линк до сервера с репой есть, то конечно, для всех удобнее будет делать пуш в репу напрямую.
Почему не пользуетесь стандартным функционалом git (или аналогов)?
Create branch, commit, push, merge.
Даже если у вас разработчики на диалапе и имеют доступ только к е-мейлу, есть же
git format-patchиgit am.Про собственный опыт ответ все же не принимается :-)
Совещаниями, почтой, коммуникациями и т.п. я часов по 10 в день практически без перерыва вполне могу заниматься (правда, справедливости ради стоит сказать, что такой деятельностью заниматься целый день длительно не приходилось, максимум пару дней подряд, и таймером я ее не замерял).
А вот для технических задач, если заниматься ими целый день не вставая и не отвлекаясь получается 6ч максимум.
Потому и был вопрос о более-менее рядовых сотрудниках — сколько они времени показывают, и сколько тратят реально?
Очень интересная статья и комментарии.
Неясны несколько моментов:
После полугода экспериментов с тестами я пришел к такому выводу:
И пара общих, но очень важных штук:
Какой у нас на хосте руби? Системный 1.8? Завернутый в магию RVM? Зашимленный в rbenv? Какой-нибудь странный самосбор в /usr/local? А на маке? А на винде?
С контролем этого хозяйства раньше были реальные проблемы. Сейчас просто притаскивает с собой все что нужно и работает. Лишние 200Мб на диске проблемой редко когда будут.
У нас VSphere с DRS и машинки создаем им прекрасно.
Но провайдер пока еще глючноватый — не подтягивает в стейт изменения со стороны VMWare, кое-какие вещи делает не совсем верно.
В целом пользоваться вполне можно, просто сперва попрактикуйтесь на тестовых средах.
Из старых — Savage. У нее была очень непростая 3d-составляющая и не очень динамичная RTS-составляющая.
Мне кажется, в таких играх важна сыгранность, поэтому они не так популярны.
Нас учили, что премию нужно давать, если люди делают больше, чем обычно, и не чаще пары раз в год.
В данном случае премию, похоже, они не заслужили, впрочем, как и первая команда (если, конечно, провал сроков и бюджета проекта для вас не является желаемой нормой).
Исключением будет, если проект быстрыми шагами начал идти к провалу (причем, не по их вине — это центральный момент), и они проявили чудеса героизма его спасая.
Бонус/подарок сотрудникам по результатам работы всей компании/проекта можно дать, но нужно дать понять, что это именно подарок, а не результат их заслуг, и не что-то, что будет происходить постоянно.
С человеком все ясно: конфликтный, смотрим следующего.
А вместо него сделать сплиттер на LPEG.
Но они к производительности подходили очень серьезно — лишнюю инструкцию в цикле в фильтре не вставляли, чтобы скорость не падала.
И еще, возможно вам, или еще кому-то пригодится: https://github.com/timurb/heka_mock
Это мокер, чтобы можно было тесты к фильтрам писать.