For smaller businesses, responsible deployment is difficult. Generally it is a series of local tests, a test on a remote server and then locally building it and pushing it to another server via sFTP or some other method. People often use “Continuous Integration” in their check-ins to a development branch, where it runs the site through a series of pre-programmed test routines, but that’s actually pretty hard to do efficiently when you’re a small shop with a high workload doing very complex systems. But I’ve used Continuous Deployment for years, where if the site compiles on that branch, it gets pushed to a server.
Now it’s even better with Azure Static Web Apps
The functional process is pretty simple. We have 3 primary branches: Development, Beta, and Production. Every check-in to a branch results in the code from that branch being called from Azure’s build tool for Static Web Apps. Then compiled and pushed live.
The “business” process is also simple. Every code change gets checked in to development. One guy may be working on that branch directly and anyone working on a feature has their own branch, which they merge into master as often as possible, just to ensure the code bases stay close. Each checking to Development branch pushes is to the dev server and we KNOW it compiles. We can have QA run directly on a copy of the live site whenever we want.
For releases, the QA lead will add a “tag” where he is going to start QA. At that point people can keep going on development. If it passes QA, then they can merge it to beta from that tag and checkin that merge. it will automatically build it and push the newly QA’d site to the beta server. Azure ensures there is zero interuption in service.
We will then wait for the client to use it for a while and any bugs found will be made with a hot-fix. The developer with the bug will create a new branch called “hotfix/{ticket-id}” from BETA branch, do the fix, test it out locally, then merge it into master. If it merges well and there are no problems, then they merge it into the Beta branch and check it int. That will automatically build it and people using the beta server will see the change.
If a bug makes it through to production and we need a hotfix for that, a similar process is followed. A branch is made from the production site, the change is implemented and made sure it works on production, then it is merged into the Development branch and if it works, checked in. then it is merged into beta, and if it works, checked in. then it is merged into production and if it works (which is should, since that’s the base of the hotifx) then it is checked-in.
The business process is what makes this work, not the continuous deployment. However, continuous deployment makes it easier to manage.
now…. how about roll backs? That’s not actually “too bad”, but it is still a pain and I’d like a better solution:
In the past, I’d simply do git checkout tags/xyx (I use tags for releases), then build it and then push the build. But, with continous deployment, it’s not “quite” so easy.
Here’s the process:
1. do the checkout of your tag. eg: checkout tags/v3.2.1
2. generate a new branch eg: git checkout -b rollback-to-v3.2.1
3. modify your yml release script to use rollback-to-v3.2.1 as the branch
4. check-in that change.
5. push that branch to the source control server: eg. git push origin rollback-to-v3.2.1
That will reset it to v3.2.1
