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.
The outcome?
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.
