What are the next gen. projects in the Jira cloud?

Hi, my loving friends. Welcome to this course. In this article, I will explain to you about the next-gen project. This is the new feature of Jira and atlas Sian introduced it in the year 2018 so, let’s have a look at the agenda of this content. In this, we will learn what are the next-gen projects, how to create next-gen projects? How can we create issues and add issue types in next-gen projects and how to configure the board? So. Let’ start.

What are the next-gen projects?

Next-gen projects are the newest projects in Jira software and it is only available on the cloud platform to the server one. If you are using a server the server platform and you wouldn’t be able to sit. The third one is configured by project team members. Any team member with the project’s admin role can modify the setting of their next-gen projects. There is no need to take the help of the Jira administrator to add the issue types and to add some fields to your screen. The Fourth one is it is easier and faster to configure than classic projects. You can easily configure setting like issue types and fields with drag-and-drop editing and reordering all in a single place because the best part of next-gen projects is the ability to enable and disable the features and it allows you to scale your projects as your team grows and tailor your projects to your team changing needs so, this is the best thing in the next-gen projects. And before going forward, I would like to tell you one more thing like atlas Sian is building the next-gen Jira software from the ground up.

How to create next-gen projects?

So, it doesn’t yet have all the features that classic projects have. And they are a lot of differences between the next-gen and the classic projects like if I’m talking about the configurations then in the classic projects. We are able to share the configurations from one project to another. But in the next gen, you can’t share it. If you did some configurations for the particular projects in the next-gen, you wouldn’t be able to share that configuration with another project. And there are many more like estimations in the classic projects, you have the options, you can give the estimations in story point in your basis but in the next-gen, there is only one option is available and that is a story point. If you will go to the next-gen cloud instance and see how can you create the next-gen projects and configure them? There will be your cloud instance and you will create the next-gen projects from there. You will see that there will be two options are available one is classic and the other is next-gen. if that particular option is created out for you then this is the permission issue so, before creating the next-gen project. I would like to tell you about the permission so, once you will click on the Jira setting and go to the global permissions, there will be your global permission schema, and create next-gen project option will be there. At the time, you will have permission to create the next-gen project. You will click on the next-gen project and you will see the interface is similar to the classic.

You can simply change the template from there but you will see only two templates are available one is scrum and another one is Kanban. If you will go with Kanban and name the project, you will see the access option (open, limited, private) and project key as a classic one. If you want to change the project key then you can do it there. You will go forward to clicking the create button then the next-gen project board will appear which would be similar to the classic one but what is the difference and how can you identify that this is the next-gen project but what will happen? If you will haven’t created it yet you didn’t create it. Maybe, you are using the project which is created by another one. You will see in the bottom line that you are in the next-gen project. You can find out and identify that you are using the next-gen project. You will see there are the options which are roadmap, board, pages, add an item, and project setting. A Roadmap is a good option which is given by the next-gen project. I will discuss this later in the course. I hope this will give you exact direction in the way of your Jira learning and about its next-gen project. So, you will stay tuned with this course for further next information regarding Jira next-gen project.

Related Video:

Tagged : / / / / / / / / /

Customize changelist description field with templates

rajeshkumar created the topic: Customize changelist description field with templates
The way most of our customers add additional fields to the change description is with the use of triggers and scripts that add extra fields within the “description” field.
As an example:



import os
import sys
import re
import random

users = [ “cpflaum”,”cpflaum2″ ]
user = sys.argv[2]
user = user.lower()

if user in users:
tempfile = str(random.random())
input = open(sys.argv[1], “r”)
output = open(tempfile, “w”)

for line in input.readlines():
if re.search(““, line):
output.write(“\n\tMy Additonal field 1=\n”)
output.write(“\n\tMy Additonal field 2=\n”)


os.rename(tempfile, sys.argv[1])

By – Chuck Pflaum <support@perforce.com>
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Templates in InstallAnywhere

installanywhereExpert created the topic: Templates in InstallAnywhere
A template is the starting point for every new installer project. A template can be a
simple empty project, or it can contain everything a regular project would contain,
such as license agreements, custom graphics and billboards, and even files.

Tagged :

Build Configuration Templates in Teamcity | Teamcity Guide


Going meta with Meta-Runners in TeamCity

We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters.

Meta-Runners provide a straightforward way to create custom build runners. Meta-Runners can be thought of as a way to avoid duplications in build steps across build configurations.


While templates can be used to create and maintain build configurations that are very similar, Meta-Runners can be used across build configurations that perform the same build steps. Moreover, a build configuration can only be based on one template, but it can make use of multiple Meta-Runners.

In Chapter 3, Getting Your CI Up and Running, we created the deploy-to-test build configuration that deploys the Django application to Heroku. Using this build configuration as an example, we can see how we can extract a Meta-Runner Deploy To Heroku that can be used by any build configuration that wants to deploy to Heroku.

Recall that the deploy-to-test build configuration had a simple command-line runner that executed the following commands:

git remote add heroku git@heroku.com:django-ci-example.git  git push heroku master

To create a generic Meta-Runner out of this, we need to provide a way to push to any remote, rather than just git@heroku.com:django-ci-example.git.


Deploying to Heroku using remotes needs the ssh keys to be set up on the agent. The example used here just illustrates Meta-Runners and may not be ideal for production use.

As mentioned in Chapter 6, TeamCity for Ruby Projects, we can use a gem such as heroku-headless (https://github.com/moredip/heroku-headless).

As expected, we will do this by extracting the remote out into a build parameter. The command-line runner will have the following as the Custom Script to be run:

git remote add heroku %heroku.remote%  git push heroku master

We will provide the value for the %heroku.remote% parameter in the Build Parameters section of the build configuration.

Now we are ready to create a Meta-Runner from this build configuration. This can be done by clicking on the Extract Meta-Runner button in the right-hand side bar of the build configuration settings page. This brings up the Extract Meta-Runner dialog, which is shown in the following screenshot:

Going meta with Meta-Runners

In the dialog, we give a name to the Meta-Runner. This is the name that will appear in the Runner Type field when configuring a build step for a build configuration.

Click on Extract to create the Meta-Runner. Once the Meta-Runner is created, we can see it listed in the Meta-Runners tab on the project administration page. We can also edit the Meta-Runner to fine-tune it as desired.


A Meta-Runner is essentially an XML configuration (much like most TeamCity configurations) that can be edited directly from the web interface.

The following screenshot shows the edit page of the Deploy To Heroku Meta-Runner that we just created:

Going meta with Meta-Runners

The Meta-Runner extracts all the parameters and steps defined in the build configuration. We can edit the Meta-Runner to have only the necessary parameters and steps.

Using Meta-Runners

We can now use the Meta-Runner that we created pretty much like a normal build runner. We will remove the existing build step in the deploy-to-test build configuration (from which we extracted the Meta-Runner) and add a Deploy To Heroku Meta-Runner-based build step.


We can also disable build steps if we don’t want to remove them while experimenting.

In the New Build Step page, for the Runner type field, the newly created Deploy To Heroku Meta-Runner is available, as shown in the following screenshot:

Using Meta-Runners

Once we choose the Deploy To Heroku Meta-Runner, we can see that the heroku.remote parameter is one of the fields to be configured. Since we created the Meta-Runner with the heroku.remote parameter with the value git@heroku.com:django-ci-example.git, that remote is available by default. The Deploy To Heroku runner configuration page is shown in the following screenshot:

Using Meta-Runners


It is possible to remove the value for parameters in the Meta-Runner XML so that no default values are present for the fields.

We can click on Save to add the build step. The new build step, based on the Deploy To Heroku Meta-Runner, will function in the same way as the previous build step based on the command-line runner.


Of course, the value of Meta-Runners becomes more apparent when we create them out of multiple build steps. The same set of steps that may be repeated across multiple configurations can be extracted into Meta-Runners.

Reference Book – Learning Continuous Integration with TeamCity by Learning Continuous Integration with TeamCity

Tagged : / / / / / / / / /