12 min
Development Environments - Isolating Customers From Your Changes Healthy Software Developer
-
- Technology
To release software to your customers, you'll probably need several development environments. To allow a team to make changes to software without disrupting paying customers, we need a way to isolate them.
Software developers and engineers working on an agile software development team need an environment where they can make changes under development. The development environment might be a copy of a website, database, or API on their computer. This is sufficient for a product with a minimal footprint. In a larger and more complex software product, cloud or server resources in a datacenter may be needed to support development environments.
In addition to a development environment, most teams need somewhere separate from development and production to do additional testing. This can be known as the "test", "user acceptance" (UAT), or "staging" environment and allows the team to more closely inspect a version of the software slated to release.
The final environment that is always required is production itself - or the place where your paying customers use the software.
In addition to a development, test, and production environment - there are two other environments that can be fairly common.
One of these is a demo environment, who's purpose is to provide a playground or sandbox where a limited audience can "kick the tires" of the software without disrupting the development team.
The other common environment is a capacity test environment, who's purpose is to determine whether a potential release of the software will stand up to a real load. Capacity test environments should have the same hardware or cloud processing power as production, to provide testing results that are representative of real traffic on the same computing power.
Regardless of which environments your company or team uses to release software, you'll need configuration management to automate releases through these environments. I'll talk about configuration management tomorrow, and how you can use it to make sure releases of the software in a given environment don't accidentally point to the wrong environment's resources.
You can also watch this episode on YouTube.
Related resources:
Continuous Delivery - Are You Missing The Big Picture?
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
To release software to your customers, you'll probably need several development environments. To allow a team to make changes to software without disrupting paying customers, we need a way to isolate them.
Software developers and engineers working on an agile software development team need an environment where they can make changes under development. The development environment might be a copy of a website, database, or API on their computer. This is sufficient for a product with a minimal footprint. In a larger and more complex software product, cloud or server resources in a datacenter may be needed to support development environments.
In addition to a development environment, most teams need somewhere separate from development and production to do additional testing. This can be known as the "test", "user acceptance" (UAT), or "staging" environment and allows the team to more closely inspect a version of the software slated to release.
The final environment that is always required is production itself - or the place where your paying customers use the software.
In addition to a development, test, and production environment - there are two other environments that can be fairly common.
One of these is a demo environment, who's purpose is to provide a playground or sandbox where a limited audience can "kick the tires" of the software without disrupting the development team.
The other common environment is a capacity test environment, who's purpose is to determine whether a potential release of the software will stand up to a real load. Capacity test environments should have the same hardware or cloud processing power as production, to provide testing results that are representative of real traffic on the same computing power.
Regardless of which environments your company or team uses to release software, you'll need configuration management to automate releases through these environments. I'll talk about configuration management tomorrow, and how you can use it to make sure releases of the software in a given environment don't accidentally point to the wrong environment's resources.
You can also watch this episode on YouTube.
Related resources:
Continuous Delivery - Are You Missing The Big Picture?
Visit me at JaymeEdwards.com
Find me on Facebook at JaymeEdwardsMedia
Find me on Twitter as @jaymeedwards
12 min
Top Podcasts In Technology