Вы правы. Я переформулировал мысль, чтобы не вводить в заблуждение. Речь шла больше о готовых, популярных решениях, которые решают перечисленные задачи.
Не совсем. Дорога «прокладывалась» мной в качестве руководителя и тимлида этой команды. Это не просто «уволить джунов и нанять специалистов», работали все вместе. На счет пиара, вы правы, это статья из серии «смотрите что мы сделали», которые пишут как организации так и частные лица. С наступившим вас!)
Для больших проектов с legacy кодом тоже можно использовать flake8. Для этого есть flakehell (от we-make-python-styleguide), который индексирует текущие замечания и не показывает их.
Статья пахнет 2010ыми. Фактически, написали MVC (он давно уже не в моде) фреймворк. Посмотрите в сторону Django или же Starlette, если вы пишете только API на стороне backend'a.
А с какими проблемами настройки сетей вы сталкивались в k8s? Если речь идёт про классические приложения (например, Django), то я склоняюсь к тому, что без k8s или его урезанных версий на проде нормально не настроить те же сети. А если хочется больше автоматизации, можно (и нужно имхо) брать managed k8s у того же Google или DO.
Думаю, статья утратила свою актуальность (в том числе выше перечисленные аргументы по сетям и прочему), потому как в 2019 мало кто деплоит Docker на production. Docker (вместе с docker-compose) нужен для рабочего окружения разработчиков, CI и пр. Production ready это k8s (или его «мини» версии, типа mikrocube или k3s) с runC вместо Docker.
“Многие уже поняли, что от них один вред. Написание тестов отнимает много времени, за которое вы могли бы сделать что-то более полезное.”
Немного странное мышление) Разработка и тестирование — единый процесс. К тому же, на тесты/сценарии можно вешать теги и тестировать их локально, не обязательно ждать результата CI.
Вы правы. Я переформулировал мысль, чтобы не вводить в заблуждение. Речь шла больше о готовых, популярных решениях, которые решают перечисленные задачи.
Да, и тут на помощь придет gitlab-board! :) Мы хотим убрать эти ограничения для Community Edition в виде open-source проекта.
Спасибо, ознакомлюсь.
Не смотрели. Спасибо за совет!
Там ведь написано: отечественное ИЛИ open-source решение.
Есть Community Edition на крайний случай. Он open-source.
Собственно так оно и было. Нас уведомили ровно за 3 недели до 30 октября 2022.
Спасибо за полезный отзыв!
На момент нашего перехода этого проекта еще не было. Выглядит хорошо! Спасибо.
Выглядит современно и приятно, но судя по информации на сайте, предлагается только on cloud вариант.
Да, согласен :)
Думали об этом. Вполне вариант, но не хотелось возвращаться в нулевые.
ПО покрывалось юнит-тестами и интеграционными BDD сценариями разработчиками. Бюджета на отдельных автотестеров к сожалению не выделили.
“Многие уже поняли, что от них один вред. Написание тестов отнимает много времени, за которое вы могли бы сделать что-то более полезное.”
Немного странное мышление) Разработка и тестирование — единый процесс. К тому же, на тесты/сценарии можно вешать теги и тестировать их локально, не обязательно ждать результата CI.