Qa supports infrastructure updates
Hello all. Need your input. Qa in our company does software testing to support all infrustructure changes. Network resources do the actual behind the scenes testing as Qa simply has no tools to test swiches, routers, firewalls, web servers. Our infrastructure has been in a bad shape and no telling when these weekly changes will stop but it looks like another 1.5 yr. to implement all desired changes.
Qa has very limited view in what is coming and often times it is an immediate request. It is commont to be testing software for the changes on the nights and on Sundays, when traffic is low. In fact a Sunday became a regular day for a QA tester. Tests often start at 6 or 7 am on Sundays. We need help. I dont think this is the right way to do things but our Network manager seems to be creating this schedule. What do you recommend?
I think the appeal for companies moving things to the cloud is to be able to swap out things out quickly for deployments.
Originally Posted by ekabeka27
So generally most production deployments on cloud will involve deploying a new instance on a "staging" environment which is identical to production. Testing happens in a staging cloud environment (which is generally invisible to the public unless they have the right hostnames and VPN access). Then on the date/time of the deploy, an Ops/Dev Ops person would just flip the VIPs and point the production domain to the staged instance, while switching the production instance to the staged environment. Run a few automated smoke tests to ensure that deployment worked, and ta-da! If something goes wrong, flip the VIPs back and you've done an effective roll back. Generally deployment switches happen so fast, it can be done on a lunch break with only fractional seconds of downtime.
For database changes, these are generally harder to do. A good way to do this is to use an ORM and factory methods for switching between backwards/forwards compatible data models based on schema connected to. Make the system forwards compatible and deploy the app first. Then in a later update when things are deemed stable, schedule a blackout window where write access to the database is disabled in order to copy the data to a migrated database. Then from there you can do a VIP switch. This deployment however will take longer and probably shouldn't be done on peak usage hours.
For companies not on the cloud. You'll probably either need redundant production VMs or full Servers to accommodate this.
Last edited by dlai; 01-26-2015 at 02:50 PM.
Tags for this Thread