3

I'm planning a project that consists of the following parts:

  1. REST API in Lumen
  2. Web client in Laravel
  3. Product website in Jekyll

These separate products are going to be running on the same server.

I'd like to have a development environment that mimics the production environment as closely as possible, that's why I'm going with Vagrant in combination with a single Ansible playbook that provisions both environments.

What's the best way to organise such a project? Should I keep everything in one repository, or should I split up the parts into multiple repositories?

What about the development environment and provisioning scripts? Should I put these in a separate repository? How would I go about referencing the separate parts of the project in the development environment?

I'd like to be able to clone a single repository and spin up a development environment with as little work as possible.

Any recommendations?

Edit: My question differs from this question because I'm especially struggling with things related to production and development environments.

Improve this question
3
  • @gnat There is indeed some overlap between the questions, but I'm especially struggling with organising this project given that the parts run on the same server and that I'd like to use a single development environment. Some specific insights regarding those subjects would help me out a lot.
    – Willem-Aart
    Jan 3, 2016 at 11:42
  • Does "a development environment" always mean one set up with all three of those subprojects, or just one? Usually when I have a project with multiple server-side parts like that I rarely need to work on all of them at once. Also, could you tell us more about these scripts? (I have no idea whether these are shared between the subprojects, whether they're 10 lines or 10k lines, etc)
    – Ixrec
    Jan 3, 2016 at 13:17
  • @Ixrec It depends. The product website does not depend on either the API or the client, so it could run apart from the other two. The provisioning scripts are a couple hundred lines of code in total. Since the subprojects run on the same server, the provisioning scripts are shared between these subprojects.
    – Willem-Aart
    Jan 3, 2016 at 13:45

2 Answers 2

Reset to default
3

After some fiddling around, I came up with a solution that seems to work pretty well.

I keep the subprojects in separate repositories:

  • projectname-infrastructure
  • projectname-api
  • projectname-client
  • projectname-website

The project-infrastructure-repository contains a Vagrantfile, some provisioning files and an Ansible playbook that is run locally in order to set up the development environment:

--- - hosts: 127.0.0.1 connection: local tasks: - git: repo=https://name@example.com/projectname-api.git dest=www/api/ - git: repo=https://name@example.com/projectname-client.git dest=www/client/ - git: git: repo=https://name@example.com/projectname-website.git dest=www/website/

When the above playbook is run, the separate repositories are cloned into the www-folder that nginx on Vagrant uses to serve files.

Of course, the www-folder is inside of the .gitignore of projectname-infrastructure.

The only thing I need to do is git clone https://name@example.com/projectname-infrastucture.git, followed by ansible-playbook setup.yml -i 127.0.0.1,. Then I can just execute vagrant up and everything is up and running.

Any downsides to this approach?

Improve this answer
3
  • It's a good approach; we use something similar at my work. We've got 5-7 projects and a single Vagrantfile. The only problem: how would a developer test his or her changes against the local Vagrant env?
    – user169469
    Jan 3, 2016 at 17:57
  • @ChristianEWillman What do you mean, exactly? The folders in www are synced with the Vagrant environment through shared files.
    – Willem-Aart
    Jan 3, 2016 at 18:25
  • Ah, I didn't comprehend that from your post. Then I think your system is fine, and it is extremely similar to how we operate at work. The only difference is that our developers clone project repositories to a shared directory by hand, as we have many projects and a developer may not be interested in all of them. It also gets a little more complicated when a project may have more than one active branch.
    – user169469
    Jan 3, 2016 at 19:15
2

I'd suggest using same repo even if parts are running on different servers. And I wouldn't split setup scripts (e.g. ansible playbook) into different repository too, because it is the same project any way.

It is just a matter of convenience: you only need one checkout to get started as a developer, tester or support engineer. And I wouldn't bother about provisioning unneeded parts of a system to a server, because ansible could take care of that.

Improve this answer
2
  • A shared repo will definitely work, but quickly becomes a nightmare for project management as well as code organization if and when the project takes off. Even though all components are logically separated, their physical proximity encourages developers to think "monolithically".
    – user169469
    Jan 3, 2016 at 18:00
  • 1
    @ChristianEWillman, I understand the point, but in my opinion this is the last thing that will become a nightmare when project starts. I don't see how separating repos can improve management. In my experience it only adds more layers into setup process and requires additional effort to keep thing synchronized.
    – name_no
    Jan 3, 2016 at 18:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.