Job code deployment to production

(0) Share

Report

Posted on by Community Member

Hi everyone,

I wanted to get some feedback from those more versed with AX than I on a topic. We follow best practices to deploy code to production of course. But occasionally we'll need to write a small job to update a table record some one reason or another. These jobs we currently also package up with our deployment. I was curious if moving jobs to production requires the same strict adherence to process as, say, modifying a form or class? Let's assume the job is fully tested and is not invasive. An example, it interrogates the UserInfo table and writes data out to a text file.

Thank you in advance for any feedback provided.

*This post is locked for comments

I have the same question (0)

All responses (5)

Answers (0)

Fredrik Sætre 12,644 on at

Like (0)

Report

Not an expert on this issue, but I guess if you would like to keep your CIL compiled in a controlled (not live) environment and keep it in check you want to adhere to the trusted regime.

Was this reply helpful? Yes No
Suggested answer

Florian Hopfner 2,461 on at

Like (0)

Report

Depends on your process, but I'm guessing the question you are really asking is "can I deploy my job using xpo?" even though deployment by xpo is a big no go. I'm not going to tell you that you can or should do it. I will tell you that in some of my projects this was done, but

- you better know very well what you are doing and

- you have a really good reason (and for the example you described I doubt the reason is good enough)

In short, make sure this remains a rare expection to the rule.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thank you both for your opinions. I agree it's hard to find a good reason to push job code out to production given the potential for issues.

Was this reply helpful? Yes No
Suggested answer

KyleLeBarre 747 on at

Like (0)

Report

In theory, no code movements to production should happen outside of a modelstore deployment. In end-user-land, as long as the output has been verified in another environment, the risk is low. Jobs won't affect CIL or mess with table/field IDs.

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (0)

Report

If you use jobs for one time use: you could create or import them into production. Then run them and delete them (as there is no reason to keep them and you want to keep modelstore in sync with other environments). DO MAKE SURE IT IS TESTED!

If you need to run them more then once, you're using jobs in an improper way and should create class(es) which should follow the model/modelstore procedure.

Was this reply helpful? Yes No