How to Deploy Complex Development Projects in a Consistent Manner
Before I joined Project Ricochet, I would mainly focus on developing one single product. Or, I would manage development for a portfolio of projects within the scope of a larger product. So, suddenly having to switch between many projects each day was a fairly big change for me.
Collaborating with many people on several different client projects can be a challenge because as variables start to multiply, maintaining context for each product becomes harder. Since you probably find yourself in similar situations, I thought we could offer a few useful ways to make the transition.
For context, consider that Ricochet projects tend to fall into one of three areas:
- Drupal projects
- Meteor projects
- Mobile app projects
Within those categories, there will be details on how specific projects should move forward, depending on factors like... what frameworks we apply, where we deploy, and where it will be published.
Types of projects include:
- Migrations from Drupal 6 to Drupal 7
- Migrations from Drupal 6 to Drupal 8
- Drupal 7 projects built from scratch
- Adding new features to existing Drupal 7 projects
- Drupal 8 projects, created from scratch
- Maintenance for existing Drupal 8 projects
- Developing new features for existing Drupal 8 projects
- Meteor apps deployed to Docker cloud
- Meteor apps installed in ad-hoc servers rather than container services
- Mobile Android apps
- Mobile iOS apps
This list doesn’t even yet take into consideration what deployment platform should be used in the case of Drupal projects. It could be Pantheon, Acquia, the client’s own servers, or a hosting service like AWS, goDaddy, or Dreamhost.
As you’d imagine, juggling upwards of 40-some-odd different deployment strategies to accommodate all these different scenarios would be quite unsustainable. If indeed it were necessary, the situation might provide ample material for a case study on how to make a development team lose their collective sanity!
So, while there are instances where exceptions must be observed and compromises made — we try to standardize the approach as much as possible. To do this, first we analyze the projects to identify aspects that are shared between them.
In our case, we found that the three main commonalities were:
- Code management
- Relative ease (or possibility of) backup creation
- Deployment platform
To manage the code, we tend to use the same branching strategy for all projects regardless of the technology. Most development environments will feature a code repository with version control and three main branches (develop, test, and master).
We find that maintaining the same branching strategy and environment structure across all projects helps dramatically reduce the challenges inherent to switching between many projects each day, because the code repository structure is consistent and familiar.
Selecting the deployment platform isn’t quite as easy to standardize because it usually depends on the technology used for the project in question, and that has some inherent differences. But, that doesn’t mean we can’t work to minimize those differences!
For instance, recall that the two main platforms for deploying Drupal projects are Acquia and Pantheon. We don’t consider one superior to the other. One just might be better suited for some things than the other. So, we choose based on clients’ specific needs.
On the upside, both platforms provide:
- A Git-based repository to deploy our code to
- A way to create code, assets, and database backups
- Easy ways to create the environments we need for our branching strategy
Does that mean we need specific processes for Acquia versus Pantheon deployments? Thankfully, no! The steps are the same for both. How we perform those steps may differ based on their unique user interfaces or workflow. But even then, variations are minimal.
Streamline Your Meteor Projects
For Meteor projects, we use container-based services to help standardize their deployments. (We invite you to dig into Project Ricochet entries on Docker and containers, here.) The process is mostly automated. We just have to keep an eye on the branching strategy to make sure the environments have the code they’re supposed to have.
That’s why the branching strategy is so important from the start. Even though projects tend to feature different internal setups and package dependencies, the base environment is created with a shared Dockerfile that doesn’t explicitly specify the project dependencies. Quite often there will be a preliminary step within the project itself to build the project-based configuration file. That means we can use the same setup if we switch container services to a different provider.
Simplify Your Mobile Projects as Well
Mobile projects tend to be little more unique. But, we can still make things easier. Even when used to produce builds for different purposes – like development, staging, UAT, production, or release candidates – the branching structure is the same. And, we have two different deployment (or in this case, publishing) vectors – the platform’s official marketplaces.
Calibrate Your Process Based on Each New Project
Have we achieved maximum simplicity? Probably not. But, considering that we initially may have had to manage 40 different strategies, I believe we have really improved our approach. Essentially, we rely on one main process for code management that in turn gives way to three deployment processes.
Certainly, we are still fine tuning the approach. If you want to adopt a scheme like this, you’ll probably also want to test new solutions and aim to automate as much as possible.
Hopefully, you’d agree that from a development and release management perspective, the benefits are clear. I, for one, can attest that adopting these strategies has made it much easier to move between several different projects without losing my mind!
