System changes occur so quickly that upgrades and updates have to be unobtrusive and ready to hit the ground running.
The changing nature of application development necessitates new methods for ensuring updates and patches are deployed in near-real time via automated testing and validation. The challenge is to deploy apps in a way that doesn’t hinder users’ access to your organization’s vital applications. To do so, you have to think small, and you have to be ready to respond to feedback as quickly as you receive it.
It’s almost certain that whatever software components your new application needs have already been written. “Application development” is now a matter of putting pre-existing software pieces together in an intelligent, problem-solving, revenue-generating way, with little or no original coding required. Then all you need is the most efficient combination of compute cycles, storage, network bandwidth, and database elements to support your apps.
What matters as much as development these days is continuous, almost-instantaneous updates, so you’re in a near-constant state of deployment. The goal is to update in the background, and in a way that minimizes interference with users.
- Deployments: Small and focused
- Testing: Fast and well-defined
The foundation of modern app development is API- and service-based access to functionality: Code and configuration repositories, source code, and configuration versioning and controls are required for rapid, focused, compartmentalized deployment. One key to the success of your app-development project is to involve the “Ops” side of DevOps from the get-go. This way, the operations staff can help define the supportability, testing, management, and security of the services comprising your applications.
Updates will often add new fields, modify forms and reports, customize or enhance dashboards, even add new use cases to expand the potential user base for the application. All of these changes make the app more complex. They also have the potential to conflict with other infrastructure components, and they may hinder performance and usability.
You can’t always know what changes you’ll have to make to the app in the future to keep it up-to-date. You have to develop with flexibility in mind. When you take a no-code, low-code approach to app development, you’re better able to make alterations quickly and precisely, with minimal impact on users.
Streamline testing, but not too much!
Continuous deployment depends on two things: Determining the lowest level of test coverage necessary for each deployment, and choosing automated testing tools that you can trust to do the job. In a November 13, 2015, post on DZone’s DevOps Zone, Moritz Plessnig identifies three principal benefits of continuous deployment:
- Small, focused iterations are less likely to cause problems, and they’re also easier to troubleshoot.
- Frequent updates maintain momentum and give users a sense of the app progressing.
- Users get faster access to new features and are able to provide feedback quicker.
Continuous deployment moves changes through the deployment cycle automatically. Source: Yaniv Yehuda, via InfoQ
Plessnig considers three types of deployment tests to be indispensable:
- The smoke test simply confirms that the system functions as it was designed to function. You want to make sure the various components work as expected in the production environment, not just in a simulated testbed.
- Happy path story testing ensures that the sequence of actions users typically step through to complete a task operate as expected. Examples are the sign-in process, order entry, and product purchase. You have to test the “happy path” for each of these “user stories,” according to Plessnig. As with smoke tests, the happy path test must use production code and run in a production environment.
- Integration testing verifies the application’s boundaries. It can take the place of unit testing, generative testing, mutation testing, and other traditional developer-focused tests. For example, classes and modules may run without a hitch in an isolated test environment but clash when they’re connected to a database, file system, or other external component.
Puppet adapts readily to changes in your infrastructure
One of the most popular ways to keep tabs on the configuration of your Linux servers is Puppet, which is available in both open-source and commercial versions. As reported in a November 25, 2015, article in Linux Journal, after you define the state of your IT infrastructure, Puppet enforces that state across OSes; physical, virtual, and cloud environments; network and storage devices; and applications. This includes initial code development, testing, production release, and updates; as well as provisioning of physical and virtual machines, orchestration, and reporting.
In the Puppet workflow, the agent collects information about the host and sends it to the server; the parser compiles an implementation for the host and returns it to the agent; and then the agent applies the configuration locally. Source: Luke Kanies, via Aosabook.org
The new Puppet Application Orchestration App is intended to serve as the single method for updating all of your application’s deployment tiers: from the application layer through all the infrastructure layers it supports. This lets you model distributed applications as Puppet code to take advantage of Puppet’s declarative model-based design. More than 3,500 Puppet modules are available for assembly into full models of distributed applications.