Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Web Application Deployment
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Web Application Deployment

SplitIceSplitIce Member, Host Rep

I'm not sure how many people here deploy reasonably large applications regularly. But how do you deploy your applications at scale?

How we do it

Our process is relatively simple considering the size of the application -

We have utilized a GlusterFS shared NFS drive so that all machines have a consistent state. Permissions restrict writing on the web nodes for security.

We have a structure similar to the following when mounted:

When exececuted deploy.sh makes a full copy of the dev folder to N+1 revision, clears the oldest revision if needed, and then sets the production symlink.

The web server polls the production symlink for changes, and when detected updates its internal webroot path to the appropriate revision dir (saves on a symlink lookup on every file load). Caches are emptied and warmed up at this time. We do something similar on the job queue workers too.

The problem with the method

We want to make it possible to do a full system deployment, in a testing environment at any time (think for automated testing and the like). There are few problems here -

  1. dev does not align with any version control commits/branches
  2. revisions don't align with version control commits/branches either. Makes it hard to align with CI.

So while this process has served us well for 4 years. We are looking to improve or replace it.

How do you do application deployment? or, how would you modify the process to meet these new requirements.

The Advantages of this method we would like to preserve

  1. Quick progression between staging (dev) and production. Bugs found can be fixed quickly.

  2. Deployment process is easy & quick leading to regular deployments.

  3. Simple to maintain, deploy.sh is only a handful of lines long.

Comments

  • gbshousegbshouse Member, Host Rep

    Ansible + OctopusDeploy

  • SplitIceSplitIce Member, Host Rep

    @gbshouse Well, we already use ansible and were planning to use that to fire off whatever solution was found so thats a match.

    Unfortunately OctopusDeploy looks .NET only. Our stack is PHP.

  • You have a holistic problem that can't be boiled down to a simple choice of deployment solution. Management has to decide if the wants they have really make sense according to the needs of the company. I've been in many places where they're all into the CI/TDD kool-aid, but that process doesn't really reflect how the business functions.

    So if you've already got a configuration management solution like Ansible picked out, what you actually need to do is back up and determine what needs to change in your process to get a workable outcome. From the outside looking in, it really sounds like you need to better formalize the division between development and production.

  • WSSWSS Member

    I've managed to get by for years with CVS. checkin/update on staging, works? tag for release. Release? Deploy.

  • Jenkins + rundeck

  • trewqtrewq Administrator, Patron Provider

    We use Gitlab CI to build up docker container, run tests then deploy them to production if it was triggered from the master branch.

  • SplitIceSplitIce Member, Host Rep

    I did some research into PHP specific solutions and most seem to just be file management like we do. i.e https://deployer.org/docs explains that their system uses the a similar structure but with releases & current instead.

    While systems like that provide a more formal deployment process, it's really nothing ansible can't do. And while I could rig that to githooks, but I would loose quick progression and ease while not gaining much over the current process.

    @impossiblystupid I agree. Currently in some cases the division is too small.

    When I think about it there are two types of deployments we do:
    1. Most of the time it's major releases deployed infrequently.
    2. Small changes, largely to static files or occasionally to fix a bug

    With that in mind I'm considering introducing two different types of deployments.

    deploy.sh --dev & deploy.sh --staging

    staging would be git based. While dev matches our current workflow and would always contain the latest version of the source. This would rely on the developers local testing before deployment if relevant to the changes made.

    The main goal on the completion of our ansibilization is to be able to deploy the system in full (everything from monitoring, to the filtering nodes, to the web side) in an entirely virtualisation environment. We should be able to do full system automated testing that way. Testing the full flow through the infrastrucutre i.e testing that an attack launched results in an attack notification & is registered for reporting.

    We can reduce our QA time & defect rate we hope by automating this stuff.

    @trewq while I like docker as a concept in practice I've found it a bit heavy weight - espececially on the 1 core / 512mb / 20GB disk instances that make up the majority of our deployment boxes. We scale out, not up with a passion. Thanks for your input though.

    Everyone else: Thanks for your input.

  • jhjh Member

    For PHP is there Capifony for Symfony (based on Capistrano for Ruby). We tend to use www.deployhq.com. The free version is really generous, really easy to set up.

Sign In or Register to comment.