All geek questions in one place

Deployment Workflow

I am currently managing live web application development. There are two developers. We strive to define a workflow that determines how assemblies and deployments should be performed.

We are currently using codebaseHQ for version control.

That's what I think:

  • Dev1 and Dev 2 receive and commit changes to the same repository in CodeBaseHQ.
  • We send updates from codebaseHQ to alpha.domain.com, which is separated from the production database for initial testing.
  • Assuming the tests run well, merge the changes into beta.domain.com, which is linked to the production database for further testing.
  • Assuming these tests are going well, team up on domain.com (production).

Does this sound normal? For developers, this is a very cumbersome process - they have to test / click twice for each set of changes. With rare updates, this seems tolerable, but if we push the changes daily, what would you recommend?

+4
source share
2 answers

This seems to be a very cumbersome process for developers - they have to test / click twice for each set of changes.

It looks like you do not have much automation for pushing or testing. After you run automated tests, you can use tools like Go (full disclosure: I work there) to define different environments and model a workflow that automatically switches to different environments. It’s great that you push the changes daily, you will probably find many relevant recommendations in the continuous delivery of the book .

+1
source

I really hate the idea of ​​promoting source code to promote functions to production. I am a big fan of promoting builds through the environment (I think Bagheera too, as we are competitors).

Get the “build”, whether it is a compiled or just a package, and promote this package through the environment using scripts or a tool.

0
source

Source: https://habr.com/ru/post/1441311/

More articles:


All Articles