1

I'm working on a project that will have these applications:

- backend api   (nodejs)
- ios app       (objective-c)
- android app   (java)
- web site      (php)
- admin site    (php)
- client site   (php)

My question is about versioning and managing all this projects.

I'm thinking about two options:

1) build each app saparately

  • Harder to test apps integrations
  • If I change something in one app, I need to be careful with all other apps
  • I need merge all apps changelogs to a single document

2) put all apps into one single build

  • This seems good to generate a single changelog
  • Maybe write tests to apps integrations?

--

So, what is some good practices for this case? Maybe option 2?

anderlaini
  • 1,593
  • 2
  • 24
  • 39

2 Answers2

2

My vote goes to option 2. Much easier to 'carry' development across all its phases with a monolithic approach:

  • simpler integration - all pieces are already integrated, everyone working on any piece of the overall project is on the same page, not in their own sandbox (true continuous integration, if you want) - very important if you also plan to use agile methodologies
  • integration testing no longer has to be a separate activity, you can do it part of the regular CI process since you can test all pieces together (possibly with a single combo testbed instead of dedicated testbeds for each piece - lower costs)
  • simpler coherent/consistent source code control (even if the pieces have their own repos, they can be managed together in a monolithic style like I suggested in this Q&A: Build dependencies and local builds with continuous integration
  • possibly faster overall builds (different builds can use idle cycles in other builds which is harder to orchestrate when they are independent - they could potentially be better "packed", leading to cost reduction on build resources)
Community
  • 1
  • 1
Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • I agree with everything you said. Is this a commom practice in real world? Build different apps into single deploy package. I'm looking for some articles to read about this, but found nothing – anderlaini Jun 16 '15 at 10:56
  • Not common yet (from the implementation prospective). Multiple apps in a single deploy pkg: fresh/initial linux distributions, almost every complex/advanced embedded system for which installing or upgrading is `monolithic` (for exampe computing/storage/networking/military equipment). Actually it doesn't `need` to be a *single* deploy package (unless by that you really mean a set of more or less related packages which just happen to be deployed together). The concepts are here: http://www.martinfowler.com/articles/continuousIntegration.html – Dan Cornilescu Jun 16 '15 at 12:09
0

I would absolutely not go with option 2. Continuous integration was termed by Grady Booch back in the early 90's. Today, they want to use the term Continuous Delivery. I say we should have used Continuous Improvement the whole time. Anyhow, you want to be able to deliver, deploy, put into production an application, a project, "a" deliverable. You absolutely do not want to mix applications. You could have the need to deploy one application to production and something is wrong with another application. Or you just did a very quick fix to a single application and you want to take it through the process to delivery today. I would not choose option 2 for these reasons.

kleopatra
  • 51,061
  • 28
  • 99
  • 211
David L. Whitehurst
  • 11
  • 1