hi Gianni,

which version of IFS are you using?

Generally - in IFS EE - you can highlight records, Right-click - Edit - copy object, then go to another environment (same screen), RMB - Edit - Paste object.

This works well for basic data.

There is also a magic spreadsheet washing around that does much the same thing, but allows you to edit the data in Excel in between extracting it and loading it.

You may want to also look at Application Configuration Packages. You can add configurations e.g. custom fields etc. to an Application Configuration Package, export that from say the Test enviro and import into Prod. This is how we generally do things - we develop in Test, add to an app config package and then export that to the Prod environment.

It also helps provide an additional layer of documentation in IFS about what configurations have been applied to your environment.

hi @gianni.neves 

are you asking with regard to regular IFS data, or configuration items e.g. custom fields?

Hi @paul harland ,

I am working at version 9 and configuration items like, EXTERNAL FILE TEMPLATE, DATABASE TASK SCHEDULES.

Thanks,

@gianni.neves 

Database task schedule - we recommend creating these manually.  There’s no export/import function, although it’s probably possible if you use the migration tool (write them out to a file and then import them).

Database Tasks (not the schedule) can be exported/imported, but this is only relevant if you have created new ones, which is unusual.

External File Templates - I think you are best using Copy Object / Paste Object.  Someone might know if there’s a function-specific way to export them, but i don’t think there is.

Along the DevOps philosophy, I start writing a “deployment plan” as part of the process of developing the solution. I add a line to that file before I create each file. Attempting to write it afterward takes more time and is prone to omissions.

Developing without the end in mind would be like designing a manufactured good with only customer requirements. You can’t ignore the process of actually making it. I highly recommend the book The Phoenix Project if you haven’t already read it, where this analogy of comparing IT to manufacturing is explored in some depth.

This is also why I recommend separating DEV and TEST environments. What your users are testing isn’t just your solution; they’re also testing how well you’ve deployed it. If you blindly hack at something until it works, you won’t remember what you’ve done in order to repeat it in PROD. Separating DEV and TEST forces discipline.

There are two reasons why I recommend frequent refreshes of your DEV and TEST environments. The most obvious reason is that you’re testing against the latest configuration and data. A less obvious reason is that it forces you to get really good at deploying things. That’s one of the paradoxes of the DevOps philosophy: If change is hard, it’s because you lack practice.

Anything I develop that isn’t intended for PROD goes into a “development scaffolding” file. I don’t throw out code, but I do keep my junk in its own tidy place. This gives me the mental comfort of knowing I won’t lose work should I decide later to include it, and this comfort improves my flow.

I script everything I can. It’s the best way to guarantee exactly the same deployment between QA and PROD. Database task schedules can be created with BATCH_SCHEDULE_API.NEW__, for example.