Целью данной статьи было показать, что DevOps — это, прежде всего, про философию и понимание сути и состава этой методологии, а не про инструменты. Вначале я как раз и говорю о том, что многие (и зачастую это далеко не новички в данной сфере) воспринимают DevOps именно как использование специального ПО для построения CI/CD. Затем я поясняю, почему такой подход не правильный и к чему приводит практическое применение DevOps в такой трактовке. А так как мы в своей практике встречаемся с последствиями этих проблем довольно часто, то и возникла мысль написать статью, которая показывала бы первичность теоретической составляющей, что позволило бы заложить прочную базу для дальнейшего развития DevOps в проекте в правильном направлении.
Практической же стороне вопроса внимания удаляется лишь в виде отсылки к абстрактному набору инструментов, который может быть выбран любым и будет сильно зависеть от особенностей конкретного проекта. Я подумаю над возможностью написания второй части статьи, которая бы освещала эти моменты. Но и та статья не будет описывать какой-то конкретный стек ПО (мануалов и холиваров на эту тему и и-нете достаточно) и будет касаться лишь вопросов выбора того или иного инструментария в зависимости от различных факторов.
На текущий момент такой функционал nxs-build-tools из коробки не предоставляет. Но т.к. в основе сборки пакетов лежит CMake, то принципиально можно доработать cmake-файлы таким образом, чтобы сборка нескольких пакетов в рамках одного проекта стала возможной.
У нас в компании все проекты, в которых применяется данный инструмент, разделены таким образом, чтобы получался один результирующий пакет на проект. Когда-то у нас был один проект, из которого на выходе было три пакета, но потом мы от этой практики отказались, прежде всего, из-за неудобства разработки (но это чисто для нас). И т.к. мы не используем такую практику (да и в принципе я лично видел не так много подобных современных проектов, возможно, конечно, просто не обращал внимание), то и в базовый вариант «многопакетность» не закладывалась. Но nxs-build-tools и был выложен в open source, чтобы он имел возможность развиваться и быть максимально удобным и полезным как можно большему числу людей. Поэтому все вопросы, замечания и идеи помогут его улучить )
Скажите, пожалуйста, Вы могли бы привести какие-то юзкейсы, где бы такая функциональность была бы полезна?
И вновь огромное спасибо, поправил!
Проверил и поправил остальные прототипы и примеры, где были неточности. Теперь с этим проблем быть быть не должно ))
Проблема заключалась в том, что при конфигурировании бота в значение опции telegram.bot_api_addr был добавлен лишний завершающий символ '/' (т.е. было указано: https://api.telegram.org/). Бот это не проверял и при конкатенации строк добавлял ещё один слэш, что не позволяло зарегистрировать Webhook в Telegram.
Сейчас недочёт устранён, в репозиторий выложены пакеты с новой версией бота.
Если бы мы начинали с чистого листа, то скорее всего выбрали бы именно Go (тут я с Вами согласен), но т.к. у нас уже были какие-то наработки и готовые инструменты, то решили остановиться именно на использовании Си.
Скажите, пожалуйста, а почему именно Вас отталкивает реализация на Си?
Спасибо за интересное решение. У нас в планах тоже есть интеграция с Telegram, но чтобы встроить его в Redmine как мессенджер, чтобы пользователи могли общаться между собой.
Скажите, а где (например, в какой-то задаче) в Redmine Вы предполагаете сохранять лог общения пользователей в Telegram?
У меня вопрос, почему вы не используете плагины для упрощения работы с задачами и жизненными циклами задач?
Исходя из специфики нашей работы нам, в принципе, достаточно стандартных средств самого Redmine и тех процессов, которые мы написали с использованием этого плагина. Но если Вы дадите ссылки на полезные плагины — буду благодарен! :)
У вас все движения задачи происходят через стандартное редактирование задачи с отображением всех полей?
Не совсем. Есть некоторые отклонения от стандартного движения задачи в соответствии с созданными нами процессами с помощью упомянутого плагина. Например, автоматическая смена статуса задачи с «Ожидание клиента» на «Ответ клиента» когда в тикет отвечает клиент.
А видимость полей тоже ограничена в зависимости от роли пользователя в проекте, чтобы клиентам не выводить лишнюю информацию, загромождающую экран.
Спасибо, мы рады, что наша идея оказалась полезной для сообщества!
но C, вы серьезно?
Да, вполне. При выборе языка для разработки бота мы исходили из следующего:
1. У нас уже был свой framework, на котором разработано большинство внутренних инструментов для компании и который показал себя с хорошей стороны при решении подобных задач.
2. У нас есть разработчики на Си, которые знают этот framework
Поэтому мы посчитали, что получить максимально качественный продукт в максимально короткие сроки мы можем только с помощью Си.
У меня встречный вопрос: почему для Вас важно на каком языке разработан бот? Ведь для него создан пакет и есть репозиторий из которого его можно поставить одной командой, т.е. не надо ни компилировать программу вручную, ни разбирасться с тем как её установить. Можно просто брать и начинать пользоваться. Если, конечно, Вы не хотите дорабатывать бота под себя :).
Когда мы в компании осознали потребность в подобном ПО, то, разумеется, внимательно изучили существующие решения (в том числе и то, которое Вы приводите). И т.к. ни одно из них не предоставляло нужный нам функционал — мы решили разработать собственного бота, который бы максимально вписывался в имеющиеся у нас бизнес-процессы и логику работу.
Я ни в коем случае не хочу сказать, что имеющиеся решения плохие, нет, просто они другие. Например, наш бот позволяет нашим клиентам общаться с тех. поддержкой вообще не используя Redmine, а администраторам общаться с клиентами не используя Telegram.
С чего начать DevOps?
С чего начать DevOps?
Целью данной статьи было показать, что DevOps — это, прежде всего, про философию и понимание сути и состава этой методологии, а не про инструменты. Вначале я как раз и говорю о том, что многие (и зачастую это далеко не новички в данной сфере) воспринимают DevOps именно как использование специального ПО для построения CI/CD. Затем я поясняю, почему такой подход не правильный и к чему приводит практическое применение DevOps в такой трактовке. А так как мы в своей практике встречаемся с последствиями этих проблем довольно часто, то и возникла мысль написать статью, которая показывала бы первичность теоретической составляющей, что позволило бы заложить прочную базу для дальнейшего развития DevOps в проекте в правильном направлении.
Практической же стороне вопроса внимания удаляется лишь в виде отсылки к абстрактному набору инструментов, который может быть выбран любым и будет сильно зависеть от особенностей конкретного проекта. Я подумаю над возможностью написания второй части статьи, которая бы освещала эти моменты. Но и та статья не будет описывать какой-то конкретный стек ПО (мануалов и холиваров на эту тему и и-нете достаточно) и будет касаться лишь вопросов выбора того или иного инструментария в зависимости от различных факторов.
Апдейт nxs-build-tools — помощника в сборке deb и rpm пакетов
На текущий момент такой функционал nxs-build-tools из коробки не предоставляет. Но т.к. в основе сборки пакетов лежит CMake, то принципиально можно доработать cmake-файлы таким образом, чтобы сборка нескольких пакетов в рамках одного проекта стала возможной.
У нас в компании все проекты, в которых применяется данный инструмент, разделены таким образом, чтобы получался один результирующий пакет на проект. Когда-то у нас был один проект, из которого на выходе было три пакета, но потом мы от этой практики отказались, прежде всего, из-за неудобства разработки (но это чисто для нас). И т.к. мы не используем такую практику (да и в принципе я лично видел не так много подобных современных проектов, возможно, конечно, просто не обращал внимание), то и в базовый вариант «многопакетность» не закладывалась. Но nxs-build-tools и был выложен в open source, чтобы он имел возможность развиваться и быть максимально удобным и полезным как можно большему числу людей. Поэтому все вопросы, замечания и идеи помогут его улучить )
Скажите, пожалуйста, Вы могли бы привести какие-то юзкейсы, где бы такая функциональность была бы полезна?
Апдейт nxs-build-tools — помощника в сборке deb и rpm пакетов
Blue-Green Deployment приложений на Spring c веб-сервером Nginx
Скоро от нас будут ещё переводы статей, продолжающие тему Zero Downtime, в которых как раз будет рассказываться про миграции БД )
Разбираемся с пакетом Context в Golang
И вновь огромное спасибо, поправил!
Проверил и поправил остальные прототипы и примеры, где были неточности. Теперь с этим проблем быть быть не должно ))
Разбираемся с пакетом Context в Golang
Спасибо за Ваше сообщение. Действительно и в самом оригинале статьи, и в нашем переводе имеется указанная неточность. Добавил уточнение к переводу.
Telegram-бот для Redmine. Как упростить жизнь себе и людям
telegram.bot_api_addrбыл добавлен лишний завершающий символ '/' (т.е. было указано:https://api.telegram.org/). Бот это не проверял и при конкатенации строк добавлял ещё один слэш, что не позволяло зарегистрировать Webhook в Telegram.Сейчас недочёт устранён, в репозиторий выложены пакеты с новой версией бота.
Telegram-бот для Redmine. Как упростить жизнь себе и людям
Скажите, пожалуйста, а почему именно Вас отталкивает реализация на Си?
Telegram-бот для Redmine. Как упростить жизнь себе и людям
Если решаемый вопрос окажется общим — по итогам резюме будет либо представлено тут, либо скорректирована инструкция по настройке бота.
Telegram-бот для Redmine. Как упростить жизнь себе и людям
Скажите, а где (например, в какой-то задаче) в Redmine Вы предполагаете сохранять лог общения пользователей в Telegram?
Исходя из специфики нашей работы нам, в принципе, достаточно стандартных средств самого Redmine и тех процессов, которые мы написали с использованием этого плагина. Но если Вы дадите ссылки на полезные плагины — буду благодарен! :)
Не совсем. Есть некоторые отклонения от стандартного движения задачи в соответствии с созданными нами процессами с помощью упомянутого плагина. Например, автоматическая смена статуса задачи с «Ожидание клиента» на «Ответ клиента» когда в тикет отвечает клиент.
А видимость полей тоже ограничена в зависимости от роли пользователя в проекте, чтобы клиентам не выводить лишнюю информацию, загромождающую экран.
Telegram-бот для Redmine. Как упростить жизнь себе и людям
Спасибо, мы рады, что наша идея оказалась полезной для сообщества!
Да, вполне. При выборе языка для разработки бота мы исходили из следующего:
1. У нас уже был свой framework, на котором разработано большинство внутренних инструментов для компании и который показал себя с хорошей стороны при решении подобных задач.
2. У нас есть разработчики на Си, которые знают этот framework
Поэтому мы посчитали, что получить максимально качественный продукт в максимально короткие сроки мы можем только с помощью Си.
У меня встречный вопрос: почему для Вас важно на каком языке разработан бот? Ведь для него создан пакет и есть репозиторий из которого его можно поставить одной командой, т.е. не надо ни компилировать программу вручную, ни разбирасться с тем как её установить. Можно просто брать и начинать пользоваться. Если, конечно, Вы не хотите дорабатывать бота под себя :).
Telegram-бот для Redmine. Как упростить жизнь себе и людям
Я ни в коем случае не хочу сказать, что имеющиеся решения плохие, нет, просто они другие. Например, наш бот позволяет нашим клиентам общаться с тех. поддержкой вообще не используя Redmine, а администраторам общаться с клиентами не используя Telegram.