Олександр Щедров та Альбіна Тюпа — Magic button. Can production releases be smooth and your clients happy?
•Download as PPTX, PDF•
0 likes•314 views
Magic button. Can production releases be smooth and your clients happy?
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to Олександр Щедров та Альбіна Тюпа — Magic button. Can production releases be smooth and your clients happy?
Similar to Олександр Щедров та Альбіна Тюпа — Magic button. Can production releases be smooth and your clients happy? (20)
More from LEDC 2016
More from LEDC 2016 (17)
Recently uploaded
Recently uploaded (20)
Олександр Щедров та Альбіна Тюпа — Magic button. Can production releases be smooth and your clients happy?
- 1. Happy Ever Afters With CI Workflow
- 2. hello! I am Albina Tiupa I am a PM at FFW You can find me at: https://www.facebook.com/albina.tiupa
- 3. hello! I am Alex Schedrov I am a Team Lead at FFW. You can find me at: http://www.facebook.com/schedrov @sanchiz
- 4. 420+ people 11 countries 15 years Formerly Blink Reaction, Propeople, Bysted, Chainbizz & Geekpolis
- 6. Long-long time ago we realized that using CI workflow in our projects is 90% of success
- 7. Do you know why?
- 8. We want all releases to go to production seamlessly and on time 1.
- 9. We want releases to be of a high quality with minimum post production bugs 2.
- 10. We want easily maintain multiple independent environments 3.
- 11. We want development team to be in sync with each other 4.
- 12. We want releasing to become an automated routine or a one- click action 5.
- 13. We want to be sure that everything is under control! 6.
- 15. Don’t you dream about it all for your projects??
- 16. WE NEED TO CHANGE OUR PROCESS, IT’S SH*T!
- 17. When this book is your team’s guidance
- 18. When your team doesn't understand what’s going on.
- 19. When your team have no code review
- 20. When you have lack of QA
- 21. When your team members do not follow processes you agreed about
- 22. When deployments depend on one person and manual workarounds
- 23. So, don’t you want to get rid of that finally?
- 24. Caution! Addictive content goes next!
- 25. What does CI workflow mean from technical perspective
- 26. 1.Environments ● Development/QA environment resemble the production environment ● Isolated features on every build
- 27. 2. Specifications ● Functional specs for client ● Technical specs for dev team ● Functional/Technical specs developed in advance ● Protect your team
- 28. 3. Knowledge exchange through code review ● Development techniques and approaches of problem solving ● Quality of the code ● Responsibility for reviewed code
- 30. 4. Code Driven Development ● Everything in code(configuration, DevOps scripts, updates and etc.) ● No manual steps during deployment ● Responsibility for own code
- 31. 5. QA ● QA is done before code is merged to ‘master’ ● Steps for review in each task ● Manual and automated tests
- 32. Even more, steps for review!!!
- 33. 6. Automate everything ● Anyone can deploy ● Deploy any time and more frequently ● Team members are forced to follow the process
- 35. PM Dashboard
- 36. Our lives have been divided into 2 parts: before CI workflow and after CI workflow And guess what?
- 37. WE LOVE OUR JOB!
- 38. Happy PM has better feeling of completed task or milestone
- 39. Happy PM is more collaborative during development cycle
- 40. Happy PM can respond quickly to problems and bugreports
- 41. Happy Client spends less time bumping into and reporting bugs
- 42. can expect deliverables on few versions simultaneously Happy Client
- 43. experiences a short cycle time between idea and usable software Happy Client
- 44. Happy PM works with a highly disciplined and productive team
- 45. We decided to share the setup we’re using: CIBox http://bit.ly/ffw-cibox
- 46. thanks! Any questions? You can find us at: https://www.facebook.com/albina.tiupa http://www.facebook.com/schedrov
Editor's Notes
- @Albina and @Alex: Добрый день! Мы очень рады видеть вас на нашем докладе. Сегодня мы хотели бы рассказать историю и поделиться опытом о том, как CI workflow изменил процессы внутри нашей команды и как это влияет на работу менеджеров и технической команды, а также делает наших клиентов довольными результатами и продуктами, которые мы разрабатываем. Мы попытаемся не учить вас “жить”. Мы просто поделимся позитивными результатами своих успешно примененных наработок. Возможно, вы захотите перенять что-то для себя :)
- @Albina: Меня зовут Альбина Тюпа. Я работаю проджект менеджером в компании FFW уже больше года. В зону моей ответственности входит обсуждение и уточнение требований клиентов, постановка и раздача тасков команде, распределение ресурсов команды между разными проектами, отслеживание прогресса разработки и сроков реализации проекта в целом, отчетность по проекту, а также передачей выполненной работы клиентам. Клиентами, с которыми моя команда работает в основном, являются non-profit organizations из США.
- @Alex: Меня зовут Щедров Александр. Я работаю в компании FFW и выполняю роль Тим Лида. Я учавствую в менеджменте проектов с технической стороны и несу ответствунность за качество нашей продукции. Таким образом я работаю как с командой разработчиком, так и с клиентами.
- @Albina: FFW is a digital agency that brings together specialized teams from five previous agencies: Propeople, Blink Reaction, Bysted, ChainBizz, and Geekpolis. We currently have six offices in the US, three offices in Denmark, three offices in Ukraine, and one office each in the UK, Sweden, Germany, Austria, Bulgaria, Moldova, and Vietnam.
- @Albina: уже больше года наша команда из 11 человек работает исключительно в удаленном режиме. 1 ПМ 1 QA 8 developers (3 with devops skills and 4 Andrey/ew/ii/iy s :) )
- @Albina: Когда начала формироваться наша команда, как полноценная единица производства в cоставе компании, мы задумались над тем, что в наших условиях важно четко наладить все процессы внутри команды. Мы остановились на практиках CI workflow и решили “подрихтовать” их под свои нужды. В последствии мы осознали , что для любой команды это тоже важно!
- @Albina: Сейчас хотелось бы посмотреть на выбранный технический подход к организации процессов с точки зрения ПМов и клиентов и объяснить почему это важно, простыми, доступными для нетехнических ПМов и даже клиентов, словами. Далее я хочу представить несколько аксиом, которым вам и вашим клиентам, скорее всего, хотелось бы следовать в процессе разработки продукта.
- @Albina: Software only becomes valuable when you ship it to customers! Релизы должны проходить легко и непринужденно, без зависаний в офисе до глубокой ночи. А еще релизы должны случаться достаточно часто. Потому что Shipping exposes mistakes
- @Albina: Продукт высокого качества - залог успеха. Счастье клиента может омрачить большое количество багов. Мы этого не хотим, правда же?
- @Albina: В наших идеальных мечтах нам хотелось бы чтобы и дев, и стейджинг и продакшн в особенности environments были стабильными и чтобы мы могли в любой момент проверить актуальное состояние нашего приложения или же изолированно зарелизить какую-то из фич на стейджинг для передачи клиенту на тестирование.
- @Albina Всем бы хотелось осознавать, что команда работает по установленным правилам и согласно налаженным процессам. Чтобы один был на подхвате у другого, и чтобы все были легко взаимозаменяемыми. А еще чтобы каждый осознавал свой взнос в конечный результат
- @Albina: Вопрос к ПМам - Случалось ли у вас такое, что вы в попытке зарелизить новую версию или продукт сидите над головой у девелопера или тимлида с вопросами “ну как там, долго еще?” “как без Пети мы не можем решить эту проблему????” “почему фича не работает на продакшене??” и “мы пойдем сегодня вообще домой?” Я осмелюсь предположить, что удовольствия от такого вы получали мало… Хочется забыть о таком НАВСЕГДА
- @Albina: Ну и конечно же, вам и вашему клиенту хочется ощущать, что все находится под четким контролем вашей команды. Это основы основ доверия и залог довольного клиента!
- @Albina: выглядеть это может примерно так :)
- @Albina: Неужели вы не хотели бы работать с пониманием, что у вас все под контролем? А для этого, вы не поверите, не надо выдумывать велосипед.
- @Alex: Я уверен что многие хотят поменять свой процесс разработки пректов и довольно часто мы себе говорим что пора что-то менять. Наш процесс не так уж и хорошо. Мы делаем это очень часто и пытаемся его улучшить. Если к сожалению вы не задаетесь такими вопросами, то есть парочка способов как распознать процесс которой стои ло бы поменять.
- @Alex: Когда эта книга являеться вашим руководством и любимой книгой. На украинском и русском языках название конечно звучит намного сильнее, “рас рас и в продакшен”. Другими словами если технический процесс разработки проекта вообще отсутствует и делаеться все как попало. Если в данный момент вы понимаете, что большинство ваших проектах делаются по такой схеме, то вам пора что-то менять или искать новую работу. Могу сказать по опыту, что желание работать по такой схеме пропадает уже через несколько месяцев.
- @Alex: Когда работая вы не понимаете что с ним вообще происходит и что вы делаете. Например вы не знаете его будущее, не известно проходят ли деплойменты, насколько долгосрочный он. Как тогда можно писать качественный код и разрабатывать качественный функционал? Так же это может относиться к отдельным фичам над которыми вы работаете. Это значит что команда находится в вакууме от всего менеджмента и существует огромная пропасть между технической командой и командой менеджеров. Это очень сильно влияет на мотивацию команды и на организованность.
- @Alex: Когда у вас нету код ревью, у вас нету ощущения что все делаеться правильно. Лично для меня, как для Тим Лида это очень важно. Когда вы видите код только после того как он уже лежит в основном репозитарии - это очень плохо! Код нужно просматривать еще до того как он туда попадет. Таким образом можно пинимизировать огромное кол-во тупейших багов, опечаток и других неприятных моментов.
- @Alex: Когда вы тестируете свой продукт только на продакшене или не тестируете его вообще, это очень плохо. Чем больше этапов тестировани - тем лучше. Путь это будет ручное тестирование, функциональное, unit тестирование, чем больше тестов - тем лучше. Но не стоит забывать, что тесты должны быть качественные. Если у вас до сих пор нету тестирование или оно очень слабое, задумайтесь о том, возможно стоит немного поменять ваш процесс.
- @Alex: В каждой команде есть свои определенные правила и процессы. Когда кто-то их не выполняет или выполняет не качественно, вероятность успеха такого проекта не очень велика. В таких случаях есть 2 варианта развития событий: С технической стороны создать такой воркфлоу, в котором будет невозможно не следовать правилам. Уволить/Побить вашего коллегу )))) Так дедать конечно же ненужно, это шутка))
- @Alex: Одна из самых важных причин, из которой стоит что-то менят - когда вся ваша инфраструктура привязана к одному человеку. Человек ответственный за все. Он не может болеть, он не может брать отпуск, т.к. без него рабочий процесс остановиться на каком либо этапе.
- @Alex: В связи с этим возникает вопрос, как много из того что я перечислил возникает у вас в команде? Задумались ли вы, о том что бы избавиться от этого и начать счастливую жизнь и начать радоваться выполняя свою работе? Если в зале возник хотя бы один положительный ответ, то давайте продолжим.
- @Alex: Прошу обратить внимание, содержание следующего подхода вызывает привыкание. Если вы начнете использовать Continuous Integration workflow, остановиться будет сложно)
- @Alex: Как же выглядит Continuous Integration workflow со стороны технического менеджера либо Тим Лида?
- @Alex: Очень важно иметь среду для тестирования или разработки. При этом желательная что бы она польностью реплицировала конфигурацию с вашего продакшен сервера. Это дает возможность избежать ситуаций, когда определенный проблемы появляются только на продакшене и соответствено исправить их можно только на продакшене. Следующий момент, технической команде и для менеджерам очень удобно иметь изолированные билды. Что это значит? Это значит что каждую часть функционала можно протестировать независимо от текущего состояния проекта. Фактически это состояние продакшена плюс изменения разработчика. Это дает огромный плюс и уверенность того, что все будет работать так как ожидается.
- @Alex: Спецификации. Многие из называют техническим заданием. Лично для меня это очень важная часть планирования и реализации. В моем понимании спецификация это документ, которые описывает определенную часть функционала. Функциональные спецификации описывают - как оно должно работать со стороны конечного пользователя, чаще всего они согласуются с клиентомю Следующий этап - технические спецификации. В этой спецификации описывается как оно должно быть реализовано с технической стороны. Такие спецификации пишуться для внутреннего использования внутри команды. Наша команда всегда старается делать спецификации заранее, Функциональные спецификации - защищают нашу команду от запросов клиента, технические - моделируют архитектуру продукта и дают техническое представление о реализации для разработчиков.
- @Alex: В первую очередь хочется сказать, что код ревью это не о том как правильно писать код, как следовать стандартам, как писать аннотации. Код ревью это шаринг своих знаний и опыта. Это обмен опытом между junior и senior разработчиками. Когда вы пишите код, вы ощущаете что вас ждет ревью, Что завтавляет вас 10 раз подумать, прежде чем писать код. Код ревью очень важная часть процесса которая влияет на качество продукции. По моим ощущениям, качество продукции прямо пропорционально качеству код ревью. При этом очень сложно убедить команду что код ревью важная часть процесса! После ревью ответственность делиться на 2-х человек, на разработчика который писал этот код и на того кто делал ревью. Это очень хорошо, т.к. в данном случае уже 2 человека которые заинтересованы в качественном выполнении задачи.
- @Alex: Так выглядит типичный процесс, когда мы просто советуем своим коллегам использовать что-то более лучшее. Никто не навязывает свое мнение, всегда можно обсудить любые вопросы. Таким образом, свотря на код вы можете узнать разные подходы в реализации тех или других типичных задач. Например вы делали ревью кода где кто-то реализовал Ctools popup. В через 3 месяца вам нужно его реализовать, но вы уже приблизительно знаете как это сделать и где это посмотреть.
- @Alex: Для того что бы достич хороших результатов нужно использовать Code Driven Development. Это значит что все должно храниться в коду, будь то сонфигурации, скрипты, апдейты и т.д. Так же не должно быть никаких ручных шагод для деплоймента, только через код. Таким образом разработчик будет чувствовать ответственность за свой код и легко будет обнаружить кто не сделал свою работу либо сделал ее неправильно, в результате неудачных апдейтов продакшена.
- @Alex: Тестирование. Очень важный момент со стороны технической организации процесса. Все должно быть протестировано перед тем как попадет в масте. Таким образом мы избегаем багов, которые отсеиваются на первом этапе ревью. Каждая задача должна иметь steps for review, которые описывают как проверить задачу. Это дает возможность проверить работу разратчика на этапе ревью, на стейдже, на продакшене. В нашей команде мы стараемся использовать мануальное тестирование и автоматическое. Это дает возможность отловить как можно больше багов, до того как код попадет на продакшен.
- @Alex: Даже больше, что бы с нашими клиентами не происходило таких неприятностей при тестировании их продукта, steps for review из задач, трансформируются в steps for review для клиентов.
- @Alex: Последняя вещ, которая собственно и определяет наш тип workflow, это автоматизация. Все должно быть автоматизировани, никаких ручных шагов. Таким образом достигается 3 основные цели: Любой участник команды, может сделать деплой. Это менеджеры, тестировщики, junior разработчики. В общем - все. Мы можем деплоить в любое время и с любой периодичностью, за счет того что перед тем как изменения попадают в master ветку, они протестированы как минимум 1 раз и за счет того что все автоматизировано. Когда все автоматизировано, у участников команды просто нету другого выбора как следовать правилам. Это решает огромное кол-во проблем в менеджменте.
- @Alex: Так выглядит типичный процесс релиза и тестировки продукта. Разработчик создает Pull Request, при этом протестировав функционал локально. Создается билд и происходит тестирование билде, плюс код ревью. Код мерджиться в мастер и функционал тестируется на дев сервере, релиз на который происходит каждый день. Когда мы готовы к продакшен релизу, мы делаем релиз на стейдж и тестируем релиз там. Когда все готово, делаем релиз на прод и клиент тестирует все там. На каждой стадии мы имеем промежуточное тестирование.
- @Alex: Ну и панель управление релизами для наших Project Manager’ov. Им достаточно войти в Jenkins и нажать кнопочку. После чего запустится релиз на определенный environment.
- @Albina: Признаюсь честно, не сразу все стало лучше :) Мы много работали над тем, чтобы усовершенствовать наши процессы под нужды лично нашей команды, но когда мы пришли в некотором роде к идеально настроенному процесу, наша жизнь разделилась на до и после CI workflow. И знаете что?
- @Albina: никаких стресов никакой работы на выходных никаких постпродакшн цейтнотов Остановлюсь более подробно на некоторых ощутимых результатах сотрудничества с командой и клиентами в условиях активного применения практик CI workflow
- @Albina: Во-первых, у меня, как у ПМа есть полное понимание текущего статуса проекта и осознание осязаемого результата работы команды. Я могу делать релиз на стейдж ежедневно и отмечать для себя что можно улучшить, а что надо обсудить с клиентом на предстоящем митинге.
- @Albina: возможность делать демо для клиента чаще и атомарно (позадачно) очень важный фактор формирования доверия к команде. Ведь не всегда даже самые точные спецификации трактуются 2-мя человеками одинаково. Показав результат в действии можно осознать недоработки или “тонкие” места и вовремя сформулировать необходимые change requests
- @Albina: Представим себе ситуацию, что все-таки один коварный баг таки проскочил на продакшн с релизом. С CI workflow фикс можно зарелизить атомарно и очень быстро. Главное не забыть сделать backport опосля :)
- @Albina: Много было сказано про качество доставляемого клиенту продукта и про важность интеграции QA в процессы (как автоматическое, так и ручное тестирование). И на деле мы получаем очень и очень мало баг репортов, продолжительность UAT периода сокращается еще и за счет итерационного процеса передачи результатов работы клиенту (частые релизы)
- @Albina: Примером таких ситуаций может быть юс кейс, когда во время работы с большой non-profit organization мы получаем задачи от разных отделов орг-ции и должны, согласовывая действия с остальными частями разработки, иметь возможность продемонстрировать результаты работы или же зарелизить их на продакшн. Все это возможно с CI workflow. Доказано :)
- @Albina: Бывают ситуации, когда время на реализацию какой-то фичи очень ограничено. Нам нужно зарелизиться вовремя, чтобы успеть донести до конечного пользователя какой-то функционал, привязанный к ограниченым временным рамкам. С CI workflow мы можем очень быстро доставить результат клиенту. Лишь бы были свободные руки ;) а процесс уже под это “заточен”
- @Albina: Я ложусь спать и просыпаюсь утром с поной уверенностью в том, что моя команда работает слаженно, как единый механизм, и что никто не тратит свое драгоценнейшее время на процесы, которыми не стоит заниматься. Продуктивность каждой единицы команды в разы выше! И это перекликается с тем, что уже упоминал ранее Саша с технической точки зрения. А я, как ПМ это чувствую наглядно и на данный момент мы уложились в дедлайны по всем проектам, над которыми работали. Конечно, может не всем так повезло с составом команды, как мне … Но это уже совсем другая история ;)
- @Alex: В результате нашей работы над процессом, появился продукт который называется CIBox который мы с удовольствием решили расшарить и сделать open source продуктом. Доступен он на GitHub по следующей ссылке.
- @Alex and @Albina: АПЛОДИСМЕНТЫ НАМ!!! WHOAHAHAHA!!! БЫСТЕНЬКО!!! ПОШЕВЕЛИВАЕМСЯ!!!