Torbz - Fotolia

Tip

Improve the rapid application development model for deployment readiness

Get a better understanding of the top three areas in IT to improve a rapid application development model. Expert Tom Nolle discusses the future of RAD and DevOps.

Tom Nolle
By
Published: 15 May 2018

The rapid application development model aims for accurate deployments, as does DevOps as an IT methodology. It would seem the two concepts are natural partners, but that's not always the case. Development and operations specialists have to work to unite RAD and DevOps, or risk devaluing both.

RAD, which is a version of Continuous development, creates an efficient pipeline for changes to travel from development into production. As software complexities increase, and the possible deployment platforms for a program multiply, the build and deploy process can introduce risks and errors. DevOps tools, designed to orchestrate app configuration in deployment and updates, can overcome these problems. When a rapid application development model meets DevOps configuration and deployment automation practices, the common sticking point is a difference between the test and production environments. The pipeline that combines RAD and DevOps should be vetted and tested.

Development and testing usually occur in specialized sandboxes that bear little resemblance to actual production resources. That makes it difficult, or impossible, to accurately test code deployment and update scenarios until late in the development flow -- often not until pilot testing.

Build a better RAD model

A working rapid application development model in today's IT world demands three things:

  1. Development must take place in a sandbox that is protected from production contamination, but still mimics the real production environment.
  2. DevOps tools used for production deployment must also enable RAD testing flows.
  3. Operations feedback must be injected in development practices to reflect the first two requirements.

Enterprises could build consistent, production-mirror sandboxes for applications' every development and testing step, with the same kind of hosting or cloud resources. It would ensure accurate tests and faster development. However, in real practice, it is inconvenient to create such complex and large-scale production-like resources. Furthermore, it risks a leak between testing and production that allows untested versions to emerge into real use.

While the cloud is both a critical target for rapid application development and a critical platform to host development as a service, it's unlikely that many enterprises could build a series of consistently hosted sandboxes leading to production. Another strategy is needed.

Containers for RAD

Containers can address the three aforementioned conditions with the rapid application development model. Containers and container orchestration add abstraction that reduces differences between development and testing sandboxes and production. Adding containers to applications opens two possible pathways to unite DevOps with a rapid application development model. The first is to integrate DevOps with container-based RAD, and the second is to integrate container deployment to RAD tools -- essentially, replacing DevOps with container orchestration. The difference in these approaches is their foundation, one of which might be easier for a given organization than the other: Adapt the DevOps pipeline, or adapt the rapid application development tools.

Test data with DevOps and RAD

Whatever approach you use to integrate DevOps and rapid application development, don't forget about test data. It's crucial to test each change in a close simulation of real production, at least at the predeployment phase of testing. Test data injection at scale, from distributed sources, will be essential in validating changes and making sure your deployments really work in the environment in which they're going to be used.

Major DevOps tools have plug-ins or extensions for container deployment, but large-scale container adopters argue that traditional DevOps isn't the best method for container orchestration. DevOps tools are rooted in how to configure applications more than how to deploy or redeploy them. It is difficult to use imperative (script-based) DevOps tools in a configuration-independent manner. Declarative automation tools are more easily adapted to the rapid application development model, particularly if you invoke container orchestration via a plug-in rather than try to mimic it. The configuration and provisioning automation tool, therefore, stays at the declarative level, and the same DevOps models can be used through the entire application development flow.

An increasing number of enterprises adapt rapid application development tools rather than reworking their DevOps toolchain. Kubernetes, Marathon and other container orchestration platforms easily combine with continuous integration tools such as Jenkins to make every stage of rapid development, from unit testing through production, part of an explicit flow. The move from idea to prototype is defined in rapid development terms, using rapid development tools.

Jenkins, Buildbot, CruiseControl and similar tools frame production as a stage of rapid or continuous development. At each stage, they link to container orchestration for deployment. Simply hosting application code in containers does not guarantee that the orchestration practices for each stage will be comparable, but it does organize the process overall. Containers, and a single orchestration tool, provide commonality across all stages of rapid application development to ensure that every stage is tested, including the transition to production..

The rapid application development model, in both setups, is a string of testing and integration phases linked together. Examine if it's logical to think of this pipeline as the central framework for rapid application development. If so, then base the integration of DevOps and rapid development on the pipeline, which means on rapid development tools. If the process is seen more as deployment-centric, as it might be if the majority of software is purchased rather than programmed in-house, then using DevOps configuration and provisioning automation as the foundation makes more sense.

Dig Deeper on Agile, DevOps and software development methodologies