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.
These three phases of the software development process, or the software development lifecycle (SDLC), are:
- Development,
- Testing (also referred to as staging), and
- Production.
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.
Development, Testing, And Production
Building software is more than checking in code into a code repository. Having in place a develop-test-release pipeline is critical to delivering software to end-user successfully. And even though the three environments' names are quite self-explanatory, it is worth taking a closer at each and its purpose:
Development
The phase where code is written, bugs are fixed and new features are implemented. This is the phase where software is actively being developed.
Testing (Or Staging)
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.
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.
Single-Click Deployment In Low-Code Application Builders
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.
Application Deployment & Release Management In Five
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, 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.
Get Started Today
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 the cloud, using Five's paid plan. To get started today, simply visit Five, sign up for a free download and start building!
Oldest comments (0)