FWIW, here is the high level overview of our process. I can elaborate
further as needed and can share some of my groovy scripts or additional
detail as needed.
1. *Jenkins*
1. *Build Step*
1. Build
2. Unit test
3. SonarQube analysis
4. Deploy artifact to Nexus
5. Post-build call to "TriggerGoPipeline" Job with the following
build parameters:
1. GO_PIPELINE
2. POM_GROUPID
3. POM_ARTIFACTID
4. POM_VERSION
5. POM_PACKAGING
6. CLASSIFIER (optional)
7. BUILD_ID (Jenkins build id)
8. BUILD_URL (Jenkins Job URL)
9. CHANGESET (from Perforce)
2. *TriggerGoPipeilne Step*
1. (Groovy Script) Query Nexus for build-specific information. In
the case of a SNAPSHOT build, I want the exact URL based on the
timestamp/incremental id:
1. Artifact URL
2. Artifact SHA1
3. FlywayDB schema version strings (from POM)
4. Build Final Name (from POM, tomcat context name)
2. (HTTP) Call GoCD API to schedule pipeline with the following
GoCD variables (via Query Parameters)
1. JENKINS_BUILD_ID
2. MAVEN_GROUP_ID
3. MAVEN_ARTIFACT_ID
4. MAVEN_VERSION
5. SHA1 (Nexus-generated SHA1 for build artifact)
6. REPO_URL (Nexus URL to build artifact)
7. FLYWAY_SCHEMA_VERSION (for db migrations)
8. BUILD_FINAL_NAME (tomcat context)
2. *GoCD*
1. *Generate build materials pipeline*
1. (Groovy Script) Validate parameters passed in from the build
and serialize to a PROPERTIES file material
2. *Prepare Materials - Pipeline*
1. (Git) Check out salt pillar data + templates
2. (Groovy Script) Process templates and inject build URL and SHA1
for Nexus
3. (Groovy Script) Process files to required Salt pillar + commit
to Git
4. Save pillar data as GoCD pipeline material
3. *Acceptance Test - Pipeline*
1. Get pipeline materials from Step 4
2. FlywayDB database migration to our MySQL databases
3. Salt deployment
1. SCP salt pillar data (Acceptance Test) to salt master
2. Deploy build to salt minion via salt-api
4. Validation (QA automated Tests)
1. (Git) Check out and build QA automation
2. Run functional tests
3. Publish Test results as a tab in GoCD
5. Approval to next Step
4. *Integration/System Test - Pipeline*
1. Get pipeline materials from Step 4
2. FlywayDB database migration
3. Salt deployment
1. SCP salt pillar data (Integration Test) to salt master
2. Deploy build to salt minion via salt-api
4. Validation (QA Integration Tests)
1. (Git) Check out and build QA automation
2. Run integration tests
3. Publish Test results as a tab in GoCD
5. Approval to next Step
5. *OPS Staging - Pipeline*
1. <Rinse and repeat>
6. *Production deployment - Multiple pipelines depending on scope of
production environments*
1. <Rinse and repeat>
Not sure if this is clear or not. Hopefully it conveys the high level
process. The devil is in the details though.
- Jeff
On Fri, Apr 7, 2017 at 10:52 AM, Kyle Flavin <[email protected]> wrote:
> Bharath, did you have success with this? We use Jenkins/Artifactory
> heavily, and it sounds like I'm trying to do something similar. We'd like
> continue to use Jenkins/Artifactory for our CI process, but then use GoCD
> for visualization of our workflows.
>
>
> On Monday, July 11, 2016 at 10:36:39 AM UTC-7, Bharath Reddy wrote:
>>
>> Jeff Vincent ,
>>
>> Thanks for the feedback. I am also trying to do the same. I have my
>> organisation building the code with Jenkins, integrated with GIT/Stash.
>> Once the code is build, the WAR and EAR files are going to be uploaded into
>> articatory and also, a copy will also be maintained in Stash.
>> My plan is to enable GoCD to pick the EAR/WAR from either Stash or
>> Artifactory and deploy onto the target servers.
>> I am also planning to use pipelines, where I want to introduce manual
>> approval from ITO team for UAT deployments and PMO approval for production
>> deployments.
>>
>> I am new to this to this tool chain, I would ask if you can help me with
>> some suggestion on how I can achieve this.
>>
>> Thanks
>> Bharath
>>
>> On Wednesday, March 16, 2016 at 3:41:04 AM UTC+5:30, Jeff Vincent wrote:
>>>
>>> Because GoCD isn't Maven aware whilst Jenkins is. GoCD can run Maven
>>> build commands, but to handle multiple dependencies on other Maven
>>> projects, you must manually manage the build order/hierarchy in GoCD.
>>> Jenkins does this implicitly and requires no manual intervention.
>>>
>>>
>>>
>>> On Tue, Mar 15, 2016 at 3:32 PM, Mirko Friedenhagen <[email protected]
>>> > wrote:
>>>
>>>> Hello Jeff,
>>>>
>>>> could you outline why you use two different tools here? Why not use
>>>> go.cd for building as well?
>>>>
>>>> Regards
>>>> Mirko
>>>> --
>>>> Sent from my mobile
>>>> Am 15.03.2016 00:27 schrieb "Jeff" <[email protected]>:
>>>>
>>>>> We are using SaltStack and pulling down the WAR file directly from our
>>>>> Sonatype Nexus Maven Repository Server. However we don't use GoCD to do
>>>>> the builds, we use Jenkins-CI to do the WAR build + deploy to Nexus then
>>>>> runs a Groovy script to gather metadata information about the artifact
>>>>> (SNAPSHOT version, URL, SHA1, POM info, etc.) then pushes to the GoCD
>>>>> pipeline (via GoCD ReST API) using the Jenkins build parameters including
>>>>> Nexus SNAPSHOT version, URL, etc.
>>>>>
>>>>> On Mon, Mar 14, 2016 at 4:23 PM, Magnus Lyckå <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Ansible is a nice and simple tool. You'll obviously need it on the
>>>>>> go-agent, but there is nothing special that needs to be installed on your
>>>>>> target hosts. It just needs to be accessible via ssh and have a shell and
>>>>>> python2.
>>>>>>
>>>>>> https://github.com/ansible/ansible
>>>>>> https://github.com/ansible/ansible-examples
>>>>>>
>>>>>> Fabric is another option. Then you don't even need Python on the
>>>>>> target hosts, but you need to write some Python...
>>>>>>
>>>>>> http://www.fabfile.org/
>>>>>>
>>>>>> You could probably get away with running the same shell script as in
>>>>>> Jenkins though...
>>>>>>
>>>>>> Den tisdag 23 februari 2016 kl. 09:04:49 UTC+1 skrev [email protected]:
>>>>>>>
>>>>>>> What's the best practice of deploying the build artifacts,like a war
>>>>>>> file, to the PRO environment.
>>>>>>> In jenkins we often use a shell script to upload the war package by
>>>>>>> SSH. What's your solution?
>>>>>>>
>>>>>>> Regard,
>>>>>>> Anan Hong
>>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "go-cd" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeff Vincent
>>>>> See my LinkedIn profile at:
>>>>> http://www.linkedin.com/in/rjeffreyvincent
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "go-cd" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "go-cd" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Jeff Vincent
>>> See my LinkedIn profile at:
>>> http://www.linkedin.com/in/rjeffreyvincent
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
