Community Manager

How does your development process look like?

We're currently thinking of ways to improve the development process within FirstSpirit projects. Please see javascript:; for details.

We're curious to know how your current development process/cycle does look like. Here are some questions to get you started:

How does your FirstSpirit environment look like?
Do you have a development, quality-assurance and productive system?
How do you keep your environments in sync?
Are you using the template update feature to transfer templates from one environment to the other?

5 Replies
I'm new here


I'm trying very shortly to sketch our real world scenario for Template distribution

Server "A" (Master Server)

  • Is internal / not accessible from the Internet
  • It contains 2 development projects: The "Global Template" project, and a smaller "Formedit" development project (our own Form Edit module)
  • Both projects publish template/media packages into each other ("Global Template" and "Form Edit" templates are based on each other)
  • Both packages are available to all projects on this server ("Global Template" is the Basis, "Form Edit" is optional).
  • Development is only done in the master projects before the templates are rolled out into the productive projects via the package pool
  • The non-project-specific, updatable components consist of templates, media (CSS, images), global content (editable translation tables) and metadata / site store variable settings
  • Global content needs to be updated manually because it is not supported by the package pool
  • Other thing (settings, translated names and hierarchy of added templates) are updated with a post-package script

Server "B" (Sub-Master)

  • Contains international sub-sites - projects maintained by international dependecies over the internet
  • Stands in the DMZ, and has no network connection to Server A
  • Contains a "Sub Master" project which is a copy of the Master from Server "A"
  • "Global Template" and "Form Edit" templates in the Sub Master are updated with a "Template update" on a regular basis
  • Global Content and Media need to be updated by hand (Export / Erase / Import), and are therefore very much out of date Smiley Sad
  • In the "Sub Master" project, the templates and media are again put into 2 packages (Global and Form) and distributed across the projects via the package pool & scripts
  • Again, Global Content needs to be updated manually in each project

Even now, only with 2 servers, there are so many wholes in the process that virtually every project has a different level of template / media versions. Once daughter companies start hosting their own servers worldwide (based on server "B"), we need a robust mechanism to keep the central components of the projects up to date.

0 Kudos

Aren't you using any kind of test system before pushing your template changes into production?

0 Kudos

Oh sure, that was just a rough description Smiley Wink. One of the "slave" projects on the master server is a test project to test the template functionality as well as the update functionality. It is basically a snapshop (export/import) of one of the main production projects on the master server.

Which brings me to another thing: In this respect, the package pool functionality is less than optimal. Exporting / importing a project almost surely messes up the package subscription information as well as the package references when exporting the "Master" project. The Client itself seems to think that there is a package / subscription, but the pooling service doesn't see a package, of course.

So creating the snapshop with proper package references on server B(:smileyalert:) is an awful lot of manual work (remove item from subscription or package before creating a news subscription). When importing a project, all references to subscriptions and packages should be removes if the referenced package is not on the server (or just on request with an option in the import dialog)

0 Kudos
Returning Creator

Wir haben ein Enticklungs-/Testsystem (A) und ein Produktivsystem (B).

Auf A werden die neuen Anforderungen umgesetzt und müssen dann von den Nutzer getestet werden. Wenn alles OK ist, wird es auf das B System übernommen (meistens mit "Aktualisierung" erstellen).

Nachteil davon ist (Entw. und test als ein System), dass man meistens erst weiter entwickeln kann, wenn die einen Änderungen übernommen wurden. Das habe ich aber recht gut im Griff, da ich momentan der einzige bin, der die Entwicklung übernimmt.

Ab und zu, so einmal im halben Jahr wird das Testsystem geleert und mit den aktuellen Daten aus dem Produktivsystem gefüllt, wenn es sein muss auch manchmal zwischendurch.

0 Kudos


we have just a major upgrade to our template deployment process: A Script called "media updater" which writes a media tree from FS on a disk (Master Project on Server A), and then synchronizes the "Sub-Master" (Packet Master on Server B) from this media repository. It uses timestamps to check which media need updating.

All in all, we keep the second server and its projects up to date like this:

  • Templates: "Aktualisierung" from Master of Server A to Sub-Master of Server B. Both projects deploy the templates within the server via the package pool
  • Media: Transfer of package-related media with the "Media Updater" Script from Server A to Server B. Deployment on server via package pool
  • Global Content (Translation tables): Neither package pool nor scripting works, so we export the folder on the Master / Server B, and then need to delete the respective folder in every target project, and import it manually again

Global Content is our main concern at the moment :smileycry:, but at least we can handle the media now.

0 Kudos