search

UdacityMobileWebScholarship / guess-quote

This application is a collaborative project made by the Google Udacity Mobile Web Specialist Scholars.
MIT License
22 stars 48 forks source link

Need a development & production branch #14

Closed ishank-s closed 6 years ago

Rohanhacker commented 6 years ago

why is that ? You can develop on your fork and send pr's , We just need a master and a release branch

ishank-s commented 6 years ago

Well, Imagine someone posts a PR that is breaking for some specific OS or env, maybe the contributor and the co-mod both are able to run that PR but it's still broken and that would affect all the users. If we have a DEV branch that problem would be mitigated and there aren't many projects that do not have the following 3 levels- CANARY DEVELOPMENT STABLE

Rohanhacker commented 6 years ago

Our app is too simple for having a canary and development branch. I don't see how having a staging branch will prevent your use case.

skyshader commented 6 years ago

Yep, we will definitely not use the master branch as the main production branch. Our plan is to use a release branch for production purposes, so that contributors don't have to switch to development branch and keep track of the branch while submitting pull requests. I hope this clears the doubt? Do share your point of view though.

ishank-s commented 6 years ago

@Rohanhacker as i explained the new feature X may break things on different env, that the contributor would not necessarily catch.Dev branch may break while the master(STABLE) would still work without that feature.

retrocausal commented 6 years ago

Mods! where are we hosting the app? how will people access the landing page? Would it be gh-pages?

If yes, what branch does gh-pages use for deployment?

Is it master alone? or can you use another branch?

twishasaraiya commented 6 years ago

Our plan is to develop a prototype with minimal functionalities and full PWA. Focusing now on production, since we are just starting, seems too early. Lets first focus on making a basic working app. Please do feel free to share your opinions here.

skyshader commented 6 years ago

gh-pages typically resides in gh-pages branch itself. Though we are still discussing how to proceed with the deployment. If you gave any suggestion, feel free to start a new thread and we can discuss this there :)

retrocausal commented 6 years ago

@skyshader If I may, I think github changed that feature long back. master is the only branch github uses to deploy the app as of 2017 as a jekyll site / a gh-page. correct me if Iam mistaken.

Hence, the need for a prototype branch, so that master always is functional. Also, gh-pages sound resonable for hosting an app. No overheads

Rohanhacker commented 6 years ago

We have a backend so we can not deploy on gh-pages. We can use something like heroku for backend and gh-pages for frontend

skyshader commented 6 years ago

@retrocausal master is used in case you're creating an organization or personal global page. In case of project page, we can use master or gh-pages or any other branch that we can configure.

Read this for more info: https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/

Btw, we have still not decided whether we are going forward with github pages for frontend deployment or not. So, to make contributions easier and taking some load on ourselves for deployment purposes, we have fixed master for our constant development branch.

Correct me if I missed something.

retrocausal commented 6 years ago

I Just have one last point to make. Handling Contributions and handling branches (one dev and one deployment ideally not a branch more , not a branch less) would be headache free and time efficient If we could decide on how the app is presented to the world. And identifying which branch is which, depends on how we host the app. And that is an initial pre contribution consideration which If the moderators can decide now, can lead to a chaos free deployment and development of the prototype.

I assumed it might be a github hosted app, but If you guys have anything else in mind, do consider firmly categorising branches based on how the app is made available.

Arbitrary assumptions of identifying a development branch, could lead to utter discomfort for the deployment team at a later date

skyshader commented 6 years ago

@retrocausal I totally understand your point. And, that's the reason we are thinking of creating a release branch which will be stable always and will be used for deployment purposes.

Though I'd like to hear what other mod's thoughts are on this. @twishasaraiya what's your take on:

  1. master and release
  2. dev and master

IMO, keeping master as production makes more sense but considering master is the default branch and during submitting a pull request and cloning the repository, there are a high chances the contributors have to change the branch everytime and might forget to do so sometimes. Do we have any way to change the default branch of a repository (I think we don't have the permission for that)?.

But if we go with master and release branch approach, it would be on us to as to when to merge with release. The contributors as usual will work with master and submit PRs there.

@retrocausal your thoughts are appreciated as well. Please chip in. :)

retrocausal commented 6 years ago

So, Per me, the names you have mentioned are not an issue. we can name the branches however we wish to.

What I wondered was,

Suppose we have two branches

branch 1 and master

If we use gh-pages , when we deploy, github would automatically choose the master as the deployable branch. I am guessing https://Udacitymobilewebscholarship.github.io/guess-quote/ would then be the landing page.

In the above scenario, we do not have any option but to make branch-1 the production branch, and master the deployable /release branch.

However, If we choose to host it elsewhere,

say a digital ocean droplet / GCP / anywhere else,

then, the branch master, can be the production branch, and release / whatever name we choose, can be the deployment branch.

I am guessing in this scenario, the landing page would be up to us. We would need to have a custom domain?

All we would need to do, is log in with suitable permissions, and do a

git checkout <release-branch-name> on the server

twishasaraiya commented 6 years ago

@skyshader I think we should go with dev and mater branch. We should keep master as the production-ready branch and we could do our feature development on dev branch. Also, it would make it easier to deploy on GitHub Pages.

skyshader commented 6 years ago

@retrocausal The name is not the concern for me as well.. However the default branch is.

Btw it makes sense to keep master stable and a dev branch for contributions. Let's finalize this. Later, we can branch out from master into release if required.

@twishasaraiya we also need to update the Contribution docs accordingly.

twishasaraiya commented 6 years ago

Okay @skyshader, I will update the contribution docs. Are we keeping the name of the development branch as dev or something else?

skyshader commented 6 years ago

@twishasaraiya what do you suggest? You can create dev or development branch and update that in docs. Let me know if you want me to create the branch and also your preferred name.

twishasaraiya commented 6 years ago

@skyshader I am creating develop branch.

gpalsingh commented 6 years ago

I'm really confused with the situation now. We are supposed to be adding new features in develop right? But right now I see the pull requests that are open are for the master branch...

twishasaraiya commented 6 years ago

@gpalsingh All new PR will be merged into develop. Since this model was adopted later and PR were made earlier we will be merging them into master. But all PR from now on will be merged into develop. I hope I have cleared your confusion.