Docker and Kubernetes allow development teams to move faster, deploy more efficiently, and operate at an ever-growing scale. FlexDeploy 6.0 container support has been revitalized to enhance teams’ ability to leverage these tools to increase operational efficiencies, improve developer productivity, and be more consistent with other plugins. Here’s what you will find:
- Container projects are no longer configured in separate tabs on the project, adding efficiency and consistency to the user experience. Instead, they are configured using project properties (values set on a per project basis that are used by the plugin) and plugin inputs (values set in the workflow).
- A Container Blueprint has been added. This Blueprint will guide you through the process of creating a container project, as well as creating Workflows, Target Groups, and anything else needed for the project. Blueprints accelerate the journey to the ultimate goal, which is automating the process of building and deploying software.
- The Docker, Kubernetes, and Helm plugins have all been streamlined. The Docker plugin is now using the same project properties for operations which require an image name and tag. This means no longer having to configure the image and tag multiple times, eliminating repetitive tasks and potential for error, and increasing productivity.
- The ability to pass data from the build workflow to the deploy workflow has been added. This is useful for transferring which image and tag were built to the deploy workflow. You can also pass your own custom values from build to deploy. Continue reading for examples of this.
Let’s take a look at some examples of these new features in more detail.
Project Configuration Changes
Let’s start by looking at the properties tab on an already configured Docker project.
We can see the newly added Image Name and Image Tag properties. Previously you would have configured these on the Docker tab. As you can see it is now simpler and more in line with other plugins. Additionally several new variables have been made available for use in project properties to ease this transition. The following variables were added to properties:
- FD_PROJECT_VERSION – Version of the project, as seen on the project execution screen
- FDBLD_BRANCH_NAME – Name of the branch as configured in the source control section
- FDBLD_BRANCH_ATTRIBUTE1 (and 2 and 3) – Branch attributes as configured in the source control section
These new variables allow for many scenarios, including having different tags for every branch. For example something like this:
FDBLD_BRANCH_NAME + "-" + FD_PROJECT_VERSION
Plugin Streamlining
Prior to FlexDeploy 6.0, many of the Docker plugin operations had different inputs or project properties for the same thing. With the new image name and image tag properties, it is now cleaner when using different operations across the same project. For instance you could build an image and then push it to different repositories based on the environment. All without needing to configure anything except adding the dockerPush operation to the workflow, and configuring the correct repository in each environment.
Showing image links in artifacts
Another addition is that whenever a Docker image is built or pushed, it will show up on the artifacts tab:
This makes finding your images easier, and provides the ability to easily copy the image from this screen. It’s also very clear which image and tag were built.
Passing Outputs From Build to Deploy
The last new feature I would like to talk about is the ability to pass values from a build workflow into the deployment. The following outputs are automatically captured from the dockerBuild operation:
- FD_BUILT_DOCKER_IMAGE_ID – The image id that was created from the operation
- FD_BUILT_DOCKER_IMAGE_NAME – The built Docker image name
- FD_BUILT_DOCKER_IMAGE – The built Docker image, including repository and tag
-
FD_BUILT_DOCKER_LINK – The link to the built Docker image when pushed to a repository
Now that these are being captured we can use them anywhere in the deploy workflow that you would normally use a variable. For instance you could use them in a Helm values file like this:
image:
name: ${{FD_BUILT_DOCKER_IMAGE_NAME}}
Passing User Variables From Build to Deploy
You can also use any variable marked as an output inside of the deploy workflow. In order to do this, just set a variable as an output and its value will automatically be saved for later use. Then you can read this value in the deploy workflow, just like you would use any other variable. Please note you cannot set an output in a deploy workflow and then use it in another deploy workflow. It only works from build workflow to deploy workflows. Let’s see a quick example of this.
I have created a workflow here with a variable set to output called TEST.
Next, let’s use this in a deploy workflow. I’m going to display the variable value using the Unix shell plugin. Since we have the code snippet input set to expression, we can use the variable directly:
And we can see the result:
This feature is very powerful, and not just for containers. I’m excited to see what our customers can do with it.
Conclusion
As you can see the Container experience in FlexDeploy will be greatly improved with the release of FlexDeploy 6.0. It is much more streamlined to setup and maintain a Container project. FlexDeploy 6.0 is transforming developer productivity, which just might transform your business. Let us know what you think.
If you’d like more information about containers check out the links below:
