Microsoft Azure is an ever-expanding set of cloud services to help your organization meet your business challenges. It is the freedom to build, manage and deploy applications on a massive, global network using your favorite tools and frameworks.
Why Azure is the right choice
1.Productive:- Reduce marketing cycles by delivering features faster with more than 100 end-to-end services.
2. Hybrid:- Develop and deploy where you want, with the only consistent hybrid cloud on the market. Extend Azure on-premises with Azure Stack.
3.Intelligent:- Create intelligent apps using powerful data and artificial intelligence services.
4. Trusted:- Join startups, governments and 95 percent of Fortune 500 businesses who run on the Microsoft Cloud today.
A Blueprint is a reproduction of a technical drawing using a contact print process on light-sensitive sheets. The blueprint process was characterized by white lines on a blue background, a negative of the original. The process was not able to reproduce color or shades of grey. They are used to ensure that the final products are built to specifications and in compliance with certain standards and requirements.
Azure Blueprints are used in much the same way as traditional blueprints. IT engineers can use Azure Blueprints to design and deloy a repeatable collection of Azure resources that adhere to certain requirements and standards.
Objects are replicated to multiple Azure regions to provide both highly available and low-latency access to those objects, regardless of where the Azure Blueprints objects are deployed. Azure Blueprint allowed the IT professional to orchestrate the deployment of resource templates and other Azure artifacts, including role assignments, policy assignments, resource groups, and resource manager templates.
The Lifecycle of an Azure Blueprints
Most resources in Azure have a natural lifecycle. Blueprints in Azure Blueprints are no different as they are created and then deployed. When they are no longer needed, they are deleted. Azure Blueprints provides support for typical continuous integration and for continuous deployment pipelines for companies that manage infrastructure as code.
To fully understand a blueprint and the stages, we’ll cover a standard lifecycle:
- Creating and editing a blueprint
- Publishing the blueprint
- Creating and editing a new version of the blueprint
- Publishing a new version of the blueprint
- Deleting a specific version of the blueprint
- Deleting the blueprint
Creating and editing a blueprint
When creating a blueprint, add artifacts to it, save to a management group or subscription, and provided a unique name and a unique version. The blueprint is now in a Draft mode and can’t yet be assigned. While in the Draft mode, it can continue to be updated and changed.
A never-published blueprint in Draft mode displays a different icon on the Blueprint Definitions page than ones that have been Published. The Latest Version is also displayed as Draft for these never published blueprints.
Publishing a blueprint
Once all planned changes have been made to a blueprint in Draft mode, it can be Published and made available for assignment. The Published version of the blueprint can’t be altered. Once Published, the blueprint displays with a different icon than Draft blueprints and displays the provided version number in the Latest Version column.
Creating and editing a new version of the blueprint
A Published version of a blueprint can’t be altered. However, a new version of the blueprint can be added to the existing blueprint and modified as needed. Make changes to an existing blueprint by editing it. When the new changes are saved, the blueprint now has Unpublished Changes. These changes are a new Draft version of the blueprint.
Publishing a new version of the blueprint
Each edited version of a blueprint must be Published before it can be assigned. When Unpublished Changes have been made to a blueprint but not Published, the Publish Blueprint button is available on the edit blueprint page. If the button isn’t visible, the blueprint has already been Published and has no Unpublished Changes.
1. A single blueprint can have multiple Published versions that can each be assigned to subscriptions.
2. To publish a blueprint with Unpublished Changes, use the same steps for publishing a new blueprint. Deleting a specific version of the blueprint
Each version of a blueprint is a unique object and can be individually Published. As such, each version of a blueprint can also be deleted. Deleting a version of a blueprint doesn’t have any impact on other versions of that blueprint.
It’s not possible to delete a blueprint that has active assignments. Delete the assignments first and then delete the version you wish to remove.
1. Click on All services and searching for and selecting Policy in the left pane. On the Policy page, click on Blueprints.
2. Select Blueprint Definitions from the page on the left and use the filter options to locate the blueprint you want to delete a version of. Click on it to open the edit page.
3. Click the Published versions tab and locate the version you wish to delete.
4. Right-click on the version to delete and select Delete This Version.
Deleting the blueprint
The core blueprint can also be deleted. Deleting the core blueprint also deletes any blueprint versions of that blueprint, including both Draft and Published blueprints. As with deleting a version of a blueprint, deleting the core blueprint doesn’t remove the existing assignments of any of the blueprint versions.