Software Delivery 101 (Environments and Applications)
[Article 1 of 6 in series Software Delivery, DevOps and CICD for the uninitiated]
In this article, we will cover:
- the meaning of key terms such as environment, application, infrastructure
- the meaning of the term delivery and how it differs for customer-run and self-run applications
- the need for multiple consistent environments to support software delivery
Introduction
I’ve tried to make this article series as accessible as possible for people without significant experience with Software Development and Operations, whilst at the same time trying to ensure it’s also of use for those that do. This particular article is intended as a cheat-sheet for those in the former camp, covering some fairly basic principals necessary to get the most out of the series. Those in the latter camp are likely to already be familiar with the content, in which case you have my permission to skip ahead to the next article!
Quick Glossary
Tech vocabulary can be confusing when starting out.
- Many words mean one thing in real life, and another in tech
(e.g. ‘environment’, ‘application’) - A given thing can be described using a variety of words
(e.g. ‘server’, ‘box’, ‘machine’, ‘host’) - And a given word can often mean different things in different contexts
(e.g. ‘server’ meaning a ‘machine’, and ‘server’ meaning software acting as a service, such as a web server or application server)
So as to ensure we’re all on the same page, I want to quickly run through a few terms that will come up frequently in this article series.
Software / Program / Application
Computer programs (a.k.a Software) come in two forms:
- System software (interact with the computer at a low level; includes operating systems, compilers, and utilities for managing computer resources.)
- Application software (designed for use by and end-user, including databases programs, word processors and web browsers)
For consistency of language we will assume in this article series that we are creating an application, but the same principles apply.
Infrastructure
The set of IT components combined as the foundation for developing, testing, delivering, monitoring, controlling or supporting an IT service. This may be hardware (e.g. storage systems), system software (e.g. operating systems) and to some degree, application software (e.g. user authentication). A large area of infrastructure is Networking (e.g. switches, routers, cabling, firewall).
Servers
The term server has more than one, subtly different meaning:
- It can mean a software application which provides a service over a network connection to other computer programs (called ‘clients’) and their users.
- It can also mean the actual computer on which a server software application runs.
Servers are further examples of infrastructure.
Source code
The set of instructions and statements making up a program’s behavior, which are written in a computer programming language and which can be interpreted by a machine.
Build
Source code usually needs to undergo a process known as building so that it can be run as a software application. The meaning of ‘building’ differs from application to application. Examples include:
- code written in the programming language ‘C++’ needs to be ‘compiled’ into a ‘binary’ which can be run by an interpreter.
- code written in ‘Javascript’ will however ‘run’ just as it is in a web browser, but to optimise speed, it will usually undergo a process called ‘minification’ (i.e. compressing it right down to a smallest equivalent file) during the ‘build’ phase.
Environment
A computer system composed of infrastructure into which a computer program is deployed and executed. (See chapter below)
Deployment
The processes of getting new software or hardware up and running properly in its environment, including installation, configuration, running, testing etc.
Also known as ‘implementation’, and ‘delivery’.
Environments
The concept of an environment is particularly useful when the same application is deployed to different environments. The environments’ independence and isolation from one another creates opportunities to undertake different kinds of activities in each without one affecting the other.
In order to improve, fix or alter the behaviour of an application, developers will make changes to its code (or to its configuration). If the name of the environment in which these changes are originally made is the development environment, and the environment in which end users actually use the application is known as the production environment, then in a typical software delivery architecture, these environments are not only separate but also bookend several stages in between. New software releases are deployed to each environment in turn to facilitate phased release management, where at each phase software is rolled out, tested, and rolled back in case something goes wrong.
This language is particularly suited for server programs, where some or all code runs remotely on a server, over cases where all code runs only locally on an end user's device.
Development Machines
1 machine per developer: usually their own computer.
Developers obtain a copy of the application code and make changes to it here. They will also trial the changes they make by running the application, committing changes they’re happy with to be pushed on to the next environment.
Build (or ‘Integration’)
The completed work from all the project’s developers is combined here to be built. It is important that the builds that might be taken forward for testing or release all originate in a single, consistent environment (rather than from individual developer machines) so that the outputs are also consistent, and reproducible.
The build environment will be endowed with the tools it needs to conduct the build, as well as to run the built application, as builds will also undergo basic forms of testing here to ensure (to a simple degree) that the result works.
Test
Unsurprisingly, Test environments are for the purpose of testing the application’s behavior.
Many organisations might actually have more than one test environment, with each environment serving a different purposes/reflecting different stages. A very common strategy is:
- QA (or ‘Test’): The landing environment for new software releases. The organisation will run the majority of its tests here.
- Pre-production (or ‘UAT’, or ‘Staging’): The last post for releases before they go to Production. The releases here are kept stable. The environment might be exposed externally to Customers or Stakeholders for Acceptance testing.
Sometimes applications might have more than one type of target production environment (for example mobile apps which should support multiple versions of the Android operating system). In which case there should be distinct test environments for each target production environment.
Production
The final environment where finished software code is put into action in order to fulfill whatever purpose it has, and where it is used by the end user. In the production environment, the product has been delivered and needs to work flawlessly
(Note that a software development house producing applications to be run on customer devices might not actually have or manage a true production environment, but this does not obviate the need for all the previous environments described. See the Delivery chapter below.)
Environmental Consistency
Testing software in any environment other than the production environment would be futile if we didn’t have confidence that the application being tested will behave the same once in the production environment as it does where it is being tested.
The behaviour of any software depends heavily on the environment in which it is run. To draw an analogy, a trout from a river would behave very differently if it were put in a frying pan! The term ‘Environmental issues’ describes the situation where a software system exhibits unexpected or undesired behaviour as a result of factors outside the control of the application itself. Since the ‘environment’ is no single file, it is in fact made of operating system configurations, security policies, networks, hardware resources etc, ‘Environmental issues’ can be very difficult to identify. Investigation and resolution of such issues is expensive.
As such, it is important for us to find ways of ensuring as far as possible that all our environments are as similar to one another as possible.
Software Delivery and Types of applications
The meaning of ‘Software Delivery’ differs from application to application. I find it helpful to think of two main types:
Software run by customers
Some applications are obtained by customers from a source medium or repository (e.g. an installation disk, a website or an ‘app store’) and installed by them onto their own devices.
The organisation publishing the software does not have access to the devices on which the software runs and the set of devices, versions and environments on which the application may ultimately be installed may be quite varied. You
For the software house producing the application, they do not have a ‘production’ environment, and ‘delivery’ ultimately stops at making the finished product available to customers.
Software run by the publishers
Some software applications are built by (or at least commissioned by) an organisation with the intent that it is run exclusively by that organisation, e.g.:
- a bespoke internal tool designed specifically to help employees of the organisation with the particulars of their work
- a service run locally, but used by external users or systems (e.g. a website, the ‘backend’ of a mobile app, or a bank’s payment processing system)
The software needs to be run only on a defined and small number of servers/environments, and the organisation controls these. In this context, delivery means getting the application up and running on the servers or devices.
In the rest of the series we will assume we are delivering this type of software.
Products requiring both types
Many software products are actually comprised of a combination of the two types of application described above, with the each communicating over a common interface. This is known as the ‘client’-‘server’ model. Typically the ‘server’ is run by the publisher, and provides services over the internet to the ‘client’, which is run on a customer device. A mobile app which requires an internet connection to e.g. log-in, retrieve high scores or saved messages etc. is an example of this model in action.
Summary
In this article we explored some key concepts to help us with the rest of the series, such as:
- the meaning of terms like environment, application, infrastructure and delivery in various contexts
- the need for multiple environments in a software delivery workflow, an example flow and the need for consistency between environments