Как поделиться кодом с непрерывной интеграцией

Question

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

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

Answer 1

Инструмент, подобный Code Collaborator (ссылка на Google, smartbear.com не работает ...), позволит вашим пэрам увидеть ваш код без его фиксации. Вместо этого вы просто отправляете его на рассмотрение.

Для них немного сложнее - запустить , хотя.

В качестве альтернативы, настройте вторую ветвь / fork вашей кодовой базы, чтобы вы могли работать в ней, ваши коллеги могут синхронизироваться с этим, и это не сломает сервер сборки. Когда вы закончите работать в своей собственной ветке, вы можете объединить ее с mainline / trunk / чем угодно.

Answer 2

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

Answer 3

Я нахожусь в точно такой же ситуации. Как инженер-строитель, у меня это прекрасно работает.

Прежде всего, позвольте мне разбить ветки / проекты. @Dolph Mathews уже упоминал о ветвлении и tbh, которые являются неотъемлемой частью работы вашей установки.

• Возьмите основную кодовую базу и интегрируйте ее в несколько личных или «меньших» ветвей команды. то есть branch_team_a, branch_team_b, branch_team_c
• Затем настройте teamcity для создания этих веток под разными заголовками проекта. Таким образом, в конечном итоге у вас будет следующее: главный проект, проектная группа А, проектная группа Б, проектная группа С
• В-третьих, затем настройте проверки разработчиков, чтобы они выполняли предварительные сборки для разорванных ветвей. Для этого вы можете найти плагин TC в разделе инструментов и настроек.

Теперь у вас есть 3-уровневая настройка. - Разработчик запускает предварительную сборку на удаленном компьютере со своего рабочего стола против своего проекта. Если он проходит, он проверяется в хранилище, т.е. branch_team_a - Команда проекта A проходит после нескольких проверок; в этот момент вы интегрируете свои изменения из branch_team_A в основную ветку - Проект Main build!

Если все прошло успешно, значит, у вас есть кандидатская версия. Если одна из частей выйдет из строя, создайте проекты a, b или c. это не проверяется в основной. Это был мой испытанный метод, и он работает каждый раз. Это также значительно улучшает командное общение.

Answer 4

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

Это также прекрасный пример хорошего времени для использования веток / вилок и просто слияния с магистралью, когда все сломанные вещи исправлены.