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

Я начинающий программист. В последнее время я заметил некоторые проблемы, которые, как мне кажется, можно было бы решить с помощью сервера непрерывной интеграции (CI). Я планирую в ближайшем будущем пойти к своему менеджеру и сказать что-то вроде: «У нас были эти проблемы, вот как это повлияло на нас, с Дженкинсом нам больше никогда не придется иметь дело с чем-то подобным. Могу ли я получить сервер Дженкинса? чтобы я мог настроить CI для этих проектов?»

Я боюсь, что в следующий раз, когда у кого-то возникнет проблема, связанная с CI, ответом будет: «JETM создал для нас хорошую систему; поговорите с ним». А через пять лет я превратился в DevOps-парня.

Я ненавижу делать работу, связанную с DevOps. Я рад поступить правильно и настроить инфраструктуру для более бесперебойной работы проектов моей команды, но я не желаю в этом отношении значительно большей ответственности, чем я планирую взять на себя добровольно.

Как я могу подойти к предложению улучшения, ясно дав понять, что я решительно не хочу быть «парнем Дженкинса»?

(Примечание для нетехнических читателей: CI — это непрерывная интеграция. Jenkins — распространенный инструмент для выполнения CI.)

Может быть, есть члены команды, которые тоже хотели бы настроить Jenkins, которым просто нужна поддержка и которые не боятся превратиться в devops-парня?
В вашей команде уже есть специалист по DevOps? Проблема серьезнее, чем вы думаете, — не только CI, но и другие вещи DevOps терпят неудачу? Может быть, ваше предложение должно быть больше похоже на «нам нужно, чтобы такие обязанности были возложены на кого-то», а не просто на решение этой проблемы?
@dwizum В настоящее время у нас нет никого, кто занимается разработкой.

Ответы (3)

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

Вы программист. Это означает, что есть много побочных действий, которые естественным образом добавляются к работе. Люди захотят, чтобы вы выполняли работу по CI, тестированию, работе с документами и работе с базами данных. Они могут закончить тем, что попытаются подтолкнуть вас к управлению проектами, компьютерной безопасности и/или написанию предложений. Чем больше из этого вы готовы сделать, и чем больше вы готовы сделать их, тем более ценным вы как сотрудник. Для каждого из них вы захотите установить ползунок в уме.

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

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

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

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

В общем, если вы не отличный программист, вам не захочется во всем следовать №4. Некоторая степень гибкости и готовность приспосабливаться действительно помогают убедить руководство в том, что вы командный игрок. Похоже, что в вашем конкретном случае вы хотите выбрать № 3, что круто, но факт в том, что это небезопасно. Это зависит от того, действительно ли ваше руководство заботится о ваших предпочтениях и/или от вашей способности время от времени говорить им «нет».

Итак... предполагая, что ваш менеджмент достаточно вменяемый/полезный, вам просто нужно представить это прямо. CI — это то, что вам не нравится, но вы можете сказать, что в этом конкретном случае вы могли бы сэкономить много времени и энергии, потраченных впустую на настройку этой штуки. Вы готовы приложить усилия по настройке (даже если вам это не нравится) и усилия (надеюсь, минимальные) по обслуживанию (это необходимо) на благо компании, но вы были наняты в качестве программиста, и это для вас важно, чтобы вы оставались программистом. Тогда будьте готовы. Через шесть месяцев, когда они попытаются навязать вам больше работы по КИ, чем вы согласны (как бы много это ни было), вы должны дать отпор и сказать им, что вы недовольны степенью, в которой это происходит. взял на себя твою работу. Признайте, что если ситуация управления достаточно токсична, вам, возможно, придется уйти.

Это действительно все, что вы можете сделать... в любом из этих случаев.

Мне нравится этот ответ. По моему опыту, Jenkins дает умеренный прирост эффективности каждый день, но в неподходящее время он также может стать очень требовательным. Мне может не понравиться, если коллега подтолкнул Дженкинса к команде, но затем захотел исчезнуть, когда какая-то неприятная проблема с разрешениями или несоответствие версии TLS или что-то еще подняло свою уродливую голову. И раньше я задавался вопросом, действительно ли Jenkins делает достаточно дополнительных действий (например, по сравнению с простыми сценариями сборки), чтобы оправдать его заботу и кормление. Вероятно, это происходит в некоторых магазинах/ситуациях, но не в других. Я, например, не стал бы евангелизировать за это.

Я боюсь, что в следующий раз, когда у кого-то возникнет проблема, связанная с CI, ответом будет: «JETM создал для нас хорошую систему; поговорите с ним».

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

Однако, если говорить как о парне, который настраивал сервер CI раньше и делает это время от времени, вряд ли это работа на полный рабочий день. Несколько недель раз в несколько лет.

Если на самом деле есть опасность превратиться в полноценную работу, то запомните фразу: «Это базовый навык, которым должна обладать ваша команда. У меня есть дневная работа. Я был бы счастлив научить вас ловить рыбу, но я не У меня нет времени, чтобы ловить рыбу за вас».

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

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

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

Если вы хотите действовать на опережение, предложите пробный период с «передачей» в случае успеха. Передача состоит из по крайней мере одного, а лучше двух человек, знакомящихся с системой до такой степени, что вы чувствуете себя комфортно, превращая их в администраторов, и архивируя все сделанные ими записи где-то, где их можно будет найти позже, если компании когда-либо понадобится привлечь больше людей. до скорости.