Controlling the execution of multiple plans and jobs that can't run at the same time.

Here is an example of a simplified version of my problem. I have 4 builds that need to run. Let's call them OracleA, OracleB, MySQLA, and MySQLB. Neither of the Oracle builds can run at the same time and neither of the MySQL builds can run at the same time. This is easy enough to do by creating one Oracle agent and one MySQL agent.

The problem we're having is the added restriction that neither of the "xxxB" builds can be allowed to run at the same time either because the "xxxB" builds use common resources. Since we're already using the dependencies to control the Oracle and MySQL agents, we can't use an agent to control this third dependency.

At this point I've solved the problem by getting rid of the Oracle and MySQL agents so I could introduce an agent to make sure no "xxxB" builds run at the same time. I then made the OracleA and OracleB builds tasks in separate jobs that run in two phases of the same plan. This makes sure OracleA doesn't run at the same time as OracleB.

This will work in the short term. In the long term, though, we may need to add more Oracle plans (with Oracle2A and Oracle2B jobs, for instance) that share the Oracle resources with the first Oracle plan so we don't want them to run at the same time as the plan that contains the Oracle1A and Oracle1B jobs. Is there a better way to do this?

Note: Yes, we can separate out the schemas that are in use and have one for each plan but that requires more coordination with DBAs and variable substitution than we want to get into. We can do this but hopefully it's our backup plan..

3 answers

Yup, this is rather painful at the moment

Are you finally saying that you don't need any of the MySQL and Oracle stuff to run in parallel. I am a bit lost understanding the scenario. If that is the case a single agent (as you have done now) is the solution.

@Renjith V, No, I do not want the MySQL builds to run in parallel. I basically have the need to be able to assign two agents to a build: one for the DBMS type so no builds that use the same DBMS are allowed to run concurrently and another to assign to all of the "xxxB" stage builds so that none of them run concurrently.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published yesterday in Jira Ops

Jira Ops Early Access Program Update #2: Let’s talk severity levels

Welcome to your weekly Jira Ops Early access program update, where we’re sharing news and updates on Jira Ops' progress as we work toward our 1.0 release. If you ever want to drop us feedback or idea...

34 views 0 0
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you