Yes as Phil said set the Project and each package to Don’t save sensitive.
I personally use 2 solutions. A development solution with 1 Visual Studio Configuration and a Release solution with a Visual Studio Configuration for each environment the Solutions will be deployed to, eg. Development, UAT, OAT, Production etc.
In the Development Solution I set the protection level to Encrypt with User Key.
In the Release Solution I set the protection level to Don’t Save Sensitive.
I use the Development Solution to test ideas, throw things away and play around with until I am happy. The packages only ever get run in the IDE. When I am happy I then import the SSIS package into the Release Solution and add the Parameters into the Configurations and set the values accordingly for each environment. Initially I deploy the solution using Project Deployment to Development server and set up my Agent Jobs for testing.
I always keep previous versions of the packages that have gone through for release in the Development Solution. That way I don’t lose any work and can easily scrap new ideas if they don’t work out and I am not always fishing for passwords when doing Dev work . Also it means there is only ever the current version in the Release that gets deployed.
You then only need to fish for passwords and set them up after the deployment is done. Either in the configurations in the SSIDB catalog or in each SQL Agent Job