Database Engine and SSISDB architecture advice
This is a culture change as much as it a process change, so having management support you will be important, and ultimately shield you from some level of technical resistance and aid in broadcasting how this strategic shift will improve the lives of everyone. 

Before we get into the specific case of the SSIS Catalog, let’s look at an overview of your options to better arm you with the knowledge to communicate why developers should change their system:


File system 


Individual Package are stored on any folder, any location.
No security, files can be modified by any user or process without prior knowledge and no process natively exists to prevent this from occurring.
Not part of the regular backup schedule. System snapshots are not a viable backup and do not prevent accidentally modifications that can cause irreparable damage.
Must manually organize packages and no ability to group packages outside physical location and/or documentation
Forced to use Configuration Files to parameterize values

SSIS Package Store  


Packages by default are stored specific folder “C:\Program Files\Microsoft SQL Server\&lt;SQL Version Compiled>\DTS\Packages”. Can be moved.
Limited security; can be modified by elevated permissions
Not part of any backup strategy outside system snapshots (again, NOT A VALID BACKUP SOLUTION)
Can organize packages under Folders
Cannot use roles to restrict access to packages from the SSIS Package Store 

SQL Server (msdb)  


Packages are stored in msdb and can be exported to a file-share. 
Security is tied to access to msdb.
System msdb is part of a valid backup solution. 
Cannot be added to an AlwaysOn solution
Folders can be used to categorize
Can use Roles to manage permissions in 2016+ that avoid using sysadmin. Integration Services Roles (SSIS Service) - MS Docs

SSISDB Catalog 


Packaged are stored exclusively inside SSISDB that is encrypted with a certificate
Security is further strengthened by separate permissions and roles (see above link).
SSISDB is part of a valid backup solution
SQL Server 2016+ has added support for AlwaysOn! SQL Server 2016 HA Series Part 2 – SSIS and Availability Groups – Blogs Microsoft
Mature management hierarchy that includes Parameters, Environments Variables.
Offers Full integration with Visual Studio
SQL Agent Jobs no longer directly use configuration file references or actual passwords (hope no one is doing this anyways) from being scripted out from SSMS. 




  Ultimately, you can decide what path will work for your organization.
  SSIS Catalog is one of several methods, so getting your management to
  support you in this endeavor will go a long way to making changes.
  After describing an example scheme for deployment, the rest of this
  post will highlights some Visual Studio Management and SSIS Catalog
  Tips.


An example scheme could be the following:


All new efforts will use [Visual Studio] 2017 or 2015 for backwards compatibility and SQL Server Data Tools - (Download SQL Server Data Tools (SSDT) - docs.microsoft.com).
o   note in VS 2019 they added this as a marketplace component)
projects will be saved in the code management folder (GitHub folder) so efforts are versioned or they will use the SSIS Catalog on a DEV environment, though ideally use the GitHub Repository. 
Package components are installed on each node for Dev/Cert environments first. The Enterprise DBA assists in gathering these downloads in a single file-share for ease of access/ transportation to target clustered servers and ensures they are on each target server.


BONUS SECTION:

Visual Studio Management Tips:


Your Package depends on both the Deployment Version (must match Integration Services of SQL Server instance) 





And the 32-bit/64-bit configuration depending on the components used.



In order to use the Parameters, you must either user a package “parameter” (not variables) or Project Parameter. You an use these to environmentally control what connections are used. 






You can connect and deploy to your target location (it doesn’t HAVE to use the SSISDB)





SSISDB Catalog Management Tips:

1)  You can Restore Versions with a click of a button to undo negative changes or even revert forwards!

 

2)  You can manage project parameters, validate, control versions from SSMS. No VS required.




Configure the Environment Parameters from here:






Passwords, unlike in the SQL Server Agent jobs, are securely protected inside the SSISDB database.


Example: 

EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'&lt;name of step&gt;', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=3, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'SSIS', 
        @command=N'/ISSERVER "\"\SSISDB\Replication\SSISDB_Replication\SSISDB_Replication.dtsx\"" /SERVER &lt;ServerName&gt; /ENVREFERENCE 3 /Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E', 
        @database_name=N'master', 
        @flags=0


3)  Each SQL Server Agent Job then uses these parameters after you select the environments set.


Pick the Package Source SSIS Catalog. 





Set the environment for your variables. 


 


In most cases, the parameters will automatically be set.




4)  Check what actually went wrong inside SSMS without resorting to RDPing into your server. 



5)  See performance between runs that uses real statistics!



Am I missing anything? Feel free to make this a community answer.