Как организовать парную разработку с Git для отладки на сервере?

Question

[kkolorid]

Исходные данные такие: два разработчика (один из них тимлид) и руководитель проекта. Необходимо организовать разработку и эксплуатацию телеграм-бота на Python (БД: MySQL) с дальнейшей его поддержкой (доработкой) с применением Git на сервере с Linux. Код пишется на личном компе с Windows и PyCharm, а запускаться и тестироваться должен только на сервере (через штатные средства PyCharm, как удаленный проект). Т. е. нужно как-то организовать работу репозиториев так, чтобы на сервере могли функционировать сразу несколько версий бота (наверное): Продакшн, Разработка (общая для проверки руководителем или тимлидом) и по боту на каждого разработчика. Соответственно, у каждой версии свои токены API Telegram.

С Git в командной разработке раньше не работал, хотя примерно представляю как это работает. Поэтому описал требования примерно, как это вижу, в силу своего незнания, могу ошибаться в каких-то моментах, прошу поправить.

Answer 1

[Vitsliputsli]

Стандартно, gitflow. К примеру так: разработка ведется в отдельных ветках feature, для интеграции сливаются в dev, на основе dev создается release и после тестирования заливается в master, который и выкладвается в прод.
Разные токены это относится к окружению, в коде этого быть не должно. Окружение собирается сборщиком деплоя, например в Jenkins.

Answer 2

[Владимир Коротенко]

два разработчика (один из них тимлид) и руководитель проекта.

уже несколько смешно, по идее первый должен это знать.
Итак репозиторий создается с 3 ветками

main
stage
dev

каждая фича создается в новой ветке путем клонирования main
шаблон ветки пусть будет vkorotenko/features/42444-fix_css_on_main
где идет имя пользователя, потом что это, потом номер в баг трекере и какое то описание
после выполнения работ идет мердж в dev stage main
для билда используйте дженкинс
вот пример пайплайна

pipeline {
	agent any
	environment {
		projectKeyFront = 'kvn-yanotes-front'
		projectKeyBack = 'kvn-yanotes-back'
		VUE_APP_STS_SERVER= 'https://auth.yanotes-dev.loc'
		VUE_APP_REDIRECT_BASE = 'https://yanotes-dev.loc'
		VUE_APP_CLIENT_NAME = 'yanotes_dev'
	}

    stages {

		stage('build client app') {
			agent { 
				dockerfile { 
					filename 'Dockerfile-node'
					
				}
			}
            steps {
                sh 'cd ./YANotesServer/App/ && npm install --verbose'
				sh 'cd ./YANotesServer/App/ && npm run build'
				stash includes: 'YANotesServer/App/**/*', name: 'client-app'
				sh 'rm -rf ./YANotesServer/App'
            }
			
        }
		
		stage('build server app') {
			agent { 
				dockerfile { 
					filename 'Dockerfile-dotnet-microsoft6'
				}
			}
            steps {
				unstash 'client-app'
				
				
					sh '''
						
						dotnet publish --framework net6.0 --configuration Release --runtime centos-x64 ./YANotes.sln
						
					'''
				
				
				stash includes: 'StsServer/bin/Release/net6.0/centos-x64/publish/**/*', name: 'auth'
				stash includes: 'YANotesServer/bin/Release/net6.0/centos-x64/publish/**/*', name: 'app'
            }
        }

		stage('install systemd unit file') {
			agent any
			steps {
				sshagent(['jenkins-ci-yanotes-dev']) {
				
					sh 'scp SystemdUnitFiles/yanotes.service-Dev [e-mail]:/etc/systemd/system/yanotes.dev.service'
					sh 'scp SystemdUnitFiles/yanotes.auth.service-Dev [e-mail]:/etc/systemd/system/yanotes.auth.dev.service'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl daemon-reload'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl enable yanotes.dev'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl enable yanotes.auth.dev'
					
				}
			}
		}

		stage('deployment web application') {
			agent any
			steps {
				sshagent(['jenkins-ci-yanotes-dev']) {
					unstash 'app'
					
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl stop yanotes.dev'
					// sh 'ssh -o StrictHostKeyChecking=no [e-mail] rm -rf /var/yanotes'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail]  mkdir -p /var/yanotes'
					
					sh 'scp -r ./YANotesServer/bin/Release/net6.0/centos-x64/publish/* [e-mail]:/var/yanotes'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] systemctl start yanotes.dev'
				}
			}
		}

		stage('deployment auth application') {
			agent any
			steps {
				sshagent(['jenkins-ci-yanotes-dev']) {
					unstash 'auth'

					sh 'ssh -o StrictHostKeyChecking=no [e-mail]  systemctl stop yanotes.auth.dev'
					// sh 'ssh -o StrictHostKeyChecking=no [e-mail]  rm -rf /var/yanotesauth'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] mkdir -p /var/yanotesauth'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] mkdir -p /var/yanotesauth/logs'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail] chmod 777 /var/yanotesauth/logs'
					
					sh 'scp -r ./StsServer/bin/Release/net6.0/centos-x64/publish/* [e-mail]:/var/yanotesauth'
					sh 'ssh -o StrictHostKeyChecking=no [e-mail]  systemctl start yanotes.auth.dev'
									
				}
			}
		}

    }
}

Answer 3

[Saboteur]

Банально сделать несколько "енвайрнментов", то есть тестовых ботов, и привязать ветки к этим веткам.

Намример можно привязать к именованиям бренчей, и создать заранее токены для release-bot, main-bot, dev1-bot, dev2-bot.
Каждый разработчик делает свои ветки согласно dev1/feature-blabla и так далее.

Триггер на сервере, что если пришел коммит в ветку по указанной регулярке - пересобрать и перезапустить бота с его токенами.

Comments

[kkolorid]

Ваш ответ мне кажется самым логичным решением для нашего простого проекта, на котором мы собираемся освоить git. Подскажите, что почитать по git, что бы подобное у нас реализовать? Как именно эта привязка реализуется в git? Нужно ли как-то по особому администрировать сам сервер (пользователей ssh и их доступы к дирикториям, например)?

[Saboteur]

Можете почитать конечно про git hooks, но будет проще поставить какой-нить CI инструмент, типа Jenkins/GitLab или пользоваться github actions, в общем что-либо, что будет реагировать на коммиты.

Answer 4

[Виктор П.]

Странно, что советуют делать какие-то ветки под окружение, привязывать куда-то токены к названиям.
Тут намешано несколько разных вещей. Если есть тимлид, он должен разбираться.
Для того, чтобы писать на винде, а хостить на линуксе желательно использовать докер. Ну или хотя бы сборку проекта всегда делать на одном раннере, чтобы не было косяков, что "у меня работает, а на проде нет".
В гите хранится кодовая база, можете процессы брать любые, gitflow там или чего. Основное - в кодовой базе не должно быть секретов, чтобы одну и ту же сборку можно было тестировать и раскатывать на разные окружения dev/stage/prod
Секреты, типа строки подключения, токены и прочие данные, которые не должны отсвечивать неправильно хранить в репозитории. Они должны лежать в хранилищах секретов, в облачных провайдерах точно есть, погуглите key vault или тип того. Для простоты иногда хранят в коде (еще раз, это не правильно) не знаю, что в питоне, файлы типа appsettings.dev.json, appsettings.stage.json, appsettings.prod.json, типо таких. Иногда такие профили хранятся только у "ответственного специалиста", который занимается публикацией, но это не удобно. Зависит от уровня зрелости проекта
Окружения dev/stage/prod проще разворачивать на отдельных виртуалках, чтобы был айпишник, для телеговского бота он вроде нужен. Если нет возможности разнести на разные виртуалки, а задача держать все окружения на одном сервере, тогда их вешают на разные порты и обычно используют nginx для проксирования запросов. Ну и в таком случае домены надо прикручивать