Learning Path review questions: LP07

Learning Path review questions

1. If you are creating a feed that will allow yourself and those that you invite to publish, what visibility should you choose?

Answer:

You should choose Private visibility for the feed. A private feed ensures that only the invited users or users with the appropriate permissions can access, publish, and manage the packages within the feed.

• Public visibility would make the feed accessible to everyone, but it would not meet the requirement of restricting publishing access.

• Private visibility limits access to only authorized users or groups, which is what you're aiming for when only certain individuals should be allowed to publish.

2. Can you create a package feed for Maven in Azure Artifacts?

Answer:

Yes, Azure Artifacts supports Maven as a package type. You can create a feed specifically for Maven packages in Azure Artifacts.

Azure Artifacts provides full support for Maven repositories, allowing you to store, publish, and manage Java-based packages. You can set up a Maven feed in Azure Artifacts, configure your pom.xml or settings.xml to point to the feed, and use Maven commands to publish and consume packages.

3. What type of package should you use for Machine Learning training data & models?

Answer:

For Machine Learning (ML) training data and models, you typically use custom or data packages. In Azure Artifacts, you can use packages such as NuGet or Python packages (PyPI), but for machine learning data and models, it is most common to use custom formats depending on the workflow. Some options include:

• TensorFlow models: Can be stored in a .tar.gz format or as custom model containers.

• Python Packages (PyPI): Store machine learning models as Python packages in .whl or .tar.gz formats.

• DVC (Data Version Control): DVC is commonly used for tracking datasets and models, although this is more for version control than direct Azure Artifact usage.

The exact choice of package depends on how the ML models and data are structured in your environment.

4. If an existing package is found to be broken or buggy, how should it be fixed?

Answer:

If an existing package is broken or buggy, it should be fixed by creating a new version of the package. In an immutable package repository (like Azure Artifacts or GitHub Packages), you cannot change or overwrite a published package once it has been published. Instead, the fix involves:

• Fixing the issue in the code or package: Modify the source code or data that caused the bug.

• Bumping the version: Follow semantic versioning (e.g., 1.0.0 → 1.0.1) to indicate that this is a new version of the package.

• Publishing the new version: After the fix, publish the new version of the package to the feed.

This approach ensures that consumers can access the fixed version of the package without breaking backward compatibility.

5. What is meant by saying that a package should be immutable?

Answer:

Immutability of a package means that once a package is published to a package feed, it cannot be changed or modified. If any updates or fixes are required, a new version of the package must be created and published.

This approach is essential for ensuring that the packages remain consistent and stable for all consumers.

Immutability helps prevent scenarios where an updated package might break existing applications or workflows that depend on the specific version of the package. Instead of updating or overwriting the existing package, a new version is created, ensuring backward compatibility and predictability in software dependencies.