Installation Automation - How Much is Enough?

In a previous post , I addressed the importance of keeping all of the testing environments as similar to the Production environment as possible. I mentioned that the install should be fully automated - but the question might arise, how much automation is enough? Let's consider this question now: As Martin Fowler states : "You’re doing continuous delivery when… You can perform push-button deployments of any version of the software to any environment on demand. " Having the ability to quickly and easily deploy your software with the push of a button is key to achieving Continuous Delivery, but oftentimes people will balk at automating all aspects of an install process. How much can really be automated, they ask; there are some things that we need to do by hand, they often say. I disagree. If you aren't physically installing a piece of hardware into a box, then your tasks should, and can, be automated.

When installing applications, the environment is vital to the process to ensure that all tests are being run on all systems with the same framework. Being able to accurately identify what is in the environment is key to having consistent testing environments from Development all the way through to Production. Identifying what makes up the environment, all of the tools installed, environment variables set, and so on, will also be important when creating a Bill of Materials (BOM) if it's needed. The creation of, and all changes to, the environment should be automated whenever possible - this might include changes to environment variables, installing new software packages or patches, and so on. Obviously hardware changes cannot be automated through scripts, but all other changes can be scripted or programmed. The automation should be done such that it is flexible enough to run all possible environments which may be used in the testing of the application. By using the same automation flow throughout the process, the installation scripts can be thoroughly tested before it reaches the Production system.

As the Release process progresses through various testing stages, each set of testing environments will have different configuration information. This information might include IP addresses, hostnames, and other data that is specific to a single environment. This information can be stored in a file that can be stored in a Software Configuration Management (SCM) system. Storing it in the SCM system allows changes to be tracked and monitored. Using the Configuration file that gets parsed at installation time, allows the installation to be configurable for multiple environments, as each environment can have its own configuration file, or there can be appropriate entries in the configuration file for all applicable environments. There are multiple environments that can be configured: Not just the various types of environments (Development, QA, Staging, and so on), but in many cases multiple machines in each of these environments, as well as multiple instances of these different environments (there could be dozens of Development testing environments, several sets of QA testing environments, etc.). Because of the multitude of environments and machines that need to be configured and managed, it is vital to have a way to manage these configurations. Storing the configuration files in your SCM tool helps with tracking changes to the various files. In addition, It is also important to have the tools to manage these environment configurations, as often times an installation environment is comprised of multiple machines (Web Server, Application Server, Database Server and so on). The Deploy functionality in CloudBees Flow has the capability to manage multiple types of deployments, and multiple instances of the various environments needed for your Release Pipeline. It can also be used to create and tear down instances of various Virtual environments, allowing your testing systems to be flexible and adaptable.

Implementing an automated installation solution for the applications and other components being released is becoming increasingly essential to creating a smooth and reliable Release Process. All aspects of the installation should be automated, to include uploading the applications, running the installation, and restarting any necessary services. By automating all of these, you can increase reliability, repeatability, and it will allow others to identify exactly what is needed for each release (also useful for a BOM). Another common anti-pattern is “deploying to a production-like environment only after development is complete.” This means there can be almost no confidence that a particular software release will work successfully for end users if it has never been tested in a copy of production. It is important that the automation be used throughout the entire Development process , on all testing environments. This ensures that it is tested before it reaches the Production environments. The more automated the process is, the easier it will be for everyone throughout the Development lifecycle to perform the necessary installation tasks. UsingCloudBees Flow Deploy , it is possible to set up complex installations on multiple servers. Servers can be provisioned and software deployed as needed, with the push of a button.

Virtual Environments allow you to spin up environments as needed. CloudBees Flow's Dynamic Environments features allows you to create, configure, and save virtual environments for future testing needs. This can be especially effective for spinning up new testing environments, and also for documenting what the exact environment contains for a specific release. This can be vital later on, if the environment is needed to reproduce an issue found once it is in Production. Snapshots of environments can be used to create the necessary testing environments at the various phases of the release process. By using virtual environments, QA Engineers can be sure that the environments they are testing on have not been modified, because they can simply spin up fresh environments. However, using virtual environments in the testing phase, if they are not used in Production, creates risks that need to be evaluated. There could be potential issues found on physical hardware that cannot be found in virtual environments. So that still leaves us with the question: How much automation is enough? You want to aim for very little to no human interaction during an installation, everything should be automated in some fashion. The less human interaction that happens during an installation, the less chance there is for errors to occur, and the greater your ability to perform that push-button installation that Martin Fowler refers to. The more scripts, configuration files, and other files that are used, these files can be tracked in SCM systems. By using automation tools, it frees up the time of the engineers to concentrate on things other than the installation of the applications, and less time is spent resolving problems arising from installations.