By: Jason E Bacani
Follow @JEBacaniSQLDude
Thank you for stopping by and checking out this blog post. We are starting a new series of blog entries, called Tales from Consulting, that will cover experiences, success stories, and lessons learned.
Topics will include working with development and production environments, software development life cycles, deployment methodologies, using source control, general best practices, and other anecdotal experiences. We will also write about challenges faced and “wins” achieved.
For our very first Tale from Consulting, we are going to talk about working with development and production environments.
The 4 Environments
As a consultant for Key2 Consulting for nearly 8 years now (plus many years working in IT beforehand), I’ve had the opportunity to work with many development teams that worked with various types of development and production environments. As a consultant and developer, I develop and produce code that is ultimately promoted to a production environment.
The production environment is what our clients are paying us to create, and it is where our solution is actually put into operation for its intended use by the end users. All other environments are used to support producing a functioning (as intended and designed) bug-free solution.
The development process creates source code, and this code is created and tested outside of production. This is very important because the temptation to expedite the development process will tempt teams to develop directly in production, which must be avoided! As the code moves through the various states of development and testing, it is eventually considered valid to be deployed, at which point it is released into production.
If you are unfamiliar with the code deployment process, you can think of it as being similar to mobile phone application updates, desktop operating system updates, and even video game updates that fix bugs or enhance a game. All of those updates (code) are created outside of the production environment. And once completed, those changes are introduced to production as updates.
But why do we have these separate environments in the first place? And how many “environments” should exist?
Let’s answer the second question first. There are many different ways to manage the development process, and in this blog we’ll be discussing four environments: Production, Test / UAT / QA, Development, and Sandbox.
Sandbox Environment
Like a litter box, it can be full of…
In sandbox environments, developers have free reign to develop, implement, and experiment with new code and processes. Good developers will work solely in sandbox environments when working on these types of development tasks. It is important to note that if resources are available, data in sandbox environments can often be the same as data in production environments. If a team is limited on resources and sandbox data can not match production-level data, the sandbox data can be a sampling of production-level data. This enables developers to complete logic and unit testing in sandbox environments.
NOTE: When developing code for the first time, work in sandbox first, not in production!
Development Environment
Does the code play well with others?
Once a code set is tested in sandbox, it is promoted to the next environment: development. The promotion of the code set is usually combined with source control, but we’ll leave the discussion on source control for a future blog entry.
The purpose of the development environment and its distinction from a sandbox environment (in this scenario) is that further integration testing can be done. A piece of code “worked out” in sandbox must be tested in a development environment against all other code sets. The code must be tested thoroughly against upstream and downstream dependencies. If errors occur, an iterative process is employed to work out the issues via unit testing. This unit testing is done in the sandbox environment. Once the errors are fixed, the freshly modified code is then verified in a development environment via integration testing.
NOTE: Just because your piece of code works correctly in your sandbox environment does not mean it works correctly when integrated with everything else.
Test / UAT / QA Environment
What do USERS think of the code changes?
This environment can be referred to by many names, like “test environment”, “user acceptance testing”, and “quality assurance environment”. The Test / UAT / QA environment exists to enable non-developers to test developed code and verify that it works. Feedback from users is incredibly valuable for developers, as user perspectives often provide insights into both negatives (bugs, errors, etc.) and positives that developers can miss.
A specific quality assurance (QA) group may be utilized to test a code set against requirements defined by business analysts. When an error is found in a Test / UAT / QA Environment, the iterative process we mentioned earlier is employed, starting back in sandbox.
A great example of this type of environment in action is when a software company enlists beta testers for its application. These beta testers test the application in a test or user acceptance environment.
NOTE: Enlisting beta testers can help identify programming and coding use-case scenarios not accounted for by the original developers. “I didn’t know the user would do that with my process!”
Production Environment
Where the world sees the final product
Once testing is completed, we get to the last software development stage: production. IBM puts it best: “The production environment is the environment where your services are made available to your customers.”
The production environment is the pristine environment that is front-facing to the customers – whether it’s the online banking application and system, or the online gaming server used by gamers all over the world. Code released to the production environment should be error-free as much as possible, and developing, promoting, and validating code from the prior environments helps ensure stability in production.
Of course, not all code released to production is perfect; updates to our phones and phone applications, operating systems, video games, and entertainment platforms occur frequently. Modifications are an inevitable part of the software development cycle. The importance of each environment can’t be overstated.
NOTE: Once a piece of code has been tested and validated in sandbox, development, and in test…many times over and by many eyes, then you will have peace of mind that it truly is ready to deploy to production.”
If anything, Development and Production
In consulting, working with at least development and production is highly encouraged and considered best practice. Working in a system that includes all 4 environments is ideal of course. But by having at least these two environments in place and separated, bug fixes and modifications can be completed in isolation in development (and away from production). Unfortunately costs and resources can limit what environments are available. I have experienced (many times) developers who have access to production and thus do their development work in production! Not good! While this may seem appropriate to many – “I know what’s wrong with production. I can fix it.” – it more often than not introduces many risks…“Oops! I think I deleted a table in production!”
Share Your Story and Tune In Next Time
Thanks for reading our first installment of Tales from Consulting. Now we leave you with a question: What are your experiences working with development and production environments? We’d love to hear about them!
Next time, we will discuss software development life cycles (SLDC).
Keep your data analytics sharp by subscribing to our mailing list!
Thanks for reading! Keep your knowledge sharp by subscribing to our mailing list to receive fresh Key2 content around data analytics, business intelligence, data warehousing, and more!
Key2 Consulting is a data warehousing and business intelligence company located in Atlanta, Georgia. We create and deliver custom data warehouse solutions, business intelligence solutions, and custom applications.