DEV Community: Levente

How to trigger TeamCity on Git push?

Levente — Fri, 23 Jul 2021 08:10:01 +0000

Previously in this series of Jira DevOps automation tutorials, we discussed how to trigger a Jenkins build and how to trigger a Bamboo build on successful Git commit.

Now we are looking at a Jira automation for TeamCity. We will walk through how you can automatically trigger a TeamCity build on Git push by using a specific command in your Git commit message.

Do you prefer a tutorial video? Watch this quick YouTube video on how to create an automation rule for triggering a TeamCity build:
https://www.youtube.com/watch?v=SeEoYukc8Fc

Extending Automation for Jira with DevOps triggers

The below DevOps automation solution is based on Automation for Jira (Data Center and Server) and Better DevOps Automation for Jira to automate a TeamCity build.

Better DevOps Automation for Jira extends Automation for Jira with DevOps triggers that you can use in any no-code, low-code automation rule in Jira.

You can freely combine the DevOps automation triggers by Better DevOps Automation with the built-in Automation for Jira actions, and implement a wide range of custom DevOps workflows.
If you are new to Better DevOps Automation, don't skip the introductory blog on this DevOps automation solution for Jira Data Center (and Server).

Trigger a TeamCity build on Git push

This Jira automation rule for TeamCity will trigger on Git push if your developers used the @build command in the Git commit message.
They can control if a TeamCity build should trigger after every successful push of code changes.

Better DevOps Automation introduces so-called Genius Commits, which are commits containing custom commands in the commit message.
This gives them a seamless way to change the @build command to something else, and control other CI/CD actions without switching context.

Steps to trigger TeamCity on Git push:

Create a new Automation for Jira rule and choose the Genius Commit created trigger from the DevOps category!
Choose the command "Build (@build)" from the list of commands!
Select the Send web request automation action!

Supply your Webhook URL for TeamCity:

<YOUR_TEAMCITY_SERVER_BASE_URL>/app/rest/latest/buildQueue

Replace the placeholders with your actual TeamCity base URL. If you are using a modern version of TeamCity which supports CSRF protection, check the documentation for further instructions.
Add a header with the name "Authorization" and with the value of "Bearer ". Replace the placeholder with the actual TeamCity Access Token. (Watch the tutorial video above if unsure how to create an access token!)
Add a header with the name "Content-Type" and with the value "application/xml".
Leave the HTTP method selector on POST!
For Webhook body, choose Custom data and enter the following:

<build> <buildType id="BUILD_CONFIGURATION_ID"/> </build>

Replace the actual value of your TeamCity build configuration ID, located at your build settings in TeamCity.
Save and turn on your automation rule!

You can control more than one build configuration in TeamCity with commands!
Read further on how to define the TeamCity build configuration in the commit message.

You can control more than one build configuration in TeamCity with commands! Read further on how to define the TeamCity build configuration in the commit message.

Give this TeamCity Jira DevOps integration a try for free now!

Trigger TeamCity builds on Git push!

Bitbucket Smart Commits vs. Genius Commits - What's the difference?

Levente — Fri, 16 Apr 2021 11:16:03 +0000

If you already heard about Smart Commits in Bitbucket, know that you just stumbled upon something even better (and smarter!): Genius Commits by Better DevOps Automation for Jira Data Center (+ Server).

What are Bitbucket Smart Commits?

A Bitbucket Smart Commit allows developers to use three pre-defined commands in their Git commit messages which will trigger certain issue operations. You can transition issues, log time on issues, and comment on issues.

The smart commit commands that you can use are, therefore:

"#transition"
"#comment"
"#time"

So, with Bitbucket Smart Commit, you could commit your code changes with a commit message like:

"SIA-878 #time 6h 30m #comment Bugfix passed for review #Under Review"

which would also log time against the Jira issue SIA-878, post a comment on it, and also transition into a different status. It's a pretty neat thing to do with a single commit, without context switching and other disturbances.

If you feel that more and customizable commands would be more powerful, read on because that's exactly what's coming and even more.

What are Genius Commits?

The Better DevOps Automaton for Jira app introduces Genius Commits. Genius Commits carry special commands in the commit message that can trigger any automation action, like running a CI/CD build, tests, Slack notification, Jira issue operations, etc.

Genius Commits are unlocking next-level productivity for developers by providing more commands to use out of the box and the option to add new commands.

If your team hasn't adopted Git or Bitbucket, you can still use Better DevOps Automation for Jira for automating your DevOps actions. You can use other Git clients or Version Control Systems like Mercurial, Perforce, or Azure DevOps.

Instead of having just three hard-wired commands to use you can choose from a list of 11 default commands when you install Better DevOps Automation for Jira:

@analyze: Starts a code analysis (code scan).
@assign: Assigns issue to a user.
@Build: Triggers a build in the CI/CD system.
@call: Sends an HTTP request to a (REST) API.
@Comment: Comments on an issue.
@Run: Runs a script/program.
@issuetype: Sets the issue type.
@priority: Sets the issue priority.
@status: Sets the issue status (and resolution optionally).
@TimE: Logs work to an issue.
@transition: Transitions an issue (and sets the resolution optionally)

To add new commands, you can use the intuitive configuration panel and create your own custom command.

How do Genius Commits work?

The genius commands used in Genius Commits kick off automation actions that you set up in Automation for Jira. The logic behind the actions is implemented as no-code or low-code automation rules. It means that putting together a DevOps automation logic is just as simple as any other Automation for Jira rule.

Automation actions can do anything an automation rule can do, such as working with issues, logging work, sending notifications, starting CI builds, deploying code, running scripts, and many more.

Check out Better DevOps Automation and the Genius Commits!

What is software's role in safe manufacturing processes?

Levente — Fri, 29 Jun 2018 11:35:04 +0000

EaglePicher Technologies is a leading manufacturer of battery systems for diverse industries like defense, aviation, space or medical.
As they operate in highly regulated industries, keeping a clear and traceable software code change history is just as important as complying with hardware specifications and safety requirements.

Kalen Brown, Associate Electrical and Computer Engineer, shared how they are using Commit Policy Plugin in managing source code changes in their Subversion repositories.

Tell us a bit about your role at EaglePicher!

I started here out of college in the beginning of 2015 and essentially dove into the project I am in now.

We are now working on a Lithium-Ion Iron Phosphate (LFP) commercial aircraft battery that uses a safer and more robust chemistry.
The cells in this battery may be much safer than ordinary Lithium-Ion batteries, due to the Iron Phosphate mixture, but we still want to be as safe as possible so we have hardware and software working together to keep the battery happy.

What triggered your need for a strictly controlled repository?

The Code of Federal Regulations (CFRs), the collection of rules created by federal agencies, says the equipment, systems, and installations whose functioning is required by the airplane must be designed to ensure that they perform their intended functions under any foreseeable operating condition.
The Federal Aviation Administration (FAA), the U.S. national authority that regulates all aspects of civil aviation, gives one example of an acceptable means of compliance to demonstrate that requirement as RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification, which is the framework authorities (such as FAA, EASA and Transport Canada) use to regulate commercial, software-based aerospace systems.
It clearly specifies requirements to define the intended functions around the software aspects of airborne systems and equipment, and the tests to prove them.

Boeing had serious problems with batteries bursting up in flames on 787 Dreamliners

It’s also important to note that these guidelines are not there just to make us create more documentation.
For example, some of the rigor that we need to go through is because of the battery fires on Boeing 787 Dreamliners in 2013.

So we need to be able to prove how exactly each requirement is fulfilled and by what part of the source code.

This calls for tools that make it easy to manage our work items towards each requirement and control what is committed to our Subversion repositories in a proactive way.
These requirements drove us to use Jira, Subversion, and subsequently Commit Policy Plugin for change control assistance.

How does Commit Policy Plugin help developers stay compliant?

Commit Policy Plugin helps ensure process compliance where essentially the reason why you are changing something in Subversion must be documented in Jira.

It does this by verifying all commits sent to the Subversion repository against pre-defined rules, and reminds the developer if something is not right.
It’s impossible to send in a non-compliant commit, so at code review we can just focus on what the software does and leave it to Commit Policy Plugin to check if the right conditions and references are in place.

This way, easy traceability is maintained where someone can look at the Subversion revision history containing the commit messages and find the documentation (Jira issue key the policy made us type in).

We also introduced the (more passive) Subversion ALM app, so looking at a Jira issue a reviewer can find where the change occurred in the code, as the Subversion commit message appears in an Subversion tab in the Jira issue.

What are the benefits of using commit policies in your Subversion repositories?

While we could write a regex anytime to detect if something that resembles a Jira ticket pattern is entered into the commit message, the commit policy’s JQL condition ensures that the ticket mentioned actually exists.

To give an example: you can put DEMO-72 into a commit message and it looks like a Jira issue key.
However, the commit policy can tell that, while it matches the required pattern, DEMO-72 does not exist because we are only up to DEMO-5.
Or, it exists, but it’s assigned to someone else in a different Jira project.
It saves you from creating incorrect or broken links.

It also saves you sometimes from simply typing the issue key in wrong.
Say, DEMO-893 was intended but I typed DEMO-839, the commit policy rejects my commit, saying that the issue mentioned is not in a status that I should be committing on.
So, in addition to keeping our developers on track with compliant code changes, it kind of acts as a spell checker, too.

As with most standards, the goal of DO-178C is to formalize a process where what is being done is easily reviewable and follows a common sense due diligence.
However, this results in 99% of the work generating documentation (well beyond what is discussed here) and 1% editing source code, so we apply the same rules to documents as we do to source code.
Thankfully the tools like Subversion help automate some of the documentation required to keep track of things, and Commit Policy Plugin reminds us to document what we are doing or that we need to have other people look at it before we dive into changing things.

What would be your message to someone hesitating introducing commit policies to their repositories?

When there is a process to be followed, then this is the tool to get.

It saves having a dedicated person babysit every transfer or document why the process was not followed.
If people follow the process at hand, then they should never even encounter the commit policy and it will be seamless.

You can scope it down to specific folders like the "tags" folder, or apply a rule to the whole repository that commit messages just can't be blank and not even use any Jira features like JQL.

The most difficult aspect is conveying to others what process you want them to follow, so with the commit policy in place it can be a trial by fire where your hard work does not get burned.