On develop and master branches

[jgorset]

I noticed that there are some projects that don't do this bit anymore, so I think we ought to talk about it and change it to be in line with what we currently think is best.

Then what?

If you're working on an application and you merged to develop or master, you push it to the staging or production server, respectively. The staging server should always be on the tip of develop and the production server should always be on the tip of master.

What do you think we should do, @hyperoslo/everyone?

[RamonGilabert]

We don't have the separation between develop and master in iOS, I guess because of the different deployment system.

[changxiangzhong]

@jgorset I think it really depends on the scale of the project. If client developers are working on the staging server, I think it's better to do the deployment in specific time - such as end of a sprint. To keep the staging server stable.

[espenhogbakk]

I've sort of started doing:

develop -> development server master -> staging server (with predictable deployments)

If master branch is tested and confirmed working on staging for client apps I promote it to production using heroku deployment pipelines:

[gauravtiwari]

For web projects it seems that this is an important and good practice to keep, although at inception of the project this might not seem relevant. Perhaps, because there might not be a production at early stages of the project, however once project is live on multiple environments the requirement becomes evident (sharing demo etc.).

We tried heroku pipelines on dennyeoljen together with Github hooks and it works pretty good and comes free - automatic deployments to selected environments (if toggled).

[zenangst]

For iOS, master represents the latest version of the application. We do feature branches and merge them into master. We don't have the concept of develop as it feels unnecessary. staging, pre-production and production is handled with different targets within the project.

We rely on Releases to know what is in production, if we need to 🐒-patch, we checkout the release and create a branch based on the commit that we need to throw 🍌 's at.

This works fine for iOS, we could of course go with develop and do the same as you guys are doing (or not doing).

What are your thoughts on this @hyperoslo/ios ?

[jgorset]

What's a development server, @espenhogbakk? Isn't that your local machine?

[espenhogbakk]

It might be a bad name, but in this case it's a heroku instance which always is on the tip of develop.

This way staging is exactly the same as production, and we can test production/master branch without actually rolling it out to production. I know you can do that by just checking that develop and master is on the same git ref, but this way it's very clear.

[sindrenm]

I second @gauravtiwari's idea of having develop match the staging server and master match the production server at all times. And I'm really for the idea of automatic deploys from those branches as well, it simplifies workflow. (Just remember that it happens so you don't “accidentally” push to the master branch. :tada:) That might require some post-deploy hooks, though, like database migration for Rails apps, for instance, just to keep that in mind.

I also think it's important that the staging environment mirrors what we have on production, like @espenhogbakk said, so the only pushes to master should probably just be merges from develop. I suppose it's possible, however, that merges break something, so it may be a good idea to (1) merge develop → master (no-ff), (2) merge master → develop (ff) and (3) deploy develop and test before pushing master. At least post-release, so you know you're not pushing a merge commit that hasn't been tested.

[espenhogbakk]

The inspiration for my setup pictured above was this article from Heroku. But I added the "development" server in the mix instead of merging straight to master, mainly because that is what we have been doing.

[jgorset]

Hi old friends! I'm cleaning up my issues, so I'm closing this one. Trust you won't mind. :blush: