This post is the twenty-fourth part of a ramble-rant about the software business. The current posts in this series are:
This post is about ALM tiers in the software development enterprise.
In a software development enterprise, there exist one or more Application Lifecycle Management (ALM) tiers. In this post I examine the purpose of some tiers.
An Ideal ALM
Ideally, your workplace follows the best practice of providing several isolated tiers for software development. Some have two tiers, I've seen as many as eight tiers. In general, more tiers equals better software quality as measured in fewer bugs.
Remember: All software is tested; some intentionally. You can test your software intentionally in one or more ALM tiers, or you soon-to-be-former-largest-customer can test it for you in Production.
Development is the tier where developers and analysts should have free reign. For developers, it's often called a sandbox because developers play there. I often request lots of storage for the Development tier because developers sometimes require their own personal copy of the data to play around with. Software is built and unit-tested on the Development tier.
Software is then promoted to the Integration tier. Thiis is a great opportunity to package up the application and data for deployment. Why? Deployment testing is also important. If you have four tiers like the ALM shown in An Ideal ALM, you get three deployments between tiers - and one of those is to Production. That means you need to test deployment between Development and Integration, and validate deployment between Integration and Quality. The deployment to Production shouldn't be a test, and it should never be the first time you execute a deployment procedure. In the field of software development, little sucks as much as rolling back 40 hours into a 48-hour deployment weekend because "something failed".
Integration is where the pieces are assembled and executed together for the first time. Ideally, the conditions on the Integration tier are as close to Production as possible. The contrast between Development and Integration is troublesome to most developers. The juxtaposition just bugs them: They came out of the wide open wild west and into some environment where people want to lock them down. There is natural resistance and the tendency to think (if not say) "What's the big deal? We'll fix it before it goes to Production."
This is a big deal. This is the first step out of the Developer-realm and into the non-Developer realm. Control has left the building. Your baby now belongs to the dingos. I don't know another way to say it - it's over; shipping has started. This is not to say there aren't exceptions. There are exceptions but they should remain precisely that: exceptions.
One more thing about Integration: It's the first testing enviironment. Pop quiz! How do you know you have a testing environment? Answer: In a testing environment, failed tests are ok. Scratch that, they're more than ok. Failed tests are a reason to celebrate. You just removed a bug from the code! If you are testing and someone fusses at you for failed tests, you are not testing.
Quality or Quality Assurance is for validation. The kinks should be worked out, tests successfully completed. This is the place for customer testing, a dry run for Production. Security - which should be in place in Integration - matches the Production environment and is verified in Quality.
Unlike Integration, failed tests in Quality are bad. It means something was missed in either Development or Integration. Failed tests aren't as bad as discovering bugs after the solution is deployed. But this is not the time and place in the project you want to discover flaws.
Quality should be a close copy of Production. If Quality doesn't duplicate Production, you lose the abilty to conduct accurate Performance testing.
Production is the big cheese, the whole enchilada; where money is made or customers lost. Most enterprises get it and spend enough money on their Production environments. Production must perform now, and optimally be sized for future growth. Exactly how a solution will scale is often unpredictable; and how a system scales will definitely impact performance. Since this is unpredictable, it's a good idea to have more server than you need.
A Typical ALM
In an age of bootstrapping and diminishing budgets, you may find yourself working in a less-than-ideal ALM. All is not lost. You can still practice good software development.
If your environment resembles a Typical ALM more than an Ideal, you can still crank out the code.
Good software doesn't write itself of happen by accident. A pragmatic infrastructure combined with best practices is the way to go.