Developer tools

GitOps очередной модный термин или прорыв в автоматизации?

06.10.2020 12:23:44 |

Автор: admin

Большинство из нас, подмечая очередной новый термин в IT блогосфере или конференции, рано или поздно задается подобным вопросом: Что это? Очередное модное слово, buzzword или действительно что-то стоящее пристального внимания, изучения и обещающее новые горизонты? Точно также вышло у меня и с термином GitOps некоторое время назад. Вооружившись множеством уже существующих статей, а также знанием коллег из компании GitLab, я попытался разобраться, что же это за зверь, и как его применение может выглядеть на практике.

Кстати, о новизне термина GitOps также говорит недавно проведенный нами опрос: более половины опрошенных еще не начинали работы с его принципами.

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

Облачные сервисы очень успешно выполняли эти требования и именно они дали значительный толчок развитию подхода IaC. Оно и понятно. Ведь именно они дали возможность конфигурировать полностью виртуальный центр обработки данных: нет физических серверов, стоек, сетевых компонентом, всю инфраструктуру можно описать при помощи скриптов и конфигурационных файлов.

Так в чем собственно отличие GitOps от IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:

*GitOps*	*IaC*
Весь код хранится в git репозитории	Версионность кода необязательна
Декларативное описание кода / Идемпотентность	Допустимо как декларативное, так и императивное описание
Изменения вступают в силу с использованием механизмов Merge Request / Pull Request	Согласование, утверждение и коллаборация необязательны
Процесс выката обновлений автоматизирован	Процесс выката обновлений не нормирован (автоматический, ручной, копирование файлов, с использованием командной строки и т.д.)

Иными словами GitOps появился на свет именно благодаря применению принципов IaC. Во-первых, инфраструктуру и конфигурации теперь можно было хранить точно так же как и приложения. Код легко хранить, им легко делиться, сравнивать, пользоваться возможностями версионности. Версии, ветки, история. И все это в общедоступном для всей команды месте. Поэтому вполне закономерным развитием стало использования систем контроля версий. В частности, git, как наиболее популярного.

С другой стороны, появилась возможность автоматизировать процессы управления инфраструктурой. Теперь это можно сделать быстрее, надежнее и дешевле. Тем более принципы CI / CD уже были известны и популярны среди разработчиков программного обеспечения. Необходимо было только перенести и применить уже известные знания и навыки в новую область. Эти практики однако выходили за рамки стандартного определения Инфраструктуры как кода, отсюда и родилось понятие GitOps.

Любопытность GitOps, конечно, еще и в том, что это не продукт, плагин или платформа, связанная с каким бы то ни было вендором. Это скорее парадигма и набор принципов, аналогично с другим знакомым нам термином: DevOps.

В компании GitLab мы выработали два определения этого нового термина: теоретический и практически. Начнем с теоретического:

GitOps - это методология, которая использует передовые принципы DevOps, используемые для разработки приложений, такие как контроль версий, взаимодействие, согласование, CI/CD, и применяет их для решения задач по автоматизации управления инфраструктурой.

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

С практической же точки зрения мы описываем GitOps следующим образом:

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

Merge Request (альтернативное название Pull Request). В плане процесса MR - это запрос на применение изменений кода и последующее слияние веток. Но в плане инструментов, которыми мы пользуемся - это скорее возможность для получения полной картины всех вносимых изменений: не только code diff, собранный из какого-то количества коммитов, но и контекст, результаты тестов, конечный ожидаемый результат. Если мы говорим про инфраструктурный код, то нам интересно, как именно изменится инфраструктура, сколько новых ресурсов будет добавлено или удалено, изменено. Желательно в каком-то более удобном и легко читаемом формате. В случае с облачными провайдерами неплохо было бы знать, какие финансовые последствия понесет это изменение.

Но MR - это еще и средство совместной работы, взаимодействия, общения. То место, где вступает в действие система сдержек и противовесов. От простых комментариев до формальных одобрений и утверждений.

Ну и последняя составляющая: CI/CD, как мы уже знаем, дает возможность автоматизировать процесс внесения инфраструктурных изменений, тестирования (от простой проверки синтаксиса до более сложного статического анализа кода). А также и в последующем обнаружения дрейфа: отличий реального и желаемого состояния системы. Например, в результате несанкционированных ручных изменений или же отказа систем.

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

А если вам вдруг станет интересно, как это все выглядит на практике, то приглашаю посмотреть наш мастер-класс, в котором я пошагово рассказываю, как при помощи GitLab:

Реализовать основные принципы GitOps
Создавать и вносить изменения в облачную инфраструктуру (на примере Yandex Cloud)
Автоматизировать обнаружение дрейфа системы от желаемого состояния при помощи активного мониторинга

http://personeltest.ru/aways/bit.ly/34tRpwZ

https://bit.ly/34tRpwZ

Подробнее..

Категории: It-инфраструктура , Development , Open source , Git , Gitlab , Devops , Gitlab-ci , Iac , Automation , Developer tools , Gitops , Блог компании gitlab , Gitlabci

Советы по эффективной локализации продукта

16.07.2020 12:18:27 |

Автор: admin

Локализация это воплощение принципа удобства для пользователя: примерно 75% людей в мире чувствуют себя более свободно и уверенно при использовании продуктов на родном языке, а не на английском.

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

Сложности локализации на стыке с разработкой

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

Это не единственная неприятность: может получиться и так, что в новых географических регионах запуск придется откладывать. Часто менеджеры с опозданием узнают, что переведено не всё или разработанный продукт не полностью адаптирован к местным стандартам. И чтобы успеть, приходится спешить а спешка снижает качество.

Правильный подход с самого начала

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

Переводческие компании часто могут посоветовать процессы и удобные инструменты управления переводами для конкретной задачи. К примеру, мы в Alconost, часто разрабатываем собственные коннекторы для интеграции систем управления контентом, что позволяет добиться высокой степени автоматизации.

Этапы локализации продукта и рекомендации

В стратегии по локализации важны налаженные процессы и конкретные инструкции: они обеспечивают эффективную локализацию в рамках разработки цифровых продуктов.

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

Этап 1. Проверка исходных текстов

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

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

Этап 2. Тестирование локализации (псевдо-локализация)

Следующий этап это обычно запуск пилотного языка (не английского) для того, чтобы проверить, готова ли стабильная версия продукта к локализации. Протестировав возможность локализации на одном языке, можно определить проблемные области разработки и дизайна элементов интерфейса.

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

Этап 3. Работа со сторонней компанией по локализации

На этом этапе рекомендуется остановить изменения в пользовательском интерфейсе, заблокировать контент и перенести обновления на будущий спринт. Переводческой компании нужно передать все необходимые материалы и сведения, в том числе об используемых для перевода инструментах и программном обеспечении (облачных платформах, CRM, CMS и других инструментах для перевода). Для автоматизации и оптимизации качества переводов часто используются платформы управления переводами (например, Crowdin), в которых работают все стороны, в том числе агентства по локализации.

Мы советуем дать доступ локализаторам к рабочей версии продукта, чтобы можно было понять контекст. Необходимо также предоставить инструкции по локализации, руководства по стилю и глоссарии.

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

Этап 4. Оценка качества перевода

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

Этап 5. Исправление интерфейса и перевод остальных текстов

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

Проблемы и решения в непрерывной локализации

На следующем этапе стратегии по локализации необходимо наладить эффективный процесс непрерывной локализации, чтобы обеспечить своевременное обновление в приложении текстов, кода, изменений в продукте и добавление новых сообщений.

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

Небольшие по объему регулярные переводы частое лучше делать с помощью профессионального программного обеспечения (не прибегая к машинному переводу). К примеру, с помощью нашего сервиса для перевода текстов Nitro можно получить профессиональный перевод в течение нескольких часов.

Интеграция программного обеспечения для управления переводами

Ключевое, удобное для компаний решение это использование программного обеспечения для переводов, с которым работают специалисты по локализации. Такой софт, как правило, интегрируется с веб-сайтами и платформами компании посредством API или CLI.

А ещё на таких платформах менеджеры по продукту, специалисты по локализации и переводчики получают уведомления, когда необходимо перевести новую строку (слово, фразу, абзац). И затем либо сразу приступают к переводу (если есть такая договоренность), либо ждут, когда будет назначено задание.

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

Оценка качества

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

Лингвистическое тестирование это когда специалист по локализации тестирует сборку на соответствующей локальной версии ОС. При этом делаются снимки экрана с проблемами (непереведенный текст, не влезающие в экран строки, неправильные кодировка, направление текста или контекст) и с помощью разработчиков вносятся изменения в ресурсные файлы.

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

Нужна помощь с локализацией / переводом? Мы в Alconost всегда рады помочь!

О нас

Alconost профессионально занимается локализацией игр, приложений и сайтов на более 70 языков. Лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджмент проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем видеоролики.
Подробнее