conceptual What is the best way to manage day-to-day development tasks for a running project

[Tech Support]

The world is changing and being able to put ongoing changes into your running site is essential need of any successful project. KVS regularly adds new features and some of these features are not brought into themes, so you have to add them manually. However doing changes on a live site brings some risks to harm site operation. In this article we summarize the possible configuration scenarios for ongoing site development and their disadvantages.

 

Working on production theme

The most typical scenario and very good for small projects. However actively working with regular changes may bring some issues.

Pros:

• No specific configuration or procedure needed.
• Changes are applied immediately.

Cons:

• Harmful changes may result in project unavailability for some time until sorted out.
• Intensive template changes may result in regular cache reset, which could impose performance issue when modifying top-visited list-block templates.
• Difficult to work in development-testing iterations, when partial changes applied, then tested, then next set of changes applied, and etc.
• Security considerations (should provide access to 3rd-party developers).

DEV satellite

DEV satellite is very useful for the new theme development, when you need to spend a lot of time with either re-design, or a new design for your site theme. While working on DEV satellite you can't harm a working project in any way and you don't need to hurry. When your new theme version is ready, all what you need is to migrate it from satellite to production site. End of story.

However using DEV satellite for ongoing minor theme changes is not that safe, as you could assume. The main reason is - when you migrate theme, you can't migrate something specific, you have to migrate everything, including templates, styles, configuration parameters, SEO, texts and even site advertising. Having that in mind, it becomes clear that it is not possible to selectively use DEV for testing 'some' changes - it is either ALL, or nothing.

Here is a typical scenario that could happen from time to time:

1. You decided to change something minor in advertising (e.g. replace some ad) and decided to change it directly on production.
2. Then after some time your theme developer started working with a new feature on DEV satellite.
3. After the feature is finished, you migrated theme from DEV to production.
4. Oops, your first advertising change has been lost at this point and you may not even remember about it.

Hence the conclusion is - you can use DEV satellite for ongoing theme development only if you stick to strict process of putting all changes into DEV first, then testing them on DEV and then migrating them to production. If you decide to go with this approach, it will be possible for your admins to automate theme migration process and provide command line utility that will copy all the needed files from DEV satellite to production. Unfortunately this can't be automated from KVS side and should be run via command line only due to filesystem restrictions (in most cases Apache won't have enough privileges to copy all needed files, so should be done under a more privileged user).

In order to know which files should be migrated, your command line tool can parse the tar.gz archive created by KVS backup plugin. The idea is NOT to extract files from backup archive, but use it to extract filenames for the files that need to be migrated. Here is a command that will locate the latest backup archive and extract the list of filenames relative to project document root:

find admin/data/backup -type f -name '*.tar.gz' -printf '%T+\t%p\n' | sort -r | awk '{print $2}' | head -n 1 | xargs tar -xvf | grep '^website/' | sed 's/website\///g'

Pros:

• Your primary site won't be affected in any way until you manually run sync procedure.
• Possible to configure DEV on a separate server to secure your primary installation, if you don't want to provide your theme developers FTP access to your running project.

Cons:

• Strict requirement to apply every single change via DEV satellite.
• Long time to apply any change, even very minor.
• Not possible to optimize performance on the fly.
• Hard to configure in small teams, needs command line.

 

Creating new versions of pages on production theme

This approach seems to be the most usable and best manageable for all kind of projects.

Minor changes should be applied directly to production site, as they typically do not harm your project operation. When some big changes are planned, developer should follow this guideline:

1. Duplicate page that needs to be changed into a page with new version in its ID, e.g. for view_video page it should be view_video_v2, view_video_v3 and etc. Duplication of existing page is one click from admin panel:
   
2. Duplicate the affected page components if needed. E.g if working with new video list design, duplicate include_list_videos_block_common.tpl into include_list_videos_block_common_v2.tpl and switch v2 page to use this new template version instead.
3. Work with new page version / component version without any rush and risk to harm other parts of project. You can access the new page via its direct PHP URL:

   https://domain.com/view_video_v2.php?id=123

4. When finished working with page, just change in PHP script in .htaccess rewrite to use the new _v2.php file to enable new page version into production. Deactivate the old page in KVS admin panel to make sure it will not be used and in future it will be clear that this is obsolete version.
5. When finished working with page component, copy-paste the new code into the old page component template and remove the new page component and eliminate all usage of it. There is no sense to keep old and new page components together for history or any other purposes, as KVS keeps track of version history for all templates and will record both old and new versions of the changed component. Unlike pages, components are single files and can be easily restored to any specific version, if needed.

IMPORTANT! Make sure you deactivate old page versions when switch to new page versions, or even delete them. It should be clear that specific page versions are not used anymore, otherwise you may have troubles in future, when you need to fix something and you will find yourself in the need to fix bulk of v2, v3, v4 and etc. pages, most of which are not used anymore, but you are not sure which ones. Do not keep trash in your templates!

Pros:

• No specific configuration needed.
• Small changes are applied immediately.
• Big changes do not harm working site, and developers have enough time to work with them in their own way and pace.

Cons:

• More manipulations needed to prepare working environment.
• Security considerations (should provide access to 3rd-party developers).

[Matyko42]

Dear KVS Team,

I am so happy for this article!

We are struggling with this issue for months, and all we could think about is keep using the DEV satellite even for small developments.

This article made me understand that this is Not the best practice - however it was very useful when we were working with the developers on our flagship site's redesign. 

 

The last approach seems to be perfect for us, and I am sure that the developers will support this too.

Thank You & Keep up the good work on your amazing product! <3 <3 <3

Matyko, www.fapnado.com