Skip to content

Latest commit

 

History

History
264 lines (186 loc) · 9.85 KB

RELEASE.md

File metadata and controls

264 lines (186 loc) · 9.85 KB
Raw

Releasing the Agent

To release the agent make sure you have the following configured on your workstation. We will ideally make this released by CircleCI or Jenkins at some point but for now the process is manual.

Note: The Windows release process is currently separate from everything else (see the "Windows Release Process" section below).

Setup

  1. Request prod access via slack and the splunkcloud_account_power role with okta-aws-setup us0.

  2. Ensure you are authorized to push images to the Quay.io Docker repository quay.io/signalfx/signalfx-agent.

  3. Ensure you are on the Splunk network and have access to the required credentials for artifactory and signing (check with an Integrations team member for details).

  4. Install Python tools to update the Python package in the python/ directory if it has changed since the last release:

    $ pip install --user keyring twine setuptools wheel

    Then set your password for Pypi by running the following command:

    $ keyring set https://upload.pypi.org/legacy/ your-username

Release Process

  1. Make sure everything that go out in the release is in the main branch. If so, checkout the main branch locally and ensure you are up to date with Github.

  2. Examine the differences since the last release. The simplest way to do this is to go to the releases page and click on the link for " commits to main since this release" for the last release. This will give you a commit list and diff in the browser.

    You can also do git cherry -v <last release tag> to see the commit summaries.

  3. Determine the next release version. If this is a very simple, non-breaking change or a simple addition to existing functionality, a patch release may be appropriate (i.e. only the last number of the version is incremented). If there are any breaking changes, it should be at least a minor release (i.e. the second number of the version increments and the last number resets to 0), if not a major release (where the first # of a release increments and the second and third component reset to 0). Major releases should be reserved for only very major breaking changes that are of high value.

    We roughly follow semver, but not terribly strictly and with the additional consideration that we are not only considering an "API" but also MTSs. For example, if you are going to make a change that would add a new dimension to existing metrics, given the same configuration, this is considered a breaking change since it would result in new MTSs in the backend.

  4. Update the deployment versions with the new version determined from the previous step (without the v) and commit/push the changes:

    $ ./scripts/update-deployments-version <version>

  5. If the Helm assets have changed bump the chart version number in Chart.yaml and commit/push the changes.

  6. If there are relevant changes in the python directory, bump the version in setup.py and commit/push the changes.

  7. Once you know the next release version, create an annotation tag of the form v<version> where <version> is that version. E.g. a release of 2.5.2 would need a tag v2.5.2. Annotated tags are created by passing the -a flag to git tag:

    $ git tag -a v2.5.2

    This will open your configured text editor and let you write the annotation. This should be of the form (assuming you are releasing version 2.5.2):

    2.5.2

- Did something to the agent
- Fixed this bug

Breaking Changes:

- This thing won't work anymore

    If there are no breaking changes, you can omit that section.

    Then push that tag with git push --tags.

  8. Run the release script:

    $ scripts/release --artifactory-token <splunk.jfrog.io token> --chaperone-token <chaperone token> --staging-token <repo.splunk.com token>

    This will run for several minutes and will build/sign/push the docker image, deb, and rpm. The linux bundle will be saved to ./signalfx-agent-<version>.tar.gz and will need to be manually uploaded to the Github Release. If there is an error, it will output on the command line. Otherwise, the output should say "Successfully released ".

  9. Build and release the certified RedHat container by running:

    $ scripts/release-redhat <X.Y.Z> <OSPID>

  10. Wait for the RedHat build to complete and then publish it.

  11. If the Helm assets have changed then update the repo from dtools/helm_repo by running (requires S3 access):

     AGENT_CHART_DIR=<agent dir>/deployments/k8s/helm/signalfx-agent ./update agent

  12. Test out the new release by deploying it to a test environment and ensuring it works.

  13. If the docs have changed since the last release, update the product docs repository by running the script scripts/docs/to-product-docs. If the README has been updated, you will also need to run the script scripts/docs/to-integrations-repo to update the agent tile contents, which is based on the README.

    To release product docs, first ensure that you have pandoc installed (on Mac you can do brew install pandoc). Next checkout the git repo github.com/signalfx/product-docs to your local workstation and run PRODUCT_DOCS_REPO=<path to product docs> scripts/docs/to-product-docs.

Windows Release Process

Setup

  1. You must be on the Splunk network and have access to the required credentials for signing (check with an Integrations team member for details).

  2. Request prod access via slack and the splunkcloud_account_power role with okta-aws-setup us0.

  3. You must have access to a Windows machine that is provisioned with the required build tools. Alternatively, you can build, provision, and start the Windows Server 2016 vagrant box. See the "Windows" section in development.md for details.

  4. Note: The Windows docker image is automatically built and pushed to quay.io in Azure Pipelines for release tags. Check Azure Pipelines and quay.io to ensure that the image was built and pushed successfully for the release tag.

Release Process

  1. Open a Powershell terminal in the Windows virtual machine and execute:

    PS> cd c:\users\vagrant\signalfx-agent
PS> .\scripts\windows\make.ps1 bundle -AGENT_VERSION "<X.Y.Z>"

    Where <X.Y.Z> is the release version.

  2. If the build is successful, verify that .\build\SignalFxAgent-X.Y.Z-win64.zip exists.

  3. Run the signing script from your local workstation to sign the agent executable in the bundle (must be on the Splunk network):

    $ scripts/signing/sign_win_agent.py --staging-token <repo.splunk.com token> --chaperone-token <chaperone token> build/SignalFxAgent-X.Y.Z-win64.zip

    The signed bundle will be saved to build/signed/SignalFxAgent-X.Y.Z-win64.zip.

  4. Build the msi with the signed bundle in the Windows virtual machine:

    PS> cd c:\users\vagrant\signalfx-agent
PS> .\scripts\windows\make.ps1 build_msi -version "X.Y.Z" -zipFile build\signed\SignalFxAgent-X.Y.Z-win64.zip

    The msi will be saved to .\build\SignalFxAgent-X.Y.Z-win64.msi.

  5. Run the signing script from your local workstation to sign the msi (must be on the Splunk network):

    $ scripts/signing/sign_win_agent.py --staging-token <repo.splunk.com token> --chaperone-token <chaperone token> build/SignalFxAgent-X.Y.Z-win64.msi

    The signed msi will be saved to build/signed/SignalFxAgent-X.Y.Z-win64.msi.

  6. Build the choco package with the signed msi in the Windows virtual machine:

    PS> cd c:\users\vagrant\signalfx-agent
PS> .\scripts\windows\make.ps1 build_choco -version "X.Y.Z" -msiFile build\signed\SignalFxAgent-X.Y.Z-win64.msi

    The choco package will be saved to .\build\signalfx-agent.X.Y.Z.nupkg.

  7. Release the choco package to chocolatey in the Windows virtual machine:

    PS> cd c:\users\vagrant\signalfx-agent
PS> choco push -d -k <choco api token> .\build\signalfx-agent.X.Y.Z.nupkg

    Re-run the command if it fails with System.OutOfMemoryException (known issue with chocolatey).

  8. Run the release script from your local workstation to push the msi and bundle to S3:

    $ scripts/release --stage <STAGE> --push --new-version <X.Y.Z> --component windows

    Where <STAGE> is test, beta, or release, and <X.Y.Z> is the same version from step 1.

  9. Install/deploy the new release by running the installer script in a Powershell terminal (replace YOUR_SIGNALFX_API_TOKEN and STAGE with the appropriate values):

    PS> & {Set-ExecutionPolicy Bypass -Scope Process -Force; $script = ((New-Object System.Net.WebClient).DownloadString('https://dl.signalfx.com/signalfx-agent.ps1')); $params = @{access_token = "YOUR_SIGNALFX_API_TOKEN"; stage = "STAGE"}; Invoke-Command -ScriptBlock ([scriptblock]::Create(". {$script} $(&{$args} @params)"))}

Github Release

  1. After completing the previous steps, create a Github release for the tag.

  2. Get the sha256 docker image digest by running:

    $ docker inspect --format='{{.RepoDigests}}' quay.io/signalfx/signalfx-agent:<version>

  3. Add the release notes including the deprecation notice and the docker image digest from the previous step (see previous releases for reference).

  4. Upload the ./signalfx-agent-<version>.tar.gz bundle, and the zip bundle and MSI from the ./build/signed directory to the release.

  5. Publish the release.