According to the requirements, we need to build and deploy a new code automatically for dev & stg.
But Prod will be deployed manually after tests performing on dev & stg.
Git pull schedule
We’ll use cron to schedule git pull actions with different schedule for dev & stg.
To manage this we’ll use separate files with schedule for dev & stg:
If git pull action brings to us some changes we need to start build & deploy.
If there’re no changes after git pull – just do nothing.
To manage this we’ll use git hooks feature:
Restore in case of failure
If deploy fails, f.e. because of build or deploy errors we’ll switch to previous version automatically:
While restoring procedure we need to use the previous version of git, and it can be done like this:
And during deploy we need to be sure that we’re working with an actual git version:
And here’s a case for you: we’ve received a bad code with git pull, deployed it, found an issue and restored the previous version from git.
While devs team is fixing errors the bad code will be deployed automatically because of git pull, than restored automatically, and so on in cycle.
To manage this, we need to disable git pull schedule in restore procedure and enable it back during the next deploy procedure.
That’s why, after restoring, next deploy won’t happen automatically, we’ll need to run it manually.
And of course dev mustn’t affect stg and visa versa, so no “crontab -r” actions.
It’s easy to do using action condition:
Just imagine – dev lead asks you “Which app version are we using on stg right now?”
It might be confusing, especially if you don’t have strong deploy policies, you need some time to figure it out.
And what if you’re responsible for dozen of apps?
I give you a simple solution: use git commits & messages to tag ElasticBeanstalk.
Devs are familiar with git, and if you’re able to grant access for devs to ElasticBeanstalk they will be able to see EB tags.
And it’s so easy to implement: