• Anaconda Platform
  • – Welcome
  • – Anaconda Distribution
  • – Anaconda Repository
    • User guide
    • Administration guide
    • FAQs
    • Help and support
    • Release notes
    • Command reference
    • Glossary
    • License
    • Previous versions
      • Anaconda Repository 2.32
      • Anaconda Repository 2.31
      • Anaconda Repository 2.30
      • Anaconda Repository 2.29
        • User guide
        • Admin and install guide
          • Install Anaconda Repository (AER 2.29)
          • Update/Uninstall Anaconda Repository (AER 2.29)
          • Anaconda repository command line interface (AER 2.29)
          • Adding a PyPI or Anaconda mirror to your Anaconda repository installation (AER 2.29)
          • Cross platform (“Noarch”) package support in Anaconda repository (AER 2.29)
          • Jupyter notebook support in Anaconda repository (AER 2.29)
          • Recommended Workflow (AER 2.29)
          • Anaconda repository changelog (AER 2.29)
          • Configuration reference (AER 2.29)
          • Anaconda repository end user license agreement (AER 2.29)
      • Anaconda Repository 2.28
      • Anaconda Repository 2.27
      • Anaconda Repository 2.26
      • Anaconda Repository 2.25
      • Anaconda Repository 2.24
      • Anaconda Repository 2.23
  • – Anaconda Accelerate
  • – Anaconda Adam
  • – Anaconda Enterprise Notebooks
  • – Anaconda Fusion
  • – Anaconda Scale
  • – Anaconda Cloud
  • Anaconda-sponsored OSS programs
  • – Blaze
  • – Bokeh
  • – Conda
  • – dask
  • – llvmlite
  • – PhosphorJS
  • – Numba
  • – Cython

Recommended Workflow (AER 2.29)¶

One of the most useful features of Anaconda Repository is its ability to help you manage package development and deployment in a seamless fashion. Below you can find a write-up of the actual development process and channel usage employed by one of our internal teams.

Leveraging Channels for Workflow Separation¶

Using multiple channels allows your team to maintain separate package states and easily earmark and control the versions and states of packages that users can install. For example, your team might create the following channels:

  • master
  • staging
  • release

Master is created any time something is merged into our master branch. It’s considered the development build of all of the components that make up the software. Code that makes it to this should be stable and have been confirmed independently, but a full QA test has not been run on it yet.

Once we’re ready to start working on a release, we create a staging:X.Y.Z branch. This contains all code that’s going to go into a release. No new features should be introduced at this point, just any last minute bug fixes to existing code.

The staging channel gets culled so only the latest package is maintained in it – any alpha, beta, or dev packages are removed. After all testing is complete, all issues are resolved, and the channel contains only one version of each package, we copy that package into a release:X.Y.Z channel, then lock that channel.

We’ve used this through 4 release cycles and so far it’s worked out well for us.

Docs Home
Anaconda Home
More Help & Support
2017 Anaconda, Inc.
All Rights Reserved.
Privacy Policy | EULA