Elixir logo

As you can see in our previous posts, having a complete pipeline to introduce DevOps in your day-to-day live is easy with Clarive’s Rulebook.

You just have to follow these three simple steps:
1. Get your 30-day trial
2. Upload your code to your Clarive Project repository.
3. Prepare your rulebook, push your commit and enjoy! (oops, maybe four steps would have been better :))

So let’s get down to business: we will detail the needed code.

Defining our variables

First, we declare the variables that will be used throughout our pipeline process.

vars:
  - workspace: "${project}/${repository}"
  - server:  https://<my-clarive>.clarive.io
  - art_path: ${server}/artifacts/repo/${project}

Building our application

In this step, we choose Elixir Docker image using Mix as a building tool.

build:
  do:
    - image:
         name: 'elixir'
         runner: 'bash'

     - shell [Compile application]: |
         cd {{ workspace }}
         mix compile
         tar cvf ${project}_${job}.tar _build/dev/lib/

And publish the compiled application to our artifact repository.

    - artifact_repo = publish:
        repository: Public
        to: '${art_path}'
        from: '{{ workspace }}/${project}_${job}.tar'
    - log:
        level: info
        msg: Application build finished

Ready to test

As long as we have our own application tests, this step is as simple as running the right command.

test:
  do:
    - image:
         name: 'elixir'
         runner: 'bash'

     - shell: |
         cd {{ workspace }}
         mix test

Deploy wherever we want

Now, it’s time to choose where our app will run. For example, send the tar file to another server and run the app.

deploy:
  do:
   - ship:
       from: '${art_path}/${project}_${job}.tar'
       to: /tmp/remotepath/
       host: ${remote_server}
  - shell:
      cd /tmp/remotepath/
      tar -xvf ${project}_${job}.tar
      mix run

This remote_server could be an AWS instance in PROD environment or another Docker container just to QA.

Happy Ending

Now with our .yml file already prepared, we can use Clarive’s interface to visualize the steps that will follow the finalizing of the rulebook.
To start the deployment, we only need to perform the push on the repository, just as we have seen before in other posts. When performing the push, Clarive automatically creates a deployment (Continuous Integration) and executes all the code found in the .clarive.yml.


Visit Clarive documentation to learn more about the features of this tool.


In this video we can see how Clarive checks the availability of certain versions of applications (BankingWeb 2.1.0 and ComplexApp 1.2.0) needed in an environment before deploying a version of another application (ClientApp 1.1.0).

We could consider the applications(BankingWeb and ComplexApp) as pre-requisites for the actual application (ClientApp) for which the deployment is requested.

When the required applications versions (BankingWeb 2.1.0 and ComplexApp 1.2.0) are not in the target environment yet, Clarive will block the deployment until the applications are either deployed first (in a separate job) or added to the same deployment job as the application requiring the pre-requisite applications.


Start your DevOps journey to continuous delivery with Clarive now. Ge your 30-day trial here.


Continuous integration (CI) is now becoming a standard in all software projects. With this, a pipeline is executed for each new feature or change in code that is made, and this allows you to carry out a series of steps to ensure that nothing has been “broken”.

One of the main steps that needs to be undertaken in the CI is the implementation of tests, both unit tests and regression tests. The latter can be done in the nightly build that Clarive is responsible for launching on a daily basis, at the time that we pre-define within our Releases.

Unit tests must be run whenever there has been any change in the code. This brings us to our first step. The unit tests must be run with each change in source code using a transfer (Continuous Integration) and the tests will be launched in the nightly builds of each new Release. This will ensure that the new version of our product will go onto the market without any bugs or problems in the features that worked well in the current versions.

At the end of this post the reader should know how to:
Integrate tests into a Clarive rulebook.
Publish files in an artifact repository.
– Send notifications to users.

Ready to start

To start this step-by-step guide you need a copy of Clarive installed on your server (you can request a 30-day trial).

Overview

For this post, we will use the following workflow:

1- User commit tests.
2- Clarive runs rulebook.
3- Mocha run tests.
4- Clarive post a message in Slack with the report.

For the first part of the development, we will assume that the developer has already written his tests. In this example we will use a simple “Hello world” and some example tests that you can find here and which will use the library expect.js, which will be installed during the running of the rulebook.

Workspace files:

In this example within our git repository we have the following file structure:

├── .clarive.yml
├── package.json
├── src
│   ├── add.js
│   ├── cli.js
│   ├── divide.js
│   ├── helloWorld.js
│   ├── multiply.js
│   ├── sort.js
│   └── subtract.js
└── test
    ├── helloWorld.tests.js
    ├── test-cli.tests.js
    └── test.tests.js

.clarive.yml: The rulebook file that Clarive runs
package.json: NPM configuration file. Within this file we have defined a command to run the tests that are found in the test folder:

"scripts": {
    "test": "mocha --reporter mochawesome --reporter-options reportDir=/clarive/,reportFilename=report,reportPageTitle=Results,inline=true"
  },

src: Folder where we find the source code.
tests: Folder where the test files are located.

Writing a rulebook

The rulebook will be responsible for running the tests and generating a report to notify the user of the results of the tests.

First phase: Running the tests

As we can see in the file skeleton clarive.yml, there is a step named TEST that we will use to run the tests:

test:
  do:
    - log:
        level: info
        msg: The app will be tested here

But first, let’s define some global variables:

vars:
  - workspace: "${project}/${repository}"
  - server:  https://<my-clarive>.clarive.io
  - art_path: ${server}/artifacts/repo/test-reports

We can see from the code that we are going to use node.js with mocha, chai and expectjs as libraries to run the tests. And thanks to Docker images, we can use a container with mocha and chai already installed, and this means that you only need to install expectjs using the rulebook.

We can now specify the Docker image we’re going to use during this TEST phase and then install the expectjs library from our working directory and, finally, update our package.json:

test:
  image: mocha-chai-report
  do:
    - shell:
        cmd: |
             cd ${workspace}
             npm install expect.js
             npm install

Next, we just need to run the tests. As we have already defined the command to run the tests in our json package, we only need to run npm test:

test:
  image: mocha-chai-report
  do:
    - shell:
        cmd: |
             cd ${workspace}
             npm install expect.js
             npm install
             npm test

Second phase: Publish report

When you finish running the tests, an HTML report will be generated with all the results, thanks to the mochawesome library installed in the Docker image. We will now publish this report in our artifact repository:

- publish_report = publish:
        repository: Test reports
        from: 'report.html'
        to: "test-reports/{{ ctx.job('name') }}/"
    - log:
        level: info
        msg: "Report generated successfully!"

Now, we are now going to complete the POST step. During this step we will inform the users that we want to complete the deployment.

Third phase: Notifications

We need to post the message in Slack, with a link to the report. To do this, we will have to have our WebHook configured in Slack and in Clarive:

Now all that remains is to add the sending of the message to the POST step:
From the Slack API any user can configure their own messages. In this case we have configured a message in which the user, on receiving the message, will be able to access the report from the same channel:

- slack_post:
          webhook: SlackIncomingWebhook-1
          text: ":loudspeaker: Job *{{ ctx.job('name') }}* finished."
          payload: {
              "attachments": [
              {
                "text": "Choose an action to do",
                "color": "#3AA3E3",
                "attachment_type": "default",
                "actions": [
                    {
                        "name": "report",
                        "text": "View test report :bar_chart:",
                        "type": "button",
                        "style": "primary",
                        "value": "report",
                        "url": "${art_path}/test-reports/{{ ctx.job('name') }}/report.html"
                    },
                    {
                        "name": "open",
                        "text": "Open Monitor in Clarive",
                        "type": "button",
                        "value": "open",
                        "url": "${server}/r/job/monitor"
                    }]
             }
           ]
        }

Lets make continuous integration!

Using Clarive, we can create a Story where we will attach all the code. If we haven’t already created a Project, we can create one using the Admin panel:

Then we create a repository of artifacts (a public one in this case):

Once we have carried out the previous steps we will create the Story in Clarive:

We’ll now change the state to “In Progress” and Clarive will automatically create a branch in the repository:

From the console we’ll clone the repository and change to the branch we’ve just created:

We’ll now place all our files in this branch and push them to the repository:

Clarive will automatically generate the deployment:

After finished, we will received the notification on the Slack channel that we’ve selected:

Finally, we can check test report in the artifact repository.

Next Steps:

In Clarive – After making this first contact with Clarive, our Story can be assigned to a Release (one that was previously created from the release menu) and, after changing the state to “Ready”, the developed feature will be automatically merged into the branch of therelease.

In Rulebook – Well, this is a simple example. The rulebook can be as complex as the user wants it to be, for example, by adding if statements, adding elements in the different deployments. For example, if something has gone wrong, create a new Issue in Clarive automatically, only run tests if the “tests/” folder has been modified in the commit…the possibilities are limitless!.


Visit our documentation to learn more about the features of Clarive.



Spoiler alert: if you like short product cycles to deliver features that make your users very happy, you probably already know the answer.


We’ve just released a great guide to help startups getting started with delivering lean software. Get your copy here if you haven’t already.

Lean application delivery is the part of lean startup methodology that deals with how software products are built, how to prioritize, how to track and measure and how to automate every aspect of the pipeline.

It’s basically the marriage of DevOps and your workflow: be it agile, kanban, scrumban or, yes, waterfall.

Lean Delivery:
Lean DevOps?
Lean Agile?
KanbanOps?

As we say in the guide, this is about your journey to lean nirvana: a just-in-time flow to deliver value to your users.

Tools like Trello

Postits on a wall or simple tools like Trello are a great way to start lean. Trello is no frills, low features, but sucks when you need to do anything that transcends organizing simple tasks. But it does get a team collaborating on goals fast.

Github, Gitlab or Bitbucket can get you coding and building stuff… but what stuff? For whom? Why? How do you deliver it? How do you align with the business plan?

While marketing and sales are getting their job done with HubSpot, engineers and product people are fiddling with the gruesome toolchain.

Are the tools running your team, or the other way around? Aha, Jira and Pivotal Tracker can get you very far. Heck, so far that you probably could spend your whole life in just perfecting yourself with these tools. But that’s not how a startup works. There’s no time. You need to define products, get people building, and you probably would need at least 4 or 5 tools just to:

  • Define product, align with goals and user value;

  • Code, track, deploy;

  • Automate, measure, iterate!

You need your product people to collaborate. And you need to automate everything. From goals, to ideas, to the DevOps pipeline. Just get your team to deliver software the way it’s meant to be: lovable products that iterate fast.

Batteries Inside

Our guide covers a few of our favorite topics in lean delivery, enough for a quick 10 minute read through. Here’s hint of some of the topics covered in the guide:

Define your flow before picking your tools

Or how to avoid bloating your startup with out-of-the-box, out-of-place processes from picking tools before you pick the process.

Delivering software is not just an engineering thing

Or how to build traction and make products your users love and business sells.

Emotion is a gauge

Be sensitive and measure emotion correctly.

Have a place for ideas

Or how to nurture and follow up on things that will bring value to your users.

MVP all the time: break down work

Or how to deliver value while keep your team and users motivated.

Isolate changes

Or how to be able to put a release together just-in-time instead of building really huge “develop” branches.

Measure your process, improve fast

Or how to keep your team delivering frequent releases.

Eat your own dog food

Or how to avoid delivering software that will bug your users down.

Avoid release anxiety

Or how to fine tune your iteration so that users, engineers and management is continuously happy.

It’s only done when it’s in production

Do I need to say more?

I hope this is good enough to get you started. There’s a lot of literature out there on how to build your startup to be lean and mean. Learn, measure, iterate!


Go get your Guide to Lean Delivery.



Given the fact that the EU’s GDPR law (replacing the 1995 Data Protection Directive) will go into effect on May 25, almost every software vendor is jumping on the bandwagon to explain how they can help.


Let me be compliant, and follow the stream.

gdpr and Clarive

When reading about the subject online, I noticed that most articles center around the specific business and legal obligations regarding personal data. These articles focus on physical data processing and the data controller obligations to manage processing. Of course!

This is not what I want to write about in this blog however. The GDPR is also expected to impact the software delivery life cycle and its related IT-development processes for organizations that plan to rollout IT projects within the EU.

There are many lifecycle flavors to deliver software today on the market, all waterfall, iterative, or agile based. All of them define the way to manage and control the IT project, from planning to rollout, across the different application layers or modules, and platforms. Common software layers that will be directly impacted by the new GDPR law include of course databases as well as their related architecture, but also data transport, data security, presentation, and application layers… basically potentially every software aspect could be affected!

The impact of GDPR on application delivery

This means if your company intends to continue to roll out systems in the EU, you will have to deal with the new functional and technical requirements introduced by the GDPR like the following (this is not an exhaustive list, only some important ones to make the point):

  • Ensure data protection in the system and the organization, by design and by default (Recital 78 and Article 25)
  • Use data encryption when possible (Recitals 83 and Articles 6-4(e), 32-1(a))
  • Use Data pseudonymization when possible (Recitals 26, 28, 29, 78 and Articles 6-4(e), 25-1, 32-1(a))
  • Anonymize data when possible (Recital 26)
  • Share processing attributes and steps to the data subject in an easy to understand form at the time of data collection, electronically or in writing (Recitals 39, 58 and Articles 12-1, 13-2(a-f))
  • Make data portable to another provider (maybe competitor) (Recital 68 and Articles 13-2(b), 14-2(c), 20)
  • Ensure data is secured, and integrity and confidentiality are maintained, using technical and organizational means under the management of the controller (Recital 49 and Articles 5-1(f), 32-1(b-d))

While a number of these new requirements might be seen as “no-brainer” as they were already part of your software design, others will trigger new requirements that need to be implemented fast and with quality before the law is enforced.

Failing seems to be not really an option. Not complying with the GDPR requirements could result in very serious penalties! As I could read, the worst-case scenario could a fine of €20 million or 4 percent of the company’s previous year’s total global revenue, whichever is greater. Ouch!

The clock is ticking, how do you track progress and ensure compliance?

With only a few more months left, how are you progressing with the delivery of these new requirements? Can you truly track requirement progress throughout your software delivery chain? How confident are you all policies are correctly implemented?

When speaking to bigger clients, this is often their biggest challenge: They have deployed multiple tools to support software delivery. Coding is fragmented, and the delivery toolchain is often poorly integrated, leading to extensive manual activities within the delivery process and a lack to end-to-end visibility and traceability.

At Clarive we believe in SIMPLICITY. Your software delivery toolchain should be as simple as possible, requiring the minimal set of tools to get the work done fast, with quality, and in a transparent way. For smaller organizations and startups, this can be a single tool: Clarive! Bigger organizations often do need multiple tools to support multiple platforms, but they miss overall orchestration and automation. Not those that use Clarive!

As a simple, lean application delivery platform, Clarive will deliver you the traceability you need to track progress on your GDPR (and other) requirements with ease.

Clarive not only helps with end-to-end tracking, its powerful role-based, ruling and workflow automation system also offers capabilities that will help you to ensure everyone on the team remains in compliance with the company’s legal and other requirements, like those for GDPR. For example:

  • Workflow rules: Workflow rules allows you to accept/reject code or actions that do not comply with company policies. For example, our support for code reviews ranges from static code analysis-based decision tree rules to multi-level acceptance approvals within the delivery process.
  • Role based security: Permissions can be set very granularly according to the role members have in respect to the project.
  • Cross platform & process Automation: The best way to ensure compliance it to AVOID manual interventions. Clarive allows you to automate every delivery execution step (apart from the coding itself of course) and process workflow. We support this across teams and platforms, making manual activities (other than just approvals) redundant.

Sounds great? Why don’t you take a look at Clarive now? As our customers witness, you can get started quickly. Just download your 30-day trial here and try it out yourself.


Enterprises are in constant search of ways to deliver faster, ideally in a continuous/frequent fashion, with full traceability and control, and of course with excellent business quality.


DevOps as an approach continues to get a lot of attention and support in achieving these goals.

As readers can find in other blogs and articles on DevOps, DevOps aims at bringing Development and Operations closer together, allowing better collaboration between them, and facilitating a smoother handover during the delivery process. Automation remains a critical component in the technical implementation.

What strikes me all the time is that, when I discuss the subject with customers, analysts, and other colleagues in the field, very quickly we seem to end up in a DevOps toolchain discussion that gets cluttered by numerous best of bread but point products that one way or another need to integrate or at least work together to get the delivery job “done”.

Why is that? Why does a majority end up with (too) many tools within the delivery toolchain?

We fail to search for simplicity

If you read about what analyst like Gartner or Forrester are writing about implementing DevOps, if you read closer about what Lean IT stands for, then a common theme that will surface is SIMPLICITY.

If you want to enhance collaboration between delivery stakeholders, if you want to make the handover of deliverables easier, if you want to automate the end-to-end delivery process, then you should look for ways to make your delivery toolchain simpler, not more complex.

As part of the analysis and continual improvement process of the delivery value stream, we look for better ways to do specific tasks. We should in addition carefully look at alternatives to avoid manual activities in processes when possible. This is just applying common Lean practices in the context of application delivery.

Many (bigger) enterprises remain overly siloed, and this often results in suboptimal improvement cycles. When developers face issues with the build process, they look on the web for better build support for their specific platform, ideally in open source, so they can “tweak” it for their needs if required (it is often a matter of retained “control”). If quality suffers, developers and testers can do their own quest to improve quality from their viewpoint, leading to the selection and usage of specific point products by each team, sometimes not even aware of their respective choice.

I can continue with more examples in the same trend, but the pattern is obvious: When teams continue to look for the best solution “within their silo”, then most of the time organizations will end up in an overly complex and tool rich delivery toolchain.

Look at delivery in a holistic way, from a business perspective

The above approach is not respecting some important Lean principles though: Look at the value stream from a customer’s perspective, in a holistic way, creating flow while eliminating waste.

These are some of the things you should look at while analysing and improving your delivery toolchain:

  • How does demand/change flow into the process? How is the selection/acceptance process handled? How is delivery progress tracked?

  • How automated are individual delivery steps (like build, provision, test, deploy)? How is the delivery process/chain automated itself? Any manual activities happening? Why? Does automation cover across ALL platforms, or only a subset?

In case you would like to learn around this subject, I can recommend reading the following ebook on the Clarive website: “Practical Assessment Guide for DevOps readiness within a hybrid enterprise

Clarive CLEAN stack

A C.L.E.A.N way to deliver quality

At Clarive we believe simplicity is vital for sustained DevOps and delivery success.
We designed the C.L.E.A.N stack exactly with this in mind:

Clarive Lean & Effective Automation requiring Nothing else for successful delivery.

Indeed, Clarive allows you to:

  • Implement Lean principles and accurate measurement and reporting with real-time and end-to-end insight

  • Implement effective and pragmatic automation of both delivery processes as well as delivery execution steps such as build, provision, test, and deploy.

  • Do all this from within the same product, so there is no need to use anything else to get the job done!! No real need to implement artefact repositories, workflow tools, or anything else, just Clarive will do!.

Of course, in case you have made investment in tooling already, Clarive will collaborate in a bi-directional way to get you started quickly. After all, DMAIC or other improvement cycles are cyclic and continual, so you can further refine or improve after you got started if you desire more simplicity…

This is an evolution I have seen many of our clients going through: they initially look at and start with Clarive because they have certain automation or orchestration needs. Then they find out they can do with Clarive what they did with Jenkins, and switch to Clarive, then they learn about Clarive’s CI repository and decide to eliminate Nexus. As Clarive has a powerful and integrated workflow automation capability, they realise they could also do without Jira and Bitbucket… and so on. It has saved companies effort and cost doing so.

In case you are interested in Clarive, start with the 30-day trial.

See also some sample screenshots of the tool below.

Clarive tool

Clarive tool_screenshot

Clarive tool_screenshot_deploy package


Visit our documentation to learn more about the features of Clarive.


We are glad to present our new branching model Git flow based available for Clarive 7.

This new Git flow enables you and your team to:

  • Revert features
  • Deploy different releases progressively to environment
  • Maintain simultaneous live releases
  • Isolate feature groups into different release branches.

This presentation explains the problem it solves and how it can improve your day-to-day workflow tracking changes and delivering applications.

 


Visit our documentation to learn more about the features of Clarive.



I deliberately stated the title in the “traditional” way. How to get control OVER teams.


You want to implement DevOps, so you are aware of the fact that when implementing DevOps, you need to adopt Lean and Agile principles along the way to success.

Implementing DevOps indeed not only implies the introduction of tooling to ensure end-to-end automation, but also a change in culture and different people and parts of the organization collaborate together.

What does Agile tell us?

Studying agile principles, you will have discovered that according to agile principles, you best build projects around motivated individuals/people. You should give them the environment and support they need and trust them to get the job done. Another principle is make teams self-organizing.
The best architectures, requirements, and designs emerge from self-organizing teams. Finally, you should strive for simplicity, as this is essential for flow, quality, and focus. If you are interested in further detail, I suggest you also take a look at the 12 principles behind the agile manifesto.

What does Lean tell us?

When reading about Lean, you probably have encountered the DMAIC improvement cycle. DMAIC, which is an acronym for Define, Measure, Analyze, Improve and Control, is a data-driven improvement cycle used for improving, optimizing and stabilizing (business) processes and designs. It is in fact the core tool used within Six Sigma projects. However, DMAIC is not exclusive to Six Sigma and can be used as the framework for other improvement applications.

Since in this blog I am talking about control, let’s elaborate some more on the “C” in DMAIC.
The focus in the “C” is on how do you sustain any improvements/changes made? Teams can introduce changes/improvements, but they must ensure that the process maintains the expected gains. In the DMAIC control phase, the team is focused on creating a so-called monitoring plan to continue measuring the success of the updated process.

What to remember?

From the above, and transposing this in the context of DevOps and Application Delivery, the 3 things to get better control to me are:

  • Build cross functional teams of motivated individuals, people willing to go for customer value.
  • Give those teams an environment and the support they need to get the job done. To maximize flow, remaining customer focused, and striving for quality, ensure the environment is a simple as possible.
  • Make sure it is easy for teams to monitor and measure delivery performance towards “success”.

Interestingly enough, you will not find any direct guidance in the above on how to gain control OVER teams or people, because it is against fundamental Lean and Agile principles. As a manager, you can “control” more or less by helping shape or define the WHAT, the objective, the result, the definition of success, but it is up to the team to define and decide on the “HOW”, the way to get to success or the objective. The reason I write “more or less” is because success is mainly defined by the customer, the consumer of what is being delivered, not necessarily the internal manager.

Now let’s drill a little deeper into the support a team need to get (self-)control. We mentioned a simple environment and a way to monitor and measure.

In the context of application delivery, this translates into the application delivery end-to-end toolchain environment and the way delivery activities can be monitored and measured within this environment.

Very often when speaking to customers I am hearing about toolchain environments similar to the one in the picture below:

Code-Deploy-Track by clarive

I typically see different tools used for different aspects in the delivery process, often not or hardly linked to one another. Many times, I even see multiple tools deployed within the same phase of delivery (as shown above).

Why is that? I have witnessed multiple reasons why companies have seen their delivery environment grow over the years, the most common ones being:

  • Different platforms requiring different tooling for coding and/or deploying
  • Through acquisition, different environments have been inherited, and as a result multiple tools became part of the merged organization. To avoid too much change, environments have been left untouched.
  • Companies have given their delivery teams autonomy/flexibility without proper guidance. At first sight, giving power to teams is aligned with the proposed principles, but if this is done without overall architecture or in silo, then this can lead to suboptimal conditions.

The biggest issue for organizations providing a delivery environment similar to the one in the picture above is that tracking (the end-to-end monitoring and measuring of the delivery process) becomes a real nightmare.

According to Lean principles one should monitor and measure the delivery value stream. This value stream is customer centric, so it crosses delivery phase and tooling boundaries. If measurement data is spread over 30+ tools, then monitoring performance and obtaining insight at real-time becomes a real challenge.

How to become successful?

Clarive has been designed and developed with the above in mind. The Clarive DevOps platform aims for simplicity and ultimate operational insight.

Real-time monitoring and measurement is achieved by strong automation and integration. Automating the delivery process implies automation of related process flows (such as demand, coding, testing, defect, and support flows) combined with the automation of delivery related activities (such as build, test, provision, and deploy). Clarive is the only tool that allows you to automate both within the same tool. This is what gives you simplicity! No need for multiple tools to get the job done. As a result, all measurement data is captured within a single tool, which gives you real-time end-to-end data across the delivery value chain. This is exactly what teams need to control their process and what organizations need to control/understand the overall process.

But reality is that significant investment might have been done in certain delivery areas (tool configurations or script/workflow automations) already, something the business will not easily allow to be thrown overboard as this then will be seen as “waste”. Clarive addresses this with its strong bi-directional integration capabilities allowing organizations to re-use existing investment and treat simplification as part of the improvement cycle.

Clarive enables teams and companies as a result to gain insight and control over their end-to-end delivery processes in very limited time.

Below are some sample screenshots of how Clarive provides powerful Kanban as well as real-time monitoring insight and control.

Kanban as well as real-time monitoring insight and control

assigned_swimlane by clarive


Get an early start and try Clarive now. Install your 30-day trial here.