Simplify CI/CD pipelines with FlexDeploy – Flexagon

FlexDeploy has supported advanced pipeline and release management scenarios natively for years now. Continuous Integration capabilities are also a core feature eliminating need for managing separate CI server. This makes FlexDeploy a unique DevOps platform that provide build, deploy & release automation all in one tool. FlexDeploy 5.1 takes all these capabilities step further to make CI/CD setup very EASY!

Everyone is quite familiar with pipelines as a means to deliver/deploy artifacts through various environments(stages) and eventually to production. Pipelines can be configured to execute tests and have gates for schedule and/or approvals. FlexDeploy has concept of workflow that is used for deployment of single artifact (aka project) to single environment. Pipelines build on top of workflows, which means that pipelines do not have low level deployment script/code/plugin.

Let’s review example pipeline first.

FlexDeploy pipelines are reusable and created using GUI with drag & drop approach which makes it very easy to create and understand. For example pipeline above, here is our intent.

1. Deploy to Development environment right away.
2. Check results of automated tests before promoting to Test, QA, Production
3. Require schedule in QA
4. Production requires ServiceNow change approval and off hours schedule

This is just example, customers are free to define as many pipelines as they need, but generally there will be some finite number of pipelines that will be reused.

Now, what deploys through these pipelines? That is where FlexDeploy is unique. In general for most DevOps tools there is single and mostly static number of artifacts that are executed through pipeline. But in reality, content of what is being delivered can change over time for same release and definitely for different releases. FlexDeploy release allows for definition of various artifacts of any type as a single deployment group. Here is an example of a release which I will call May 2019 release.

Now we have this release which is setup to use specific CD pipeline and has artifacts like spring application, database changes, SOA Suite composite and two packages for Oracle EBS application customizations. You can change this at any point during execution of release, i.e. it is not at all hard coded/static.

Now let’s see this in action. I have setup this release to look for changes every 10 minutes, and build automatically if changes are found. See scheduled build input box. Hence, FlexDeploy has created snapshot of all artifact versions.

Snapshot just contains individual version of each artifact that was built. We will not look at how builds work for each type of artifact as we have that covered in number of other blog entries.

At this point let’s assume that developers are working on feature request/bug that they are assigned. I will simulate that by doing dummy commits to GitHub, source of projects configured in this release. Keep in mind that every artifact (project) in release can be sourced from different repository or even different type of SCM.

Note that both changes were committed by comment that has JIRA number in it, which will allow FlexDeploy to track how specific JIRA issue is built and promoted.

Now let’s just wait and FlexDeploy will detect this change and create new builds. At this point, FlexDeploy will check for changes in SCM (Git in our case) at scheduled time. If changes are detected in one or more projects, build will be initiated automatically, which will eventually create a new snapshot. Snapshot is list of versions for all projects included in release and it will evolve as changes are made in respective source code repositories.

Snapshot name is based on time when it is created. You can see in above screen shot that new snapshot is built automatically (user releasecipoller) and once built it will execute through pipeline.

What if I want to see how snapshot is progressing through stages? You can do this on release dashboard as well as on reports. See below, we can see that snapshot is now at Deploy All Projects in development environment. Now what is Deploy All Projects step doing? It is just deploying all projects configured in release, which is what makes this pipeline reusable. Once deployment is completed in development, it will run Execute Unit Tests step and then move on to Test stage.

For Test stage, first we are checking result of Unit Tests. At noon (our pre-defined time gate), steps will start executing for deployment and tests. Here is how it looks like when it is waiting at gate.

Similarly when pipeline progresses successfully through Test environment, it will wait for QA Manager approval if test results indicate success. This process goes on as scheduled build process creates newer snapshots. This means that Development may have executed more snapshots than Test environment. Similarly QA environment will have even fewer number of snapshots. Still at times only few projects are changing in release and FlexDeploy will deploy accordingly. In our example we just had changes for two projects, so QA environment deployment will have two projects being deployed. See below.

DevOps engineers can also take advantage of FlexDeploy REST API & other plugins/integration capabilities to integrate with other DevOps tools as part of pipeline and workflow.

We have demonstrated that release content is not only built automatically, but it deploys as well through stages automatically. FlexDeploy also reduces efforts necessary to setup CI/CD processes thanks to application release automation features and out-of-the-box support for various middleware and application build/deployments. You can read about all features on our documentation page.