The following is a summary of the information covered in the webinar: Transforming FlexDeploy with Webhooks. The on-demand recording can be accessed here.
What is FlexDeploy?
FlexDeploy is a DevOps platform supporting full Build Automation, Deployment Automation, and Release Orchestration. This means FlexDeploy handles the software delivery life cycle (SDLC) from source control to the final production deployment. It has over 100 plugins and features to simplify and enhance the DevOps life cycle.
One of those features is webhooks.
What are webhooks?
Webhooks are a HTTP POST request shared between two applications, tools, or services. In this article, we will refer to these as applications. Example technologies can be E-Business Suite, Salesforce, Git, Jira, ServiceNow, Slack, and many other applications, tools, and services.
Essentially, webhooks are a way for a packaged or cloud application to let another application know something has happened. The message is sent whenever an event is triggered within an application.
This makes webhooks similar to a REST API, but in reverse. With a REST API the callee owns the format and structure of the payload/message. In webhooks it is the caller that owns the format and structure. This means that if FlexDeploy is receiving a webhook it needs to be able to understand what provider a message came from and how to parse it. If FlexDeploy is sending the webhook then that format and structure is determined by Flexagon.
For example, a push event in GitHub (where an individual pushes changes to a repository in GitHub) will trigger a webhook.
The sender, or initiating application, of the webhook (e.g., GitHub) determines the event payload. Consuming applications (e.g., FlexDeploy) then decide what to do with the received information.
Incoming Webhooks
In this example, FlexDeploy classifies the webhook as an incoming webhook because the event was triggered in an external application.
The incoming webhook flow within FlexDeploy, includes:
1. FlexDeploy Receives the Request
When FlexDeploy receives the request, it does not know anything about the message as it is just a generic post request.
2. Provider Match
FlexDeploy will attempt to match the incoming message to a provider defined in FlexDeploy. It will search for a match by checking HTTP headers, checking IP addresses, and other more complex methods.
3. Identify and Match Message
Then, FlexDeploy will match the request to the GitHub message.
4. URI Match
Finally, FlexDeploy will look at the URI sent. At this point, FlexDeploy knows the message is from GitHub and the URI is a git/push. Then it executes the specific script or function that matches these criteria.
Outgoing Webhooks
Outgoing webhooks are events initiated within FlexDeploy, examples include Workflow Complete events, Workflow Failure events, and Task Create events.
When an event is triggered, a message goes to the pre-defined Listener. For example, if a Workflow Completes event occurs, two Listeners could be (1) updating a Jira issue and (2) posting a Slack message. These scripts are not limited to external API calls but can also use a wide variety of internal FlexDeploy APIs.
See FlexDeploy’s Support for Webhooks
In this webinar, Joel Wenzel, a Senior Software Engineer at Flexagon, demonstrated FlexDeploy’s support for webhooks, including a variety of incoming and outgoing webhooks for several technologies.
Access the full webinar today to see how you can use webhooks to further automate your CI/CD pipeline!
Want to keep learning? Check out other on-demand and upcoming webinars.
Please comment or contact [email protected] with any questions or if you are interested in getting hands-on with FlexDeploy.
