[FOLIO-317] Identify and implement FOLIO software release process Created: 13/Sep/16  Updated: 12/Nov/18

Status: In Progress
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Umbrella Priority: P2
Reporter: John Malconian Assignee: Jakub Skoczen
Resolution: Unresolved Votes: 0
Labels: sprint6, sprint7, sprint8
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: 3 days Time Spent: 1 day, 4 hours
Σ Original Estimate: Not Specified Original estimate: Not Specified

Issue links:
Blocks
blocks FOLIO-333 improve integrated release management... Open
is blocked by STRIPES-158 tag and release v0.1* and establish r... Closed
Sub-tasks:
Key
Summary
Type
Status
Assignee
FOLIO-338 Create Docker Repository on Docker Hub Sub-task Closed John Malconian  
Sprint:

 Description   

Identify the ideal method for triggering FOLIO software and how this can be implemented into Jenkins to automate the "release" build and post-build steps of deploying packages, containers, and artifacts to their respective repositories.



 Comments   
Comment by John Malconian [ 20/Sep/16 ]

I was able to configure a Jenkins job that roughly does the following to create a "release". In this case, I forked Okapi (http://github.com/funkymalc/okapi and released 'v0.4' as a test.

Pre-Build:

  • Manually configure the following parameters for build: - and 'releaseVersion' and 'developmentVersion'. 'releaseVersion' is the version we are releasing and 'developmentVersion' is the next SNAPSHOT version after release version.
  • Git checkout of Okapi 'master' branch
  • Clean Jenkins workspace

Build:

  • Utilize Maven release plugin to manage Maven release process. i.e. 'mvn release:clean release:prepare release:perform -DreleaseVersion=$ {releaseVersion} -DdevelopmentVersion=${developmentVersion}

    Maven release updates the POMs, performs a release build, creates the git release tag - v${releaseVersion}

    , and updates the POMs again to the next $developmentVersion. Maven artifacts are deployed to Nexus Maven Release repository at 'repository.folio.org'. Nothing is pushed to GitHub at this point.

Post Build:

  • This is where we can add additional testing if desired. Actual integration tests and so forth. It is also where we can deploy other things like Docker images, distro-specific linux packages, documentation, etc.

The very last Post-Build step is a 'git push' to the master branch. This should be at the very end in case any previous steps fail before it. This will push the new POMs with the new SNAPSHOT version. It will also push the release tag and create a GitHub release (zip file, etc).

Let me know if this process works overall. Specifically, creating the release from 'master' and whether you think updating the master branch from the build system is ok. Note, there is no step here that creates a 'release branch' in GitHub for ongoing management of a particular release in a distinct release branch. If that is something we are going to do, then, at this point, the branch would be created manually after the release although I'm sure we could automate that as well.

Comment by John Malconian [ 21/Sep/16 ]

Updated distributionManagement maven repository to 'repository.folio.org'. PR 188 merged with master.
https://github.com/folio-org/okapi/pull/188

Comment by John Malconian [ 28/Sep/16 ]

Posted document describing the components and automated processes associated with building, testing, and deploying FOLIO projects here: https://github.com/folio-org/okapi-infrastructure/blob/master/doc/folio_automation.md

Comment by John Malconian [ 06/Jan/17 ]

The document has moved to http://dev.folio.org/doc/automation

I think I've taken this about as far as I can go for now. We probably want to add some kind of documentation about semver. Reassigning back to Jakub for additional thoughts.

Generated at Thu Feb 08 23:04:52 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.