There are lots of answers to this and I am not going to pretend I know the
"right" answer for you, but here are a few things you may want to consider
when figuring things out:
* In this "pipeline" of jobs you describe, only the initial build has
access to the source repository - rest use artifacts from other jobs to
perform the next phase of the process
* Deployment process is typically consistent of two parts - a part that is
specific to the your environment/organization but not specific to release
you are deploying and part that is specific to the particular version you
are deploying. While the line is often blurry, you are much better off not
mixing them - and keeping the non-deployment specific bits in a separate
repo. That is your Deployment Job, which is independent of the particular
version you are deploying. So, changes in org/env specific process are
pretty much independent of the changes in your project or changes in how to
deploy your artifacts - so it makes no sense to version them together and
store in one repo
* The Global Libraries are a pretty handy place to store common workflows -
like your global environment/org deployment process. Alternatively you can
just run an independent repo for that part as it is an independent
project/codebase
* Deployment artifact is a good place to include release specific
deployment instructions - there is nothing stopping you from creating an
additional deployment artifact that contains not only your code build, but
also instructions on specific steps to deploy this particular version. You
can even package those instructions as a pipeline script which gets
executed from your other job. You can even have multiple jobs for different
phases of the deployment process.
That should hopefully put you on the right path for your needs.
-M
On Friday, October 28, 2016 at 4:02:52 AM UTC-7, Graham Hay wrote:
>
> This is interesting, it's something I've been struggling with while
> converting our current system over to the new world (I really like the
> stage view!).
>
> We currently have a "pipeline" of freestyle jobs, that pass artifacts down
> the line. Build (and test) -> Deploy to stage -> Deploy to prod. The last
> build uses pinned artifacts ("keep forever"), which allows us to rollback
> by unpinning the latest build. This is something I'd like to keep.
>
> The one thing I don't understand is where I would define the deploy jobs?
> Isn't the whole point that everything is now in the Jenkinsfile, and under
> version control? Also, I don't seem to be able to point my existing
> freestyle job at the new pipeline build job, to retrieve artifacts. So what
> am I missing?
>
> Thanks,
>
> Graham
>
> On Wednesday, October 26, 2016 at 4:26:17 PM UTC+1, Michael Lasevich wrote:
>>
>> I am not sure the stages you are talking about are same as what Jenkins
>> Pipelines calls stages.
>>
>> Jenkins, at its core, is a job server. In Pipelines, a stage is a segment
>> of a job. Stages of a build job would be something like "Build Binaries" or
>> "Upload Build Artifacts" - something that is part of one logical job. What
>> you are talking is a deployment process which is really a separate job from
>> a build job, and not really a "stage" of build.
>>
>> So, my approach would be (and is, in some cases):
>>
>> * Set up a Pipeline build for the develop branch
>> * Make sure the build job archives either deployment artifact(s) or
>> pointer to them - something that can be used for deployment.
>> * Set up a separate deployment job (can also be Pipeline) that takes in
>> parameters for a build run and target environment (stage, QA, UA, PreProd,
>> Production, whatever), and grabs artifacts/pointers from the selected run
>> and performs a deployment
>>
>> Now, if you want to get fancy, you make that first "build" job a
>> MultiBranch job that builds both develop and some versions of the feature
>> branches (I've used /feature/build/* pattern) and then modify the selection
>> of the job run to select from multiple branches (need to write a Groovy
>> based Parameter selector for that) - and now you can deploy builds from
>> feature branches for testing BEFORE they are merged into develop
>>
>> HTH,
>>
>> -M
>>
>>
>>
>>
>>
>>
>>
>> On Wednesday, October 26, 2016 at 4:21:23 AM UTC-7, Sathyakumar
>> Seshachalam wrote:
>>>
>>> New to Jenkins pipeline.
>>>
>>> My process is that developers work off of develop branch (Feature
>>> branches and merges of-course).
>>> At any point in time, a release branch is branched off of develop and
>>> then deployed to a stage environment, Once Accepted/approved, the same
>>> release branch is deployed into prod. (All immutable deployments).
>>>
>>> So am looking at atleast two stages that are only conditionally and
>>> manually entered - stages being deploy to stg, deploy to prod and
>>> condition being the branch prefix. (Each stage will have build steps like
>>> deploy binaries, launch, run functional tests etc.,) and an automatic stage
>>> that is triggered only once per day (nightly) with build steps like deploy
>>> binaries, lunch, run and tear down).
>>>
>>> Is this kind of a workflow feasible with pipelines. If yes, Are there
>>> any recommendations/suggestions/pointers.
>>>
>>> Thanks,
>>> Sathya
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/d649de8e-104f-4a3e-adfc-28054c562b30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
