Manage Projects and Phases
Projects enable enterprises to create a workflow to manage their devops process in CloudCenter. The devops process may involve different stages (phases) such as Development, Test, Stage, Production and so forth. Each phase can have its own participants, environments for deployment, budget, as well as resource constraints. Applications would have to go through these phases before going live.
CloudCenter already has the concept of Deployment Environment with additional Governance Rules and System Tags and various integration points like the Jenkins plugin. However, the devops process has to be indirectly modeled using Access Control on Deployment Environments to move an application from one environment to another.
Using the CloudCenter Projects feature, enterprises can create a workflow to represent their devops process, setup participants and environments, and enforce monetary and resource limits from one central location.
A project allows you to:
Create and configure various phases that map to the devops process.
- Identify permitted users
- Choose participant applications
- Impose budget and resource limits
A project does not allow you to:
- Define application profiles – You must define Application Profile first before associating them with a project.
- Create users – You must Create Users in CloudCenter before adding them as participants.
CloudCenter project participants include:
- Admin/Project Manager: A project manager may be a tenant admin or any user that is assigned the Project Admin role and has the ability to perform the following functions:
- Create a project.
- Define lifecycle phases (each phase is a Deployment Environment – already created, or can be newly created)
High-Level Project Flow
Projects follow this workflow:
- The tenant admin/project manager creates a project and adds participants.
- The project manager:
- Adds the phases and associates plans with them.
- Adds participants for each phase to projects.
- Project users make phased deployments on a day-to-day basis.
Promote a deployment to the next phase.
Approve the promotion (of the next phase).
- Permitted users deploy the application in the approved phase.
Create a Project
To create a project, follow this process:
- Access the CCM UI and click Deployments > Projects (default tab).
Click the New Project button to create a project. The Create Project popup displays.
The New Project button is only visible to users who have permission to create projects. Be sure to assign the Project Admin role to the required user(s).
- Provide a Name and Project Budget for this project.
Select the Usage Plan Type for the entire project. You can only assign a plan to a phase if the plan fees include the cloud usage costs.
Once selected, the plan type applies to all phases of the project. The corresponding plan for the phase is used for billing purposes and tracked based on either budget or VMs, but not both.
- Select the Application Profiles that can be deployed with this project.
- Click Continue to proceed to the Share popup.
Identify the users who can view this project, modify the project, or have the ability to share this project with others.
Project are only displayed in the Project owner's dashboard. Even if other users are added to it, it will show up in the user dashboard after the project is published.
Click Save to save the permissions assigned to the users for this project and proceed to the project board
- Click Add a Phase and provide a phase name.
Choose a phase type, (the deployment environment to be associated with this phase) or click New Deployment Environment to create a new one.
The same deployment environment cannot be used by two phases.
- Choose an appropriate plan for this phase based on the project budget type.
Add the participants of the phase.
Any change you make in the sharing permission for each Phase is automatically saved for the underlying deployment environment's permission as well.
- Review all phases for this project as required by your enterprise.
- Modify permissions for each phase, if required.
- Click Save as Draft until you configure all project details.
- Click Publish when you have configured all the project details.
You can view each project by accessing the CCM UI > Deployments > Projects link. This end-to-end view allows you to see projects, the phases for each project, and the status indicators for your application deployments.
Deployments made using the Projects link can only be viewed and managed through the Projects dashboard.
Click any project in the Project name page to drill down into the project.
The Project name page provides color-coded indicators for each phase.
|Red||This deployment status is Errored or Rejected (approval is rejected by the phase approver).|
|Orange||This deployment phase is suspending, suspended or pending approval.|
|Green||This deployment is in progress or deployed.|
|Grey||This deployment has been terminated.|
Draft vs. Published Mode
If a project does not have associated phases and application, you cannot publish a project. Once published, you cannot move the project back to the Draft mode.
When you save a project, the phase attributes (Bundle, Plan, Phase Name, and Deployment Environment) behavior differs based on the mode in which the project was saved:
|Operations||Project in Draft Mode||Published Project|
|Change deployment environment of a phase||Allowed||Not Allowed|
|Add additional bundle credits for a phase||Not Allowed|
Operations highlighted in the image below are permitted for a published project based on user privileges.
The following table identifies the allowed operations. The operations that are not allowed will not be visible:
User Privileges →
|Sharing & Access||Not allowed||Not allowed||Allowed|
|Delete||Not allowed||Not allowed||Allowed|
Irrespective of the above privileges for a project, the Add Deployment link is disabled if a user does not have the Deploy To privilege for the deployment environment associated with a phase.
You can promote deployments from one phase to another in the Project name page, if you have the required permissions and if you have configured multiple phases.
The Promote action also triggers the approval request, if configured. With each change and approval, notifications continue to be sent to permitted users.
When promoting projects, you are not migrating a deployment. You are merely tying that deployment to separate settings, networks, and so forth.
What you leave behind, can remain as a copy of that deployment in the previous phase.
The cost of a project is the aggregate of its constituent phase costs. The cost of a phase is based on the plan associated with the phase (see Usage Plans and Fees and Cost and Fees for additional context).
To use a pre-paid budget plan, make sure that a budget bundle is already created. See Configure Bundles for additional context.
The type of plan that is associated with a phase should match the budget type of a project. For example:
- If the budget type for a project is Pre-paid Budget, then only a pre-paid budget plan can be associated with its phases.
- If the budget type of a project is VMs, then only a VM Subscription plan can be associated with a phase.
For a plan to be associated with a phase, it MUST also include the cloud costs.
Additional Seed Credit
To add seed credits to a phase of the published project:
|Project Plan Type||Process Dependencies|
Add additional pre-paid budget bundles
The pre-paid budget bundles need to created prior to making any additions.
|VM Subscription||Change the phase plan – to a different plan with a higher VM limit.|
Budget and Billing
Once you set the budget type (using a currency or VM specification), the project budget is determined in terms of currency or number of VMs. You can change the project budget at a later point, if required.
The project details page shows the quantity of budget consumed. This details are displayed as described in the following table:
|Project Budget Consumption Indicator||Description|
|Red||If the budget usage exceeds 100%|
|Orange||If the budget usage is between 80-100%|
|Green||If the budget usage is less than 80%|
The cost associated with a project is billed to the project manager. Any overage fees incurred while running a deployment within a phase is also charged to the project manager as part of their monthly bill.
Once the phase credits are exhausted, project managers can refill the credit by adding additional bundle credits. The bundle costs are reflected in this user's monthly bill. See Financial Overview, Cost and Fees, and Tenant Billing for additional context.
Out-of-Box Jenkins Plugin
CliQr provides an updated out-of-box Jenkins plugin to integrate the build process with the projects in CloudCenter. This can be used to provision an application into particular phase in a project.
You can use this CloudCenter plugin in conjunction with the Jenkins artifactory plugin to push artifacts generated by a build process into a repository.
Storage options like artifactory, S3 etc., can be modeled in CloudCenter as artifact repositories. SeeShare Artifact Repositories for additional context.
Once the artifacts are uploaded to a repository (modeled in CloudCenter), use the CloudCenter plugin to deploy the application to a particular project phase. The application thus deployed picks up the generated application artifacts present in the artifact repository.
You cannot create or configure a project using the CloudCenter Jenkins plugin. You can only deploy to an existing project/phase.
To create/configure a project use the CCM UI (this page) or CCM APIs (see Create Project).
Add a Deployment to a Project Phase
To add a deployment to a published project, follow this process.
Click Add Deployment in the required project phase.If the Deploy To privilege is not checked for a user in the underlying deployment environment of the phase, then the Add Deployment link is disabled for this user.
Select the out-of-box Application Profile.When you click the Add Deployment link, the following dependencies apply:
- If an Application is not shared with the user, then the user does not see the application listed.
- If a user does not have Deploy privilege on the App, then the user sees the app as greyed out.
- Click Continue.
- The Deploy Application page displays. Based on the project and the phase, some details may be pre-populated.
Provide the configuration details for this deployment and for this phase.
The deployment environment for this deployment is already pre-determined. You cannot assign tag-based Governance Rules to change this deployment.
- Click Submit.
- The Project View updates to displays the deployment state.
- You can choose to perform several functions based on the permissions for this deployment (for example, Terminate and Enable Terminate Protection are some possible actions for the deployment in a phase).
- Return to the Project View to see that the Demo deployment has three configured phases and one running deployment.
Deployment Environment Privileges
Deployment environment is the underlying entity for a phase in a project. Hence the permissions for a Deployment environment determine the operations permitted for a deployment within a project.
The following image displays the available options when assigning privileges for a Deployment environment.
- The Access column deals with the permissions on the deployment environment. This controls who can view, edit, or share the deployment environment.
- The User’s deployments and Others’ deployments columns controls the permissible operations on a deployment within a deployment environment. This is relevant as multiple users can deploy applications into a deployment environment. The image given below displays the various operations for a deployment. The operations displayed here are dependent on the permissions given at the deployment environment level.
- The User’s deployments column controls the operations permissible for users for their own deployments in this deployment environment.
- If this is set to None, then users cannot see their own running deployments in the corresponding Phase.
- If this is set to Access, then users can only view and access the deployment (by clicking on the access link in the job details page).
- If this is set to Manage, then users can see all operations except, Promote.
The Others’ deployments column controls the operations permissible for users on other users’ deployments in this deployment environment. This enables them to get privileges to perform operations on deployments of other users in the context of deployment environment. The behavior of various options here is similar to that of options in User’s deployments column, except that it is applicable for deployments of other users.
- The User’s deployments column controls the operations permissible for users for their own deployments in this deployment environment.
- The Deploy To column determines whether a user/group has privileges to deploying applications in this deployment environment. To deploy an application into a phase, the user must have the Deploy To privilege for the corresponding deployment environment of the Phase. Otherwise, the Add deployment link is disabled for the user.
- The Promote From column determines if a user/group has privileges to promote applications from this deployment environment (Phase) to another deployment environment (next Phase). To promote a deployment from one phase to another, the user must have:
- Promote From permission for the deployment environment that corresponds to current phase.
- Deploy To permission for the deployment environment, that corresponds to the next phase.
- The Authorized Approver column determines the users who should approve the deployments into this deployment environment (or Phase).
- No labels