Best practice for working with DevKinsta and multiple developers

Hi all,
We are in the process of migrating our site to Kinsta. We want to make sure that we have an easy way to develop our website while keeping it stable.

The way we work is such that minor changes in the site are done by us, let’s call us Developer A, and more advanced changes are being made by a developer outside of our company, let’s call her Developer B.

We understand the basic concept flow of DevKinsta->Staging-> prod. We also realize that after prod was changed, we have to delete stating and recreate it.
Our question goes as follow:

Developer A and Developer B both imported our site using DevKinsta to their local machines and began developing different changes.
Developer A finished his change and pushed it into staging. We liked the changes in staging and therefore we decided to make staging go Live, deleted staging, and recreated it from the new Live environment.

A few days later, Developer B finished working on her change. However, when she imported the site using DevKinsta, it had the old version of the site, before Developer A pushed his changes. If we push her changes to staging and then production, will we lose **Developer A’**s changes? How should we sync between them? What happens if their changes are conflicting?

Thanks

Proper versioning control, you can make a free private repo for your small team in Bitbucket.
I make a change to git, my colleague pulls the change and so forth.
You can set both Live and Staging to pull from it.
No more need to push from DevKinsta, just push locally, pull in staging or live.
With conflicting changes, you choose what to merge.

And you don’t need to delete staging, it’s just a waste of time.
Just restore the daily backup to staging or create a manual backup in live, restore that new backup to staging, and afterwards, delete the manual save.
Fresh staging quicker.

1 Like

Hi @Ran_Rubin . Welcome to DevKinsta! That’s a great question :thinking: . I think what @ZagnaH suggested here regarding version controlling in a repo is a great idea.

This would make for a great feature request though for a team collaboration!

1 Like