Export job designs with executables (where applicable)

[amit.jaiswal_ATL]

Hello All,

Just wanted to understand this option more because of "Where applicable" note. I am planning to use deployment automation scripting on Linux server. On Linux server job compile and dsx export options are not available. Therefore, I am thinking to keep dsx file (design with executable options) in svn/bitbucket and then import those files in target server. That way I don't need to compile the assets on target server. I am thinking to deploy from bitbucket to test server using DSXImportService.sh. For prod deployment I am thinking to automatically create the package (using CLI) from Test server and then deploy in prod environment. Do you foresee any potential issue/limitation with this option / approach ?

Thanks in advance.

[FranklinE]

My reply is generic in the sense that this is how we see it in our shop, and you might find value in it.

The production environment is set to read-only. When we have a production incident, having the Designer code in place is a great aid to determining the incident cause. Director messaging is not great in every scenario.

Compiling is restricted to the DEV and INT environments. We elevate code and executables to SAT (and CAT) for final testing, and use that base for the elevation to PRD. If nothing else, prohibiting compile above INT discourages developers trying to quickly solve a problem from doing it in a place where version control can't track it properly.

Our deployment standards set SAT or CAT as the "test" for the package being delivered to PRD. It's a limitation which avoids many issues.

[amit.jaiswal_ATL]

Thank you so much FranklinE for your response. In many places I found that deployment in Test environment is based on individual dsx file based and in production it is package based. If we use dsx (design + executables) based deployment on test server, is it ok to use same dsx based deployment for production as well ? Is there any reason most companies are preferring package based deployment on prod server ?

Thanks in advance.

[FranklinE]

We sometimes use the same .dsx file for the PRD elevation after verifying it in SAT or CAT. Below PRD, all of our exports and imports are done manually using the appid on login.

Our PRD environment is restricted to automated functions using the appid as owner of the processes. For this and other reasons, a package based deployment is the only way to be sure the integrity of the import. In our shop, we have very strict version control and auditing of deployment tasks. No one gets to avoid the paperwork.

[amit.jaiswal_ATL]

Thank you so much FranklinE for the details. Here is what we are planning as a part of deployment automation,

1. Maintain dsx files with Design and executables in bitbucket feature branch (which is created from develop branch. Develop branch is created from master branch)
2. After development and unit testing merge the feature branch into develop branch
3. Create release branch from develop branch, update YAML file with job names for deployment
4. Deploy dsx files into Test server using automation (no compilation on test server since those are already compiled)
5. Create package from the YAML file job list on the Test/UAT server using automation
6. Build the package and generate isx file and import the isx file in bitbucket using automation
7. Deploy the isx file into prod server using automation
8. In bitbucket merge the release branch into develop and master branch after successful prod deployment validation

Please let me know if anyone sees any potential issue in this approach and would like to suggest better solution.

Thanks in advance.