*nix
DevOps
IT Infrastructure
IT systems testing
Development Management
Comments 7
0
есть боль — уменьшайте ее.

Забавное заключение, аналог: жизнь боль — уменьшайте ее.

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

Не совсем понял по стилю повествования — это относится: к плюсам, к минусам, к непреложным фактам текущей реальности? Далее следуют выводы «Это позволило».
Хотелось бы прочитать, как обруливается данный момент, если он относится к минусам. Все таки нестабильное окружение и тестируемые сценарии вещь и злободневная, и интересная, а мало где можно почитать, как с таким справляются в сложных системах.
0
Не совсем понял по стилю повествования — это относится: к плюсам, к минусам, к непреложным фактам текущей реальности

суровая действительность с которой приходится жить.


Хотелось бы прочитать, как обруливается данный момент, если он относится к минусам.

были не гласные договоренности:


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

в принципе почти стандартный giithub flow получился, с поправками:


  • по каждому коммиту легковесные тесты гоняем
  • артефактов храним минимум и только по релизным веткам
0
Спасибо за пояснения.
Я правильно понимаю — это в основном аффектит ручные тесты? Или автоматические тоже?
0
* Ручные — по релизным бранчам(собранным артифакатах)
* полный набор автоматических тестов по стабильным бранчам
Only those users with full accounts are able to leave comments. , please.