I am always thrilled to find out how people are using our platform and its new features. It is a rare sense of fulfillment to discover that what you are doing is actually useful. 🙂
Today, I was having a chat with our long time customer and supporter Giuseppe Aiello from fleka.me, a Montenegrin/Italian design studio specialized in web and mobile. We were discussing about our recently launched Git integration and how they are using it.
We designed our Git approach in a way that it didn’t force any specific workflow on developers and was very flexible to adapt to different needs. At a very high level, you just need to generate an SSH key pair from our console and a Git repository that supports SSH access (i.e. Github, Bitbucket, etc.). You then link an application in any of your servers with a specific Git repo and branch and you can deploy code with a single click from Cloudways Cloud Console.
Now if you mix this with our application clone feature, or even server clone feature you open the door to a lot of very interesting possibilities to create a development workflow that adapts to your own or your company’s way of doing things.
But going back to Giuseppe and our conversation today, let’s see how they are using it:
- For each application that they deploy on a server, they keep three application clones: Dev, Test, and Live.
- They use bitbucket as a git repository. Using Deployment via Git feature, they link each clone to a branch of the Bitbucket Git repository. i.e. Live application linked to the master branch, Dev application to the dev branch and of course Test application to the test branch. They sometimes even create additional application clones for developers working on special stuff, i.e. Mario application linked to mario-amazing-new-feature branch.
- They follow the dev -> test -> live workflow as per the Github flow style, i.e. anything in the master branch is deployable.
And, that’s it!. Simple, yet very effective.
Now, what Giuseppe doesn’t like is that as you need to push a button in the Cloudways Cloud Console to deploy to an specific app. For this, he has to give his developers full access of the console. We understand that. Luckily we will be releasing a Team’s feature pretty soon (hopefully, August), through which you will be able to give fine-grained access (i.e. to an specific server) to anyone you want. It can be a customer, developer, or designer.
Another thing that Giuseppe would like to see is automatic deployments via post hooks, so that code is automatically deployed to an specific application on a Cloudways server when pushed by a developer to an specific branch in a Git repository (i.e. Bitbucket). This would avoid the need to login into Cloudways account and click the deploy button manually. Again a very interesting idea that is on our road map.
Finally, we discussed database changes. Once you do the initial clone of an application, database changes on the source app are not replicated to the cloned app. We did this on purpose as cloning can be used for a number of reasons and we didn’t want to add unnecessary features that would clutter our polished interface.
Giuseppe agrees with us here and he solves this very easily. As we offer a database manager integrated with our console, when he really needs the dev database to be synced with live, he just dumps the database via the database manager from live and restores to test. I understand that some people would like this to be a more automated process. Let me know your thoughts and we will see what can be done.
And, this is just an example of a development workflow that can be built with Cloudways amazing set of tools. If you are using some other approach and would like to share, feel free to contact me at email@example.com. Otherwise, if you have new ideas or features related to all this that you would like to see implemented, do drop us a line on our Uservoice page.