When we develop a software (a mobile app or a Web service), we need to manage versions. First, we create the first development version which can become an alpha version (the version that’s going to be used by some very early stage users), then we create a beta version, and finally move the product into the production stage.
All that management takes a lot of time. Previously, when we wanted to update a website, we would have to connect via an FTP or maybe SSH or STP connection, and upload the application files. Usually, it only takes few minutes.
But when we move to the growing stage, the amount of time we need to do a deployment becomes overwhelming (when we find a new bug or when we need to roll back and get back to the previous version, etc.). Having an automated deployment saves a bunch of time especially for startups because we need to reiterate very, very fast.
So, before we start, what are the requirements?
The requirement to have an automated deployment is by having a centralized development source code repository. The repository may be a Git service like Bitbucket, GitHub or Beanstalk. It’s a centralized place where all your developers (or maybe just you) centralize their source code. And when you have that set up, it allows you to manage deployment from the centralized place, from the repository. So having this repository is a primary requirement.
The second requirement is to have a deployment server or deployment machine. This may only be your own computer, but I recommend having a server on your data center or at least a very small virtual machine that’s going to allow you to run deployment from. This is going to make the entire process much faster, especially if your application becomes bigger and if you have more data to deploy.
Those are the two requirements. Now, what is the workflow? How does it work?
An automated deployment gets the source code from the repository. Then you need to manage and compile the configuration files for your targeted environment. If you have two, three or four environments, that also means that you’re going to have two, three or four file configurations but also two, three or four database access, Amazon S3 access keys, SMTP configurations, domain name configurations, etc. So, a bunch of configuration parameters that usually come in a configuration file in your application need to be adapted to each environment. To save yourself a ton of time, you need to manage this kind of configuration automatically. The automated configuration is going to allow you to deploy each environment in an easy and smooth way.
This is how it works: it gets the information from the repository, it compiles the configuration files, and then it needs to deploy and push the application to the server. This point is going to be dependent on what kind of infrastructure you have.
The deployment process really depends on which kind of infrastructure you are using. It might be a single server, it might be on services like Elastic Beanstalk which is going to automatically deploy the new version on each and every server. If you only have a service or maybe a hosted service with a simple FTP access, that will work too. You can just set up a deployment script that’s going to push your new version, your configuration files, up to date to the dedicated environment and just update your service.
The best thing about this is the fact that when you have an automated deployment, you also back up and save automatically each and every version that you deploy. And that’s a huge security advantage.
The real security advantage when you use automated deployment is to be able to control, to deploy easily and rapidly, and to roll back to your previous version. Every time you run a deployment, every time you compile on a new environment, you save the previous version and you deploy the new version. But if you find out later that you have a bug on your new version or that there is something wrong, it’s going to be easy and very quick for you to revert and to come back to the previous version. This is the best way to manage your software update.
It’s just a matter of a few simple steps. The first step is having a common repository, and then having a specific configuration for each environment. The configuration can be a dedicated config file. It can also be something a bit more complex with a search and replace system that’s going to apply to your source code.
Let’s take Symfony as an example. Symfony is a framework of PHP. The configuration files of Symfony are also saved under the repository. But if you take a closer look at these files, you’re going to see that inside, the parameters are not real. But you have some values between percentage sign: %databasename%. This is a kind of files that’s done and created for automated deployment, and it allows you on the deployment script to search and replace some parameters with the real value. The real value might be some database connection, some application URL and so on.
When you have this file on your repository, you need to have someone who does a bit of script. The scripting is almost something that every startup needs to go through and it’s something that I often do for my customers. A ten-line script in some cases is enough to have an automated deployment script ready to use and save hundreds of hours.
The last step, which is not a requirement but something that is easy to do, is to have a user interface to manage your deployment.
For user interface, you have several options. One popular option is by using a software called Jenkins. Jenkins allows you to configure the automated deployment and to launch your own script through a Web interface. It’s an easy and nice approach to test.
So first, what I recommend is to create your deployment script, move forward, and once you have the time, set up Jenkins or another software user interface.
You can also manage the automated deployment by hosting services like AWS CodeDeploy. CodeDeploy is quite easy and useful because it allows your developer to run some deployment even from their Bitbucket console. I set up this kind of configuration for some customers. It’s very easy and practical.
Another solution that I’ve tested is using Beanstalk features. It also allows you to run deployment through SSH script that’s going to run some command line and deploy your new version. The drawback of using Beanstalk is the fact that it’s more complicated to manage the version that you want to deploy. In some cases, you’re going to need to do a rollback and get back to your previous version. It’s not as easy as a simple deployment. You need to set up which version you want to deploy and maybe use a branch dedicated to it.
If you want to learn more, check out our other article that talks about how to manage versions and how a developer should work which is related to versioning and managing branches in a repository.
For deployment and infrastructure, check out our article on what kind of infrastructure should your startup go for. It will give you some insight on the alternatives that you have if you want to have an availability infrastructure.
And if you’re just starting to build your startup, feel free to get your FREE ACCESS to The Startup Journey Course to find out what decisions you need to make to save you time, effort and money before you even begin.
So, do you have any questions about what we’ve discussed above? What are your current goals? What do you want to achieve with this kind of deployment? Are you are a technical person? Let us know below.