Cool DevOps How-To

Version 3.5.3 and higher

1 Introduction

In this document we’ll be going over the CoolDevOps and how to work with it. It is necessary that you’ve followed the installation manual, otherwise you’ll be stuck in the first few steps.

2 Deployment Plans

The CoolDevOps runs on deployment plans. They’re holding the information on which applications and which timeslots correspond with one another. To make a deployment plan follow these steps:

2.1 New deployment plan

1. Go to the dashboard;
2. Click on Add new deployment plan;
3. Enter a name, the corresponding JOSF test repository and select both the corresponding pipeline and responsible team;
4. Click Save.

Within the detail page of the deployment plan, there are multiple boxes visible. They’ll be explained below. Mind you: everything, aside from the edit plan-box is immediately saved when changing the values.

2.2 Latest deployment

The Deploy-box shows the last deploy and the status of the steps followed by the pipeline. You can see which ones were successful and unsuccessful. Clicking on this process shows a popup with more information about the Azure Pipeline timeline and its corresponding log. If you want even more information, you can go to Azure through the link next to the build.

2.3 Configuration

In Configuration we can find three things: dependency on other plans, override BPT and admin configuration.

1. Dependency: if your deployment plan (calling them the child deployment plan) is dependent on another deployment plan (calling them the parent deployment plan) it should be started after this has finished. Otherwise there might be some errors popping up. That’s why we work with multiple runs. The dependency makes sure that the child deployment plan is in the run following the one where the parent deployment plan is in. You can edit this by clicking the pencil icon.
2. Override BPT: per environment you can choose to override BPT. Just clicking the checkboxes is enough to change the value.
3. Admin configuration: here you can set if the deployment plan is a high priority plan, which get pushed to the earliest runs. Furthermore, you can set if outdated modules should be published.

2.4 Schedule

In schedule you can add your deployment plan to any available timeslots by clicking the checkbox.

2.5 Feedback messages

When you want to see if you can deploy, you can click Validate in Feedback messages. Here you get feedback if you’re missing any zones or catalogs, or if there is an application which one of the applications in your plan is dependent on.

2.6 Applications

In Applications you can add, remove or edit applications in your plan. Adding and removing is done by clicking on Edit application in deployment plan. A popup will open which will show all applications for the team you are a part of.
To edit an application, you can click on the wrench icon. This opens up a popup where you’ll be able to put in the same information as in the application settings.

2.7 History

In History you can see the last 7 deployments and their statuses of the deployment plan. Clicking on this process shows a popup with more information about the Azure Pipeline timeline and its corresponding log. If you want even more information, you can go to Azure through the link next to the build.

2.8 Pipeline details

To edit this deployment plan, you can click on the pencil icon next to the title. This opens up a popup where you can edit the name, JOSF repository, selected pipeline and selected team.

2.9 Deleting deployment plan

1. Click the pencil icon in Pipeline details;
2. Click Delete;
3. Click OK.

2.10 Ad hoc deployment

1. Click Start deployment;
2. Click the Yes.

3 Release plan

Whenever the team is ready to close a feature and release it to the wide world, they can start a release plan. This will get the latest test results and all changes from the applications. The applications are recognized by the tags in the user stories. Note: the release pipeline will be immediately put to action when you create a release plan. This means there is no editing later on. Due to AVG/GDPR, we also removed a ‘Delete’ button.

3.1 Release plan draft

1. Go to the dashboard screen or the release plan overview page;
2. Click Add new release plan;
3. Enter a name, release pipeline, responsible team and additional evidence,
4. Click Save as draft.

3.2 New release plan

1. Either create a new release plan, follow steps 1-3 from the previous paragraph or go to the release plan list. Click on a draft release plan to edit it. Enter feature identifiers and their respective first development data for this feature
2. Change the additional evidence if needed
3. Click Start release.

3.3 Release plan

In Release plan you see all the details which we used to get the relevant information. Of course, we see the information you just entered while creating a new release plan. Furthermore, you can see the status of the pipeline and which applications are connected. If an expected application doesn’t show up, it means either the application isn’t mentioned in the tags, or the application has a different name than the name used in these forementioned tags.

3.4 Release documentation

In Release documentation we see everything we need to make a decision for a go or no go.
First, we see the additional evidence that we just entered and the repository which we got from the pipeline.
Second, we look at the tests. These tests are from Azure DevOps, which in turn gets it from the testing tool. Clicking on the title will get you to the Azure page with the test results. Clicking on Show steps shows a popup with the test steps and their respective results.
Third, we see all the changes. Clicking on the title will get you to the Azure page where the changes are highlighted.

4 Schedule

The CoolDevOps is based on the thought of daily deployments and automation. To facilitate this, we made timeslots in which deployment plans can be deployed. These timeslots will always have a higher priority than ad hoc deployments. They’ll happen once a day.

4.1 Edit timeslot

1. Go to Overview – Schedule;
2. Click on the Timeslots title;
3. Set the time you want;
4. Click Save.

We advise setting the timeslots at hours no one is working to not hinder the development team, such as the developers and testers.

With the CoolDevOps we work with dependencies between deployment plans, as not to create a monolith-like deployment plan. We make sure that the child deployment plan deploys later than the parent plan. We do this by working in multiple runs, where the high priority deployment plans go first. In the schedule you can also check why your deployment plan is set in a specific run by checking for parent plans.

4.2 Check for parent plans

1. Go to Overview – Schedule;
2. Click on the desired plan. In blue you can see where the clicked plan is all through the week.

5 Applications

In the application overview, you can see which applications have not yet been implemented in a deployment plan and which applications have been implemented in multiple deployment plans. Both situations are not ideal and should be avoided as much as possible.