While most of developers think of Dev, Test,
Live environments as fairly new concept, the actual reality that this standard
draws it’s roots back to the days ways before invention of the Internet, from
the early ‘60s of the 20th century, when the first software was
developed, to be integrated into hardware.
Known back than as a Systems development life cycle (SDLC), later as Application development life-cycle, SDLC defined a process for planning, creating, testing, and deploying an information system, where Dev, Test and Live stages were defined in fairly similar way as we use it today in software development.
This part of the process is mostly consisted of setting up a development create a development ecosystem that includes three separate environments:
There are some projects and situations where
you don’t need all three instances at some point of the Software Development
lifecycle, early in -dev, for example, but most commonly, a standard application
eventually requires all of them, as the software grows and development comes to
more mature stages.
Beyond the three environments, you need a
controlled way for changes to move around. You need a workflow. And because application
is also often full of content (most often user-generated content), content also
has to be accounted into equation.
The best workflow for app development is one where code is pushed “up” from Dev to Test to Live, while content is cloned “down,” always treating the live app as the canonical content source. These environments should be consistent in terms of both their configuration and performance, if possible. If they’re not, you can be in for a nasty surprise when you go to deploy.
It's possible that features or designs that "worked on my computer" will not operate properly when the code goes public. Configuration management in code may be used to further develop a best practice workflow once the environment has been set up.
Moving from one environment to another (Dev>Test>Live) is a lot easier when you can see exactly what has changed, who made the change, and when. Also, when creating your environment, take scalability into account and choose the environment that can scale fast, cloning the instances when needed, as for application marketing campaign, for example, making the environment that can take any load, any time at any continent you need it to.
Dev/Test/Live is, in our opinion, an essential component of any effective development process. That's why the Mars engine was designed around it.
With Mars engine you can also set up multiple test environments in different countries, cloud providers and continents, identical to your production environment with few click only.
Using Mars engine for setting up your environment saves you lot of time early in development, but most importantly it provides you with unmatched control over your infrastructure and ability to scale your apps fast, when you need it, how you need it, where you need it, within seconds, not hours.