Skip to content

Latest commit

 

History

History
43 lines (30 loc) · 3.55 KB

developer_workflow_promote_release_integration.md

File metadata and controls

43 lines (30 loc) · 3.55 KB
Raw

Developer workflow: Promote an integration update

Using Package Storage (V1)

Prerequisites

  • elastic-package (builder tool) installed - follow the Getting started guide to install the tool.
  • There is a PR open to the Package Storage/snapshot with your built integration. This will be done automatically by the Integrations repository CI when it detects an unreleased version of your package in the Integrations repository.
  • You have a fork of https://github.com/elastic/package-storage in your account.
  • Setup a Github token and place the hash in $HOME/.elastic/github.token.

Steps

  1. Please review this PR on your own and if the CI is happy, merge it. Your PR will be made against a base branch that corresponds to the stage that you will be pushing this package into for testing/deployment (e.g. "snapshot", "staging", etc). This will be referred to in the following steps as your "target stage".

  2. Release changes to the stage using 1-click Jenkins form (need to be signed in). Remember to wait until the build has finished before triggering a release. Note: triggering a release will push all changes that have been merged to the target stage branch.

  3. Test your package update - point a running Kibana at your target stage's package registry URL using the Fleet Kibana settings

  4. Once happy with the changes in your target stage, promote your package to the next stage using the elastic-package tool.

    elastic-package promote

    The tool will walk you through some options and open 2 PRs (promote and delete) to the package-storage: target and source branches.

    Please review both PRs on your own, check if CI is happy and merge - first target, then source. Once any PR is merged, the CI will kick off a job to bake a new Docker image of package-storage (tracking). Ideally the "delete" PR should be merged once the CI job for "promote" is done, as the Docker image of previous stage depends on the later one.

  5. GOTO Step 2

Using Package Storage V2

Package Storage V2 is the successor of the package-storage Git repository. You can find more info about this here.

This new storage is already set up in this repository. Everytime a new version of a package is merged, that version is built and published into this storage automatically. Jenkins stage where this step is performed: Publish to Package Storage V2.

This storage is based completely in semantic versioning to release the packages as snapshots, technical previews or stable versions. More info about the versioning here.

Considerations until Package Storage V1 is deprecated here.