All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Web Application Deployment
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 -
- dev does not align with any version control commits/branches
- 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
Quick progression between staging (dev) and production. Bugs found can be fixed quickly.
Deployment process is easy & quick leading to regular deployments.
Simple to maintain, deploy.sh is only a handful of lines long.
Comments
Ansible + OctopusDeploy
@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.
I've managed to get by for years with CVS. checkin/update on staging, works? tag for release. Release? Deploy.
Jenkins + rundeck
We use Gitlab CI to build up docker container, run tests then deploy them to production if it was triggered from the master branch.
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.
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.