Software development is a complex process. Despite software engineering’s rapid evolution through easier-to-read and write programming languages, better development tools, and better project management approaches, errors in the code, or bugs, can happen and will happen.
Once it is accepted that bugs are inevitable, the question is not so much how to eliminate them from the start, but rather how to manage them in a manner that causes minimum disruption for the end user. That’s why software projects typically require several environments that directly correspond to the three key phases of the software development process. An unwritten law in software development is to never let untested changes get deployed to production.
These three phases of the software release process are:
And they are one of the most easily overlooked features in online application builders, even though their impact on the quality of and the continuous delivery of the application is tremendous.
In this blog post, we will take a closer look at the software release process, and how to deploy applications to development, testing, and production quickly.
Building software is more than checking code into a code repository. Having in place a develop-test-release pipeline is critical to delivering software to end-users successfully. Managing the software release process is an important part of a software development team’s job. Tools can help make this process more efficient.
Let’s begin by taking a closer look at the three most commonly used deployment environments in the software release process. Even though the three environments’ names are quite self-explanatory, it is worth taking a closer at each and its purpose:
The phase where code is written, bugs are fixed, and new features are implemented. This is the phase where software is actively being developed. This environment is sometimes also referred to as a sandbox.
Invisible to the end users, the testing or staging environment is where a system, once it has been built, is accessed by a team of testers. Staging should be a replica of the production stack, and it is where the software is thoroughly tested to ensure that it is functioning correctly and meets all requirements. Only if testing is passed successfully, should software be deployed to production.
The production environment is where end-users access an application. Deployment to production should only happen after an application has successfully passed the testing phase.
Setting up and maintaining these three environments may sound logical and easy enough. But there’s a lot more to it. For example, not everyone in a development team should have permission to deploy to production. Instead, there should be a gatekeeper, who manages and oversees deployment to production. This requires development teams to put in place access controls that secure the production environment and to make sure that deployment to production is authorized and audited.
Another challenge in managing environments is data & data access. For compliance reasons, developers should not have access to production data. But in order to test their application, they need to have access to production-like data. Ideally, the test environment comes with its own database, which is separate but similar to the production database.
As a side note, for most software development projects, development, testing, and production are enough to manage releases properly. In some enterprise cases, a fourth environment for User-Acceptance Testing (UAT) is required.
Sometimes we get asked if there is a difference between deploying and releasing software. Our response is that yes, there is a difference between the two.
You only release software (to end-users) when you deploy to production. As just explained, the production environment is where your end-users access your application, and software isn’t officially released until it’s running in a production environment.
Put differently, deploying software refers to shifting your software into any of the three environments: development, testing, or production. Releasing software refers to publishing your software (or changes to it) to your end-users by deploying it into production.
Most application builders have automated deployment features for developers. Developers can deploy their applications with a single click to the cloud and do not have to have cloud expertise to do so. Another advantage is that developers do not need to waste time setting up their environment. Everything is in place already, and they can go straight into the development of an application’s functional requirements.
But not all application builders give developers a full release cycle that incorporates the three stages of the software development lifecycle.
For example, in some application builders, developers do not have the option to deploy to development or testing. There is no sandbox environment. Instead, every change that they make to the application will be pushed straight into production. This can work but is generally not advisable. Admittedly, software testing is costly, time-consuming, and oftentimes, not the most exciting task. But not testing software is even more expensive and the risk of “breaking prod” is simply not a risk worth taking.
That’s why one thing to do before building software with a no-code, low-code, or any other online application builder is to check how many environments there are per application. If you only get one environment per application (which, by default, is where your end-users will access the application), don’t expect to build and maintain serious software.
Five has two kinds of guardrails in place that help development teams ensure only production-worthy changes reach the production environment.
First, for each application, Five provides a development, testing, and production environment. The development environment gives developers working in Five the chance to preview their applications. Each developer has their own development environment and they can deploy to their development environment without affecting anyone else’s work or experience on the application.
Once a production-worthy version of an application has been built, applications can be pushed into testing. Testing will not impact the production or development environment. And once an application has been tested, it can be pushed into production, all straight from inside Five, with only a single click.
Second, Five is designed to have a single gatekeeper to manage and oversee deployment to testing or production. By default, developers can only deploy to development, which reduces the risk of accidental commits that affect the end user in production. Admins, however, can deploy to production. This also means that engineers can focus on their primary responsibility: building new features for someone else to review them. The system takes care of the release cycle.
Last, web applications built with Five are hosted on AWS (note that in our free tier, you can only deploy your applications locally), using Kubernetes and Docker. When launching applications to production from inside of Five, developers do not need to install, operate, and scale their own cluster, as deployment is fully automated. The only choice developers make is right-sizing the underlying Virtual Machine that their application is running on (for their worker node). Inside Five, developers can select from AWS’ EC2 T3 instances, a low-cost burstable general-purpose instance type, and a cost-effective way to run general-purpose workloads in the cloud.
Using Five’s free tier (available for download on our website), developers can build applications locally for free. Only if they build something production-worthy, they deploy applications to production on the cloud, using Five’s paid plan. To get started today, simply visit Five, sign up for a free download, and start building!