I have to deploy two different apps hosted in PythonAnyWhere (prod and stage) based on the same master branch. What we use to do is, first manually deploy the app that lives in the stage environment, test it and then we deploy (manually) the app the lives in the production environment. Both use the same code as I said. I want to integrate CircleCI to automate the CD process but I am not sure if I can have some way establish something like a condition for deploying sometimes prod and sometimes stage.
I see that we can use conditionals as a configuration in the yaml file, but I am not sure if can work in this case.
There are at least 3 ways to have a single config.yml operate so that it can handle different deployment targets
push to branch - so you have dedicated prod and stage branches that you place code into when you want the build to take place.
tags - you place a tag on the commit that you want cirecleci to process. The tag can then be given a name to indicate what you what the script to do.
use the API to start a script while also being able to pass parameters to the script. This solution would normally be used if you have a lot of automation in place.
Out of these 3 I think the use of tags is the most common - or at least many people have posted questions about how to get it working. A simple example of the structure would be
In this example, a tag of 123ad3.ci-staging would cause a staging build while 123ad3.ci-prod would cause the production build. The filter can be anything you want, but as tags within the system must be unique we decided to just use the commit ID.
Thank you so much for replied. So let me understand, I can configure the automation to deploy the code each time I create a tag on gitHub? I mean, I can marge many branches as I want into master but the source code will be deployed only when I introduce a tag.
Yes, that is correct. When you switch to using tags circleci will no longer start a job if the branch changes. Every commit to the branch will result in an entry into the circleci dashboard, but with the status of ‘created’ and ‘no workflow’. Only a tag that matches the filter will cause a workflow to be started.
The other thing to note is that once you are using tags, the build process can be started by tagging any branch. This may mean you end up changing your workflow as it allows you to have circleci process any feature branch that is tagged.