This is a Job-DSL seed job written in Declarative Pipeline that pulls in your Organization based on a build parameter and creates two jobs for every repo:
1. A multibranch Pipeline job that is based on the Jenkinsfile that will work across all branches and PRs.
2. A deploy job for the repo that is defined in a "jenkinsfile.deploy" file in the repo. This isn't a multibranch job but can be run on any branch based on a parameter for the branch.
This is a very simplistic implementation but could be expanded on further.
Why do you need them to be separate Pipelines? Because it is convenient or for other reasons?
Do you want everyone of these jobs in every branch that you create? In Pull Requests? Do you want all of these jobs to automatically trigger on every push the repo?
It's possible to do all of these steps in a single Pipeline but I'm curious why you would want to separate it?
We want to run our integration tests, etc. against our per-branch staging environment and then against prod when we deploy the branch there as well. With a "post-deploy" pipeline file, we can keep that logic nice and clean and easily trigger the appropriate job via the API.
With everything in one file, we would have to add the logic to our Jenkins pipeline to handle when to trigger deployments (which is currently done through a service we built that looks at GitHub commit statuses of a certain prefix/listens to Slack slash commands).
