Szczególnie ze względu na licencję Inteliji IDEA dla Open Source, myślę, że powinniśmy rozważyć przejście z gitflow na githubflow. Wtedy szybciej będzie widać udział w projekcie, a nie dopiero przy releasie aplikacji i będzie można ubiegać się o licencje. Co o tym myślicie?

Szczególnie ze względu na licencję Inteliji IDEA dla Open Source, myślę, że powinniśmy rozważyć przejście z gitflow na githubflow. Wtedy szybciej będzie widać udział w projekcie, a nie dopiero przy releasie aplikacji i będzie można ubiegać się o licencje. Co o tym myślicie?

Jeżeli zwiększy to szanse na licencje, to śmiało można spróbować. Tym bardziej, że gitHubFlow wygląda całkiem niewinnie (https://guides.github.com/introduction/flow/). W razie czego, zawsze w przyszłości można wrócić do gitFlow jeżeli gitHubFlow okaże się niewystarczający.

Jeżeli zwiększy to szanse na licencje, to śmiało można spróbować. Tym bardziej, że gitHubFlow wygląda całkiem niewinnie (https://guides.github.com/introduction/flow/). W razie czego, zawsze w przyszłości można wrócić do gitFlow jeżeli gitHubFlow okaże się niewystarczający.

Może nie do końca zrozumiałem, ale zastanawia mnie jeden element - deploy. Czy w tym przypadku zamierzamy każdy pull request wdrażać na środowisku produkcyjnym? Czy nie będzie to zbyt czasochłonne i czy mamy możliwość tak częstych wdrożeń nowych wersji?

Może nie do końca zrozumiałem, ale zastanawia mnie jeden element - deploy. Czy w tym przypadku zamierzamy każdy pull request wdrażać na środowisku produkcyjnym? Czy nie będzie to zbyt czasochłonne i czy mamy możliwość tak częstych wdrożeń nowych wersji?

Ogólnie patrząc na github flow podchodziłbym do tego dość swobodnie, traktując deploy, roboczo, jako testy na systemie po merge'u z branchem master. Jeżeli miałoby to być rzeczywiste wdrożenie w produkcje, to podejrzewam, że mogłoby być to problematyczne.
A tak swoją drogą, jak w tym momencie wygląda wdrażanie nowej wersji Mrozy?

Ogólnie patrząc na github flow podchodziłbym do tego dość swobodnie, traktując deploy, roboczo, jako testy na systemie po merge'u z branchem master. Jeżeli miałoby to być rzeczywiste wdrożenie w produkcje, to podejrzewam, że mogłoby być to problematyczne. A tak swoją drogą, jak w tym momencie wygląda wdrażanie nowej wersji Mrozy?

Też myślałam o tym bardziej swobodnie. Tych flowów jest kilka, nie wiem, który byłby dla nas najlepszy.. Jeżeli chodzi o deploy, to moglibyśmy postawić jenkinsa czy bamboo, żeby puszczał testy i robił deploy na jakieś testowe środowisko. Przy okazji to byłoby super, bo moglibyśmy sami testować, jak działa aplikacja.
Nigdy nie robiłam takich rzeczy, ale takie devopsowe są fajne i super byłoby się trochę tego nauczyć przy okazji smile
W obecnym momencie wygląda to tak, że przygotowujemy wszystko, idziemy do ośrodka i im to instalujemy. Nie jest to zautomatyzowane, jedynie update aplikacji na androida jest możliwy z poziomu aplikacji - ściąga najnowszą wersję, którą umieszczamy na serwerze. Tym będzie trzeba się zająć dopiero.

Też myślałam o tym bardziej swobodnie. Tych flowów jest kilka, nie wiem, który byłby dla nas najlepszy.. Jeżeli chodzi o deploy, to moglibyśmy postawić jenkinsa czy bamboo, żeby puszczał testy i robił deploy na jakieś testowe środowisko. Przy okazji to byłoby super, bo moglibyśmy sami testować, jak działa aplikacja. Nigdy nie robiłam takich rzeczy, ale takie devopsowe są fajne i super byłoby się trochę tego nauczyć przy okazji :D W obecnym momencie wygląda to tak, że przygotowujemy wszystko, idziemy do ośrodka i im to instalujemy. Nie jest to zautomatyzowane, jedynie update aplikacji na androida jest możliwy z poziomu aplikacji - ściąga najnowszą wersję, którą umieszczamy na serwerze. Tym będzie trzeba się zająć dopiero.
187
views
4
replies
3
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft