GIT development & deployment – architecture planning

After several years of re-engineering an entry level auction house platform with my friend Rüdiger (in my spare time, non-profit), i’m now planning to migrate my out-of-date Notepad++/FTP/production-only-workflow to a more stable and reliable PHPStorm- and GIT-based development/deployment process. Especially the last 12 month gave me a huge boost when talking about integrated development environements (IDE), debugging features and a lot of new tools for M2M (machine-to-machine communication). Sockets, REST-APIs and all this state-of-the-art cool new stuff opened a lot of new doors, not only for my private purposes, but also for my carreer.

So, back to non-business. Thinking about environments first, it’s clear to have at least two of them: live and test. At this point it’s not necessary to have every version that was ever build available all the time, that’s more risk than fun. So taking this further we will have two domains available for our live users and filthy little testing-midgets (; www.example.com and test.example.com, last one protected by a dumb htaccess.

Underlying the webserver providing (at least) access to our production and development filesystem we’ll use three main directories for the source files: /bare to hold our bare GIT repository, /live to deploy our master branche, accessible via www.example.com and /test for breaking everything on test.example.com.

My first thought before this conclusion was to generate a directory for each main version resulting in folders like /test, /v1, /v2, .. /v17, and so on. Besides spamming the servers filesystem and maybe giving more attackpoints for blackhats through vulnerabilities, i was thinking about the uptime which could be decreased to near zero by just re-routing the domain to the specific directory/version – same with restoring older version.

So i came up with this advantages of mapping two branches on two directories:

 pros  cons

+  simple, easy to understand and maintain

+ (nearly) no old code, resulting in …

+ … less vulnerabilities, no loot for crackers

+ .. and everything tidied up 

+ more automation 

– slower deployment due to copying files 

 

 

 

 

 

Maybe i’ll rethink this, putting in more scripting (hooks) for renaming live and test directories after a master merge.

Yeah, master merge. So, now lets see what we’re doing on the local machine and how the server will manage the pushes: Classical XAMPP environment, PHPStorm IDE with set up GIT origin remote bare repo. After developing just commit and push to the server. The GIT hook will manage the deployment to the specific directory, based on which branch we push. „dev“ branch to /test, „master“ branch to /live. Just force a checkout so we can be sure nothing broke from a merge.

Let’s think about it again tomorrow and then i’ll test this in real life. 

[insert info graphic here]

[link to next article]


Schreibe einen Kommentar