Robust Deployment Schema
Why should I care?
- I want to see and approve changes prior going live
- I want to be able to check what changes and where exactly my developers made in my code
- I want to be keep the history of all changes
- I am concerned about security of my website
What do I get?
- a staging (sandbox) site – where I can test/play around with new features
- code separation – developers can no longer break my live site (unless I approve it 🙂 )
- full control – a complete history of all code changes, can see who, when and what has done and can easily roll-back if needed
- protection against hacked code. see e.g.: www.snapfast.com/blog/magento-mage-jpg-hack/
I see it so very often as a freelancer. A client asking for changes on their website, then giving me the ftp access straight to their live site to make changes. When I ask if they have a database and files backup very often it is: “Hmm, I don’t think so..”.
Well, if a developer produces a code that would break their live site, e.g. checkout page, for hours or even days, what would be the cost? And then fixing it. And what if I need to experiment a little and test things, make test orders?
It is simply obvious that having a staging environment is absolutely necessary for any website owner, but especially for e-commerce sites where each customer is extremely important and highly valued. And the equation is so simple: my site is not working or customers can’t checkout = I am losing money.
Ok, now the question is:
“How to make my staging site an exact copy of my live site?”
And even more important:
“How to maintain my staging site to remain the same copy of the live site over time?”
For sure it makes no sense to create a staging site where things work differently – even the slightest differences can bring a lot of headache where things are working fine on staging and after they go live “something” is just wrong.
Basically we are introducing 2 new layers between our code and developers:
- A/code repository
- B/deployment agent
As illustrated on the picture above there are now 4 layers in the whole process of code changes:
- various developers changing the code
- code repository with two parallel branches: develop/master (Bitbucked used as an example)
- deployment agent that automatically deploys the code to staging/live site as soon as the repository branch is updated (Codeship.com used as an example)
- hosting provider – environment for my live/staging sites (Amazon AWS hosting used as an example)
The most important thing is that all developers can now only communicate with the repository layer, they will never have direct access to the live site.
New workflow scenario:
Key features/benefits:
- developers will never have direct access to the live site, they only interact with the repository
- I can test new extensions/functions and roll back easily if I don’t like it
- various developers/teams can work on various features, all possible conflicts will be resolved on the repository level
- I will deploy to live only after all is tested and approved
- the deployment is automated and error-prone, no missed files due to a human mistake
- no site crashes due to faulty code – no customers loss even for minutes