Notice: file_put_contents(): Write of 2240 bytes failed with errno=28 No space left on device in /var/www/tgoop/post.php on line 50

Warning: file_put_contents(): Only 16384 of 18624 bytes written, possibly out of free disk space in /var/www/tgoop/post.php on line 50
Экстраполяция IT@itextrapolation P.420
ITEXTRAPOLATION Telegram 420
Ребята, мы таки настроили работу с гит сабмодулями в нашей сервисной архитектуре, наступили на кучу граблей и сделали пачку костылей. Год назад в «Экстраполяции» я описывал причины почему этого захотелось и получил много справедливой критики в ответ. Где-то тогда и было решено попробовать эту систему в боевых условиях. Прошёл год и система работает довольно хорошо и стабильно с некоторыми нюансами:

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

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

3. Не все языки и фреймворки готовы к такому. Скажем, джаваскриптовый npm к такому не готов, а вот yarn имеет опцию workspaces, которая ведёт себя ровно так, как хочется.

4. Автотесты становятся просто необходимыми. Без них уж очень много ручной необходимой работы.

5. Публичными зависимостями и их версиями нужно управлять автоматически. У нас настроен бот renovate, который каждое утро делает пулл реквесты с обновлением всех зависимостей во всех репозиториях. Ещё в планах настроить правильный автомерж таких вот пулл реквестов, но пока приходится вручную.

6. Нужна жесткая фиксация версий внешних зависимостей. Никаких ">= 1.14", только "1.14.5". Так и обновлять легче и синхронизировать удобнее.

7. Изменения в сабмодули вносить стало очень удобно. Просто cd submodulename и уже там работаешь с сабмодулем непосредственно. А в родительском репозитории можно даже коммитить изменения дочернего, чтобы оно вместе работало. Потом с релизом дочернего всё станет, как должно быть.

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

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



tgoop.com/itextrapolation/420
Create:
Last Update:

Ребята, мы таки настроили работу с гит сабмодулями в нашей сервисной архитектуре, наступили на кучу граблей и сделали пачку костылей. Год назад в «Экстраполяции» я описывал причины почему этого захотелось и получил много справедливой критики в ответ. Где-то тогда и было решено попробовать эту систему в боевых условиях. Прошёл год и система работает довольно хорошо и стабильно с некоторыми нюансами:

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

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

3. Не все языки и фреймворки готовы к такому. Скажем, джаваскриптовый npm к такому не готов, а вот yarn имеет опцию workspaces, которая ведёт себя ровно так, как хочется.

4. Автотесты становятся просто необходимыми. Без них уж очень много ручной необходимой работы.

5. Публичными зависимостями и их версиями нужно управлять автоматически. У нас настроен бот renovate, который каждое утро делает пулл реквесты с обновлением всех зависимостей во всех репозиториях. Ещё в планах настроить правильный автомерж таких вот пулл реквестов, но пока приходится вручную.

6. Нужна жесткая фиксация версий внешних зависимостей. Никаких ">= 1.14", только "1.14.5". Так и обновлять легче и синхронизировать удобнее.

7. Изменения в сабмодули вносить стало очень удобно. Просто cd submodulename и уже там работаешь с сабмодулем непосредственно. А в родительском репозитории можно даже коммитить изменения дочернего, чтобы оно вместе работало. Потом с релизом дочернего всё станет, как должно быть.

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

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

BY Экстраполяция IT


Share with your friend now:
tgoop.com/itextrapolation/420

View MORE
Open in Telegram


Telegram News

Date: |

Among the requests, the Brazilian electoral Court wanted to know if they could obtain data on the origins of malicious content posted on the platform. According to the TSE, this would enable the authorities to track false content and identify the user responsible for publishing it in the first place. Content is editable within two days of publishing For crypto enthusiasts, there was the “gm” app, a self-described “meme app” which only allowed users to greet each other with “gm,” or “good morning,” a common acronym thrown around on Crypto Twitter and Discord. But the gm app was shut down back in September after a hacker reportedly gained access to user data. Administrators
from us


Telegram Экстраполяция IT
FROM American