Ten Ideas for Continuous Deployment in IT Areas in Any Company
Welcome to the Future
Over the past three or more years the whole approach to software installation and deployment have been transformed. Gone are the days of Operational Managers cracking the whip while production support engineers try to beat deadlines on manual installation of new software configurations or upgrading of existing installations.
Software tools which have been many years in the making are being investigated and deployed to help in software testing, software deployment. Automation of the configuration management of operating systems has become more easy with tools like Puppet and Chef. People have more time to design, plan and develop existing facilities to embrace new approaches, or do they?
Well, yes they can have more time. In 2016 these approaches are being rolled out across many organisations, so people are either exploring new options, running proof-of-concept systems, reviewing company culture with regard to software deployment and transforming their IT infrastructure.
How far have you travelled along this path? I set myself the task of listing ten ideas for each of the following areas that you may encounter. It’s not a complete list, but it will get you thinking. Good luck in your journey.
1. Reduce all software changes to small steps (incremental).
2. Move all code into git repositories.
3. Automate all software compilation via scripts for deployment.
4. Automate testing of software. This builds a group of tests which can be used at each upgrade automatically and quickly.
5. Set up dashboard status website for software testing status.
6. Script installation of new software.
7. Automate deployment of software to environments.
8. Development environment is snapshot of production environment.
9. Test and UAT (User Acceptance Test) environments are snapshots of production environments.
10. Customer code is protected by encryption in production and masked in other environments.
Operating system Environments
1. Operating systems are built as VM (Virtual Machine) servers (via VMWare, Docker, etc. or on facilities from Cloud providers like Rackspace, Amazon or Google).
2. System builds are automated via build parameters (e.g. Linux kickstart files) or disk images or scripted (e.g. Linux shell scripts or Windows PowerShell scripts).
3. System builds are saved via snapshots.
4. System upgrades are automated/scripted.
5. All changes are developed as deployment code held in git repositories.
6. Investigate use of scheduling of startup and shutdown of servers (like Google Kubernetes).
7. Introduce configuration management tools for operating systems like Puppet or Chef.
8. Establish virtual disk pool.
9. Manage network via virtual network connections and devices.
10. Reduce operating system versions to one (or maybe two temporarily).
1. Reduce database system versions to one (or maybe two temporarily).
2. Database builds are automated.
3. Database upgrades are automated.
4. Security upgrades are automated.
5. All build & upgrade scripts are code held in git repositories.
6. All configuration files are held in git code control repositories — for databases, listeners, etc.
7. All key customer data is encrypted.
8. Database snapshots with data masking are available to be delivered to development, test and UAT environments.
9. Investigate NoSQL databases for management of data load files if they exist.
10. Backups are incremental and fast.
Clusters for scaling and limiting downtime
1. Web server services can be clustered.
2. API services can be clustered/duplicated.
3. Database services can be clustered (think Oracle RAC).
4. Disk farm can be virtual disk farm built on multiple physical servers (or using SAN drives).
5. Upgrades can be rolled out on offline servers, allowing incremental upgrade of quorum of servers.
6. Cluster start-up and shutdown could be scheduled on larger applications.
7. Networks can have built in redundancy / bonding.
8. Power supplies can have built in redundancy/ reserves (e.g. UPS — Uninterruptible Power Supplies).
9. Network providers can be multiple to build in redundancy.
10. Use of multiple Data Centres can provide built-in redundancy for disaster avoidance.
Backup strategy /disaster recovery support
1. Fast full backup of servers (e.g. via EMC DataDomain).
2. Fast full backup of databases (via database backup agents).
3. Incremental backup of servers.
4. Incremental backup of databases.
5. Configuration Management of servers (e.g. Puppet, Chef).
6. Configuration Management of Databases (e.g. DBMaestro, Delphix).
7. Establish ability to shadow/switch services like API’s.
8. Set up standby databases for fast switchover / failover / distributing processing as needed (e.g. running reports and/or backup off online database).
9. Use of snapshotting (with and without masking) of databases (e.g. Delphix) for fast cloning.
10. Deployment of components, services using scripts from the code repository.
1. Accept the everyone can’t know everything about everything!
2. Break down silos of knowledge.
3. Encourage knowledge sharing, cooperation and teamwork.
4. Changes will reduce steps from development to deployment of changes in production.
5. Automation significantly reduces total time for software deployment.
6. Automation provides free time for design/peer review
7. Encourage people to explore new options by engagement with Change Management.
8. Reduce the number of manual steps required for software deployment
9. Reduce the number of overall steps required for software testing (see above)
10. Reduce the need for out of hours working (reducing staff costs)
There are so many areas that can be addressed, so it is going to be a learning curve for your organisation. However, by automating the software delivery the ‘software robots’ can assist you in streamlining the deployment of the software. Introducing new business changes is thus accelerated, bringing many benefits to your business.