The FOSS Enterprise Application Platform
Putting it together
How we build and deploy Preside applications as a busy agency
About me
Dominic Watson
- Technical Lead @ Pixl8 Interactive
- Lead developer of Preside
- Like making bread (but not very good at it)
About Pixl8
- Web development agency since early 2000's specializing in CMS and web applications for membership style organisations
- Based in London, UK + Kuala Lumpur, Malaysia
Preside
A growing competitor for mid to large-scale commercial content platforms; open sourced. We work openly and with integrity to create a platform for and with our community.
Our mission
To build an out-of-box web application foundation that does as much of the laborious, hard and overlooked work for you, accelerating teams as they focus on unique requirements.
To build a community and platform that leads by example; that is a joy to use, a joy to work with and a joy to participate in.
Our vision
Preside solving complex needs for a wide breadth of industries and communities. A well-known name founded on openness and excellence.
What we'll cover
- TWGit Git Workflow
- How we build applications with Preside extensions and coldbox modules today
- How we deploy our applications today
- How we inject environment specific variables today
- A little of how we got there ^^^
The PROBLEM(s)!
Problem 1: People
Collaboration within our team and with volatile clients!
Preside Projects with Dependencies
- Preside Extensions
- Coldbox Modules
- Git Submodules
- Anything else we can think of
Tests!
Environment configuration
Without coding or meddling on the server!
PRODUCTION
UAT
VS
Static asset generation
CSS / JS Minification, etc.
Solution part 1:
Git branching workflow
http://twgit.twenga.com/
TWGit
From Twenga
Simple and powerful flow that we use for both Preside itself and also all our client projects. This flow has transformed the way we work in teams and is (relatively) easy to learn.
Solution part 2:
GitLab :)
FOR EVERYTHING ELSE
GitLab:
Quick Tour and setup
(LIVE DEMO)
GitLab:
Pipelines
A file that configures what jobs to run on what commits and when
GitLab:
Pipeline build files
Basically, you can run ANYTHING you want when you commit to a repository (or when you manually run a pipeline. We:
- Build static assets with Grunt
- Pull down dependencies using CommandBox, git submodule update and anything else
- Run tests using testbox + Commandbox
- Deploy files using rsync
GitLab:
Build variables and environments
Environments in Gitlab Pipelines + convention based pipeline variables help us deploy to different environments with different settings
Looking back
and forward...
- Used to use SVN, no branching strategy, deploy using TortoiseSVN, Beyond Compare and manually editing of source files for config on servers
- Moved to some kind of branching model
- Moved to Git and TWGit + Submodules for dependencies.
- Moved to Linux.
- Deploying through sftp from repo server, no builds though
- Built an app for dependency injection
- Started using Jenkins
- Built an app for deploying using our convention
- Discovered GitLab
- Next: docker across everything
Thanks for listening
https://www.preside.org/signup
https://community.preside.org
https://presidecms-slack.herokuapp.com/
https://presidecms.atlassian.net