Who’s doing what as far as managing updates and dev on a live app?

Need help App Organization
1

Hey all,

Wanted to get some feedback on deployment to a live version.

We have 3 developers working on a live app, we all build in our own branch and merge to main once a day. After testing we push to live.

It works pretty well however I’m wondering what other people do and whether it’s worth having a 2nd level branch for each feature that would be merge to each developers 1st level branch daily with a weekly merge to main probably on a Thursday morning for testing Thursday before pushing to live Thursday afternoon or Friday morning.

Would love to hear what’s working well for others

1 Like
2

@jared.gibb i hear you run a pretty tight ship I’d love to hear your thoughts

3

We don’t do daily or weekly merges it’s more based on feature completion.

We have 1 project manager who is in charge of managing the main development branch. He’s the only one allowed to merge, sync, or push live.

From there each developer or team has their own branch(sub members of the team will branch from the main devs branch and the main dev manages them if applicable). When a feature is ready it gets QA tested on that developers branch by the PM.

It then gets merged up to main. QA tested again by the main dev & PM. If all is good then the update will go live.

Once live the PM who is familiar with each feature that just went live will then handle syncing each of the other devs branches with live.

It’s not flawless by any means since we can’t see exact changes so it requires a great PM.

Typically, we also have the dev notate in trello every page & data type that was adjusted in their branch. When pushed live the PM posts those in the deploy notes.

1 Like
4

Sounds super efficient given the tooling.

What do you do if customers find a bug? Do you roll back immediately? HotFix?

What type of platform do you run?

5

Yea unfortunately when merging is the only time you’ll get a changelog.

I like @chris.williamson1996’s approach of this being a single person for QA purposes.

One way we’re managing this is through:

  • Main
    • test
      • dev environmentX
      • dev environmentX

This avoids any breaking changes being implemented in Main before being tested. Any downsides to this approach in your view?

1 Like
6

I like this in that your keeping Main free in case you need to make any quick changes without having to push untested work.
There has been a bunch of times I’ve wanted to push an important small change but I could not as I had many larger features half built in main

1 Like