Search the FirstSpirit Knowledge Base
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?
Hi,
I'm trying very shortly to sketch our real world scenario for Template distribution
Server "A" (Master Server)
Server "B" (Sub-Master)
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.
Aren't you using any kind of test system before pushing your template changes into production?
Oh sure, that was just a rough description . 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)
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.
Hi,
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:
Global Content is our main concern at the moment :smileycry:, but at least we can handle the media now.