Question

I’m currently managing the development of a live web application. There are two developers. We’re looking to define a workflow that specifies how builds and deployments should happen.

We’re currently using codebaseHQ for source control.

This is what I’m thinking:

1. Dev1 and Dev 2 get and commit changes to a single repository on CodeBaseHQ.
2. We push updates from codebaseHQ to alpha.domain.com, which is decoupled from the production database, for initial testing.
3. Assuming tests go well, merge changes onto beta.domain.com, which is coupled to the production database, for further testing.
4. Assuming these tests go well, merge onto domain.com (production).

Does this sound okay? It seems like a very cumbersome process for the developers – they have to test/push twice for each changeset. With infrequent updates this seems bearable, but if we’re pushing changes on a daily basis, what would you recommend?

Answer 1

It seems like a very cumbersome process for the developers – they have
to test/push twice for each changeset.

Sounds like you don’t have much automation in place for pushing or testing. Once you have some automated tests in place, you could use tools like Go (full disclosure: I work there) to define different environments and model a workflow such that pushes to different environments happen automatically. It is great that you are pushing changes on a daily basis, you are likely to find lots of relevant advice in the continuous delivery book.