AEM Dispatcher cloud manager deployment

[NitroHazeDev]

All,

Followed adobe docs to add dispatcher module to the git. Now the question is,

1. do we need to add all the files into conf.d conf.dispatcher.d, including the ones we didn't alter?

2. I know we create a zip file, as part of the build process , does cloud manager replace the directory itself  or just the files that we have in the repo gets pushed in there that gets updated? I believe it is latter but thought of confirming  ....Online document states " Upon deployment to a dispatcher Instance, the contents of these directories will overwrite the contents of these directories on the Dispatcher instance" 

3.  Is there a restart of dispatcher that has to manually occur post deployment or does cloud manager take care of it for every deployment?

4. Validated the configs on local and it looks fine. Are there any other steps to be taken? The variables are already set by AMS 

[Anish-Sinha]

HI @NitroHazeDev ,

Please find my response below:

1. yes, you have to include all the files. CM doesn't identify what all files are changed.

2. CM deployment replaces all the files while deploying the dispatcher. Changed as well as not changed files.

3. Restart is not needed. It is taken care by the cloud manager. Cache clearance is also done by Cloud Manager. You can define the paths for which cache should be cleared in your pipeline config.

4. Local validation Sounds good. 

[NitroHazeDev]

Thanks @Anish-Sinha .Retained , conf, conf.d and conf.dispatcher.d. All the files within it OOTB and new files have been retained after your confirmation. Will skip directories unneeded like conf.modules.d. Unless you think it is needed. I believe it should just not update or touch it.
I see validation errors due to paths like etc and stuff on local windows, i plan to test it on linux but skeptical as using validator might mean i have to have docker set up or it might just trigger docker ?

[Anish-Sinha]

yes, as you are moving the build to cloud manager, most of the rules remains same. If you have dev server, I would say you can test the build to dev by creating the dev pipeline. You can check the logs and fix any inline issues you see. It would be quick and easier I believe. 

[NitroHazeDev]

Thanks @Anish-Sinha , i agree will take the pipeline approach, will revert if any issues. 

[NitroHazeDev]

In case it helps someone. 

After trial and errors, 

Our pipeline needed checkin of conf.modules.d.Without conf.modules.d, we ended up with issues where the service wasn't loading, no MPM Loaded error or so.

Ensure the sym links are established. 
We ended up checking in conf, conf.d, conf.dispatcher.d

Validation errors weren't a piece of cake to clear, since i was evaluating it on windows and executing the command httpd -t,  did not help much until the CSE tried doing it in clone env, since we naturally would need to erase the config to test.

For sym links - We ended up switching from Windows  to Linux m/c and then the Adobe Git repo branch seemed to have the correct symlink files. Ensure the pipeline has 
Java 8 was used for build  and below commands ; git config core.autocrlf true &
git config core.symlinks true