We’ve been getting several requests about the best way to use GitHub with scriptr.io, so we decided to write this post to describe, with a practical example, the easiest release cycle that you can adopt. So here we go…
Let’s assume we are working on an app called myApp, and we’re currently developing a new feature called feature A. In the remainder of this article I’m going to show the steps required to release feature A to production.
First, we have to start by creating a repository called myApp. For the sake of this example, we are going to start off with 3 branches, which is the minimum required number of branches for a complete release cycle:
- Master branch: this is the production branch, so any production-ready code belongs there.
- Staging branch: a branch that has everything that is to be deployed next to production, it should always be ahead of the production branch.
- FeatureA branch: every change/feature you’d like to do to the master branch should have a branch of its own. So let’s say you are adding feature A, your branch should be featureA; if you are adding feature B, you create another branch called featureB; if you are fixing a bug, you create a branch called bug-ID; and so on… Once you finish coding and you’re ready to deploy, you can merge featureA or featureB or whatever you want as I’ll later describe in this tutorial. In short, you should have a separate branch for each change to be done to the production branch, and then merge them later.
On the scriptr.io side, we recommend creating, at least, 3 accounts:
- Production account: we want to setup our scriptr.io production account to be linked to the master branch. So, as you can see in the screenshot below, the master branch is now linked to our production scriptr.io account with automatic deployment enabled. You can enable purge or not based on whether or not you want files that are not on your master branch to be deleted from your scriptr.io account when you deploy (in my case, I don’t want to lose my files, so I haven’t enabled the Automatic Deployment feature).
- Staging account: you’d also want to setup a staging scriptr.io account and link it to your staging branch in a similar fashion.
- Development account: you’re going to need an account to link it to the featureA branch in order to test your changes as you develop.
So we got our production, staging and development branches all setup and linked to our scriptr.io accounts. Once the feature is complete and it’s time to deploy it to production, commit your change to the featureA branch, and make sure to add @AUTO-DEPLOY to the commit message, else this change will not be automatically deployed. To do this, you need to create a pull request (a pull request represents a set of changes that you wish to commit to a branch).
First, start by creating a pull request to the staging branch by clicking on New pull request then selecting the staging branch. This will trigger an automatic deployment to your staging scriptr.io account because you have the @AUTO-DEPLOY in a commit message of one of the files that you committed earlier.
Now that feature A is deployed to the staging account, it would be a good idea for you to run your automated tests on the staging scriptr.io account. This will allow you to make sure you did not make any mistakes when merging the code, and to make sure that all the code you merged from the different development branches don’t conflict or negatively impact each other logically.
Once your automated tests pass, you can go ahead and merge the staging and production branches. For that, you do another pull request from staging to production. This will trigger a full deployment to all the code on the master branch to your production scriptr.io account. So if anything was modified straight on the scriptr.io account, it will be overwritten.
After the full deployment is complete, run any automated tests that you need to run on the production account and you’re done!
Don’t forget that you can always contact our support team with any inquiries on firstname.lastname@example.org.