We’ve got multible custom applications that we distribute with tasks.
Some of the tasks are in baselines.
When there is a new version of an application, say from version 5.2 to version 5.8, a new task is created and we update each baseline with the new task. This is very time consuming and inefficient.
I was wondering if a bettar appoach would be to update the existing task, update the version number, replace the .msi file and possibly renaming the task. That way it would keep it’s ID number and in theory the baseline would still use the same task and there would be no need to update the baselines.
Am I way off here or do you have some advice on how to steamline updating tasks?
That’s a very good question/use case and I have been pushing for full-GIT integration where all of this can be handled for you (listed as use case under this idea) but unfortunately it hasn’t been committed to.
As things stand you can create your own automations to handle it but it will take a bit of time… The approach depends on whether you would need to use the old version fixlets ever again. If the answer is NO, then editing should be fine - edit the contents and then all you need to do is “sync up” the baselines (you can do it through APIs: /api/baseline/{site type}/{site name}/{id}/sync). If you have policies based on the baselines you’d need to recreate those too. IF you do need to retain the old version of the fixlets it does get a bit trickier… Your automation would need to query each version of the fixlets, evaluate the latest version and compare to what is in the baselines - once it determines there needs to be updated, it’d need to remove the old one and add the new one - it should all be doable via the RestAPI but might require you to do some XML-level file manipulations (API baseline documentation). Not ideal but you can streamline it if you really want to…
I think it is called “Dynamic Fixlets”, at least it is what my team refers to it as.
Create a text file with the prefetch statement for all necessary files.
Upload that file to the site you are using, or the site you want it to be added to.
Then add this to the top of your task to deploy, using the name of the file and the name of the site you chose.
begin prefetch block
parameter "CSSpecs"="{pathname of file "CStool.spec" of client folder of site "_Dean's Content Development"}"
add prefetch item {line 1 of file ("CSSpecs")}
end prefetch block
If your .spec file has multiple lines (multiple prefetch items) use the line(s) you need. Make sure you use a generic name in the spec file, don’t use “installer10.0.2.3.exe”, use use “installer.exe” so you can refer to it in a generic manner in the rest of the task and the task does not need to be updated.
Then when you have a version change, modify the spec file and then upload it to the site, keep the same name and overwrite the spec file there. You may have to delete it and upload the new one.
But, you don’t have to update the task or the baseline that is already deployed. The task did not change at all, the content of that task changes dynamically with the text from the spec file. It is very similar to using an “include” state in many scripting languages, to include another file.
If these are not clear instructions, let me know and I will give you more screenshots of the example
