search

diglabby / doika

Модуль прыема ахвяраванняў для некамерцыйных арганізацый метадам эквайрынга.
https://doika.falanster.by
24 stars 26 forks source link

Арганізаваць працэс стварэння рэлізаў на сэрверы і гітхабе. #84

Closed Tyuba4 closed 5 years ago

Tyuba4 commented 5 years ago

Три пути решения:

  1. Залить папку vendor в ветку
  2. Поставить vendor в gitignore. Перед релизом кто-то обновляет свой локальный репозиторий и архивирует его в zip. После этот архив сливаем в бесплатное облако
  3. Делаем доп. ветку для релиза. В ней ставим vendor. Из этой папки делаем релиз
alies-dev commented 5 years ago

Дадам ад сябе (2) і (3) можна аўтаматызаваць

Мне падабаецца (2)

PS: магу аўтаматызаваць (мне гэта цікава) PPS: яшчэ можна віліпіць скампіліныя frontend assets з репазіторыя, бандл рабіць і сабіраць у архіў таксама можна пры рэлізе, але спачатку трэба докі як ставіць дойку

pro2s commented 5 years ago

Согласен vendor и build папкам не место в репе, в идеале при установке на сервер должны быть выполнены установка зависимостей и компиляция assets, и другие необходимые действия, для облегчения добавить скрипты для автодеплоя на популярные платформы типа хероку + скрипты для ci. Ну а практически при желании иметь собранный проект можно использовать тот же travis-ci который при мереже в master или по тэгу, заберет проект, обновит зависимости, скомпилит assets, протестирует, запакует и зальет архив на github, ну или по аналогии с gh-pages в какую нибудь ветку. Руками это делать однозначно не стоит - есть шанс что то забыть, или как показывает недавняя практика поиметь в вендорах троян или закладку.

rizomaa commented 5 years ago

@lptn можаш напісаць

  1. я ты бачыш аўтаматызацыю. пакрокава.
  2. як можа быць забяспечана хуткае стварэнне апошняй версіі для тэставання, або пілотнага выкарыстання?

@Tyuba4 да якога варыянт сам схіляешся?

@pro2s тут пытанне,

  1. ці змогуць тэсцеры падняць усё на сваіх лакальных сэрверах без адмысловыый ведаў працы ўсё гэтыя залежнасці?
  2. "зальет архив на github" гэта будзе рэліз як тут https://github.com/diglabby/doika_1.2/releases або проста архівы ў нейкай тэчцы?
pro2s commented 5 years ago

@rizomaa по п.1 я бы предложил чтобы тестировщики могли автоматически развернуть приложение на том же heroku и тестировать, хотя тут надо определить какой минимальный уровень должен быть - поставить node локально и выполнить пару команд это не сложно, другой вопрос если предполагается что дойка ставится на виртуальный хостинг (без консоли) то да надо иметь готовый релиз и его проверять.

pro2s commented 5 years ago

по п.2 - да есть возможность такие релизы делать автоматически через api. например https://docs.travis-ci.com/user/deployment/releases

rizomaa commented 5 years ago

@pro2s

  1. так, большасць выпадкаў гэта віртуальны хостынг
  2. па тэсцерам. тут дылема. Што прасцей паставіць докер і туды інсталяваць інсталяваць рэліз, або прымушаць іх ставіць асяродак і пасля модуль... што прасцей?

пакуль мы ідзем па другому шляху, але адчуваю, што можа быць занадта вялікі парод для іх

зы прачытай калі ласка слэк, табе там паведамленне

alies-dev commented 5 years ago

@rizomaa

@lptn можаш напісаць

я ты бачыш аўтаматызацыю. пакрокава. як можа быць забяспечана хуткае стварэнне апошняй версіі для тэставання, або пілотнага выкарыстання?

Можна выкарыстоўваць AWS ці Azure ці магчыма Heroku ці іншыя вобланыя сэрвісы для гэтых мэтаў. Машчыма нават падыйдуць CI ціпа Travis. Усе яны маюць бясплатныя планы

Пакрокава:

  1. пры кожным каміце запускаць тэсты і code quality tools (phpcs, phpmd, php test coverage, php metrics, шмат чаго можна...)
  2. пры камітах у масцер аўтатам ствараць новы рэліз на GH, а ў воблачным сэрвісе ствараць білд (webpack + composer install) і архіў з яго, заліваць архіў у воблака.
  3. Пасля стварэння заліцця архіву абнавіць апошні GH release: дадаць спасылку на архіў у воблаке

Гатовы усе узяць на сябе бо тэма мне цікавая Дапускаю невялікія змены ў кроках, будзем плясаць у залежнасці ад бясплатных магчымасцях платформ якія будзем выкарыстоўваць

rizomaa commented 5 years ago

@lptn вы робіце нейкія прамежкавыя рэлізы? 1.3.1-...

alies-dev commented 5 years ago

@rizomaa пакуль што пры мне ніякіх новых рэлізаў не было, але ж я за semver 2.0 :)

Падрабязней я адказаў тут https://github.com/diglabby/doika/issues/408#issuecomment-489330895

rizomaa commented 5 years ago

@lptn На мой погляд ў нас прыбліжана да гэтага фармату. Толькі патчы ідуць як пулрэквэсты на брэнчах.

Калі ты зможаш карацей, чым зараз гэты падыход у нас тлумачыцца абазначыць, можна яго афіцыйна перапрыняць.

Пагаджуся, што калі пяройдзем 1.3 можна яе зрабіць як 2.0 ... і тады на мой погляд будзе аптымальна. Ці нешта там ёсць яшчэ прасцей? Яшчэ тут ёсць пытанні?

alies-dev commented 5 years ago

@rizomaa

@lptn На мой погляд ў нас прыбліжана да гэтага фармату. Толькі патчы ідуць як пулрэквэсты на брэнчах.

Па semver:

Мне здаецца ў гэтым issue намешана шмат усяго

  1. semver -- гэта толькі пра тое як версіі НАЗЫВАЦЬ (Прыняць стандарт найменавання версій рэлізаў #416 -- толькі што стварыў)
  2. Як пры гэтым працуем з git і github -- гэта ужо іншае пытанне (брэнчы ці тэгі на новую версію, як адбрэнчовываемся і які flow для ПР).
  3. Як збіраць інсталякі дойкі для простага разготвання -- яшчэ адна іншая задача (Аўтаматычнае стварэнне архіва-істалятара для рэлізаў #160)
  4. Як аўтаматам дэплоіць свежы код на тэставыя асядкі -- яшчэ адна іншая задача (continious delivery (CD)) #319
  5. Як і дзе зарускаць тэсты -- гэта continious integration (CI), гэтае пытанне мы, дзякуй богу, вырашылі (Дадаць канфіг для Travis CI #214)

Прашу гэтыя задачы раздзяляць і не блытаць

Самы просты варыянт рэалізацыі 2) 3) і часткова 4) -- праз GitHub

alies-dev commented 5 years ago

Закрываю гэтую issue бо на карысць дубліката з болей багатай гісторыяй:

Аўтаматычнае стварэнне архіва-істалятара для рэлізаў #160