Ascend Integrated: Technology & Agile Management Solutions Blog

5 Free Ways to Boost Your Productivity in Jira

by Mike Brown | Sep 4, 2018 | Ascend Blog

If its free it can’t be that great, right?

There are a number of great, free add-ons / apps / plugins available for Jira server that will instantly boost your Jira or your team’s efficiency. We wanted to compile a list of apps you need to install and review now for your Jira instance. When compiling this list, we omitted apps / add-ons that required you to have a paid service (i.e. ZenDesk) or those that did not provide sufficient functionality / capabilities for your instance.

Keep in mind, all of those listed below are free and kept up-to-date with the latest versions of Jira Core / Software. Links to each of the apps have also been provided.

Jira Misc. Custom Fields

Jira Misc. Custom Fields is a tried and true, free app provided by Innovalog enabling custom calculated fields using standard or advanced calculations, new custom field types not offered out of the box with Jira, and new JQL features and functionality.

Automation Lite for Jira

Remove manual processes from your Jira instance by automating certain actions in your Jira instance, such as auto issue updates / creation based on certain actions taken on an issue. Automation Lite, while not providing all the functionality from Automation for Jira (both developed by Code Barrel), does provide the capability to automate basic Jira functions.

Timesheet Tracking for Jira

One of the biggest weaknesses of the Jira platform is the lack of out of the box reporting capabilities on time. Timesheet Tracking for Jira, developed by Touchdown is a free add-on / app allowing you to report on / track time logged. Pie charts and calculations are automatically conducted through the app. While lacking the advanced features of Tempo Timesheets, this is a great app for growing teams.

Color Cards for Jira

Now for our own shameless plug. =)

Looking to expand your agile practice, and want to make cards more easily identifiable or viewable to your agile team? Check out Color Cards developed by Ascend Integrated. This tool provides your team the capability to easily view and update cards in your agile boards using different color coding techniques.

JavaMelody Monitoring Plugin

Out of the box, Jira has limited monitoring capabilities for performance, relying heavily on third party tools to provide this information. JavaMelody, a free to download app / plugin provides this capability. By providing you with a direct link to reports and charts, its easy to identify performance bottlenecks, and understand times of high use.

Do you have a favorite free app / add-on you use for Jira Core / Jira Software? Let us know in the comments below!

Published by Michael Brown, CEO of Ascend Integrated. Image Source: Atlassian.com

The End of Stride and Hipchat

by Mike Brown | Jul 30, 2018 | Ascend Blog

If you can’t beat them, join them.

On Thursday, Atlassian announced the following in a public statement:

Atlassian today announced that it has entered into a strategic partnership with Slack. Atlassian currently has two offerings in the real-time communications market: Stride and Hipchat. With this partnership, Atlassian will exit the communications space. Slack has acquired the intellectual property for Stride and Hipchat Cloud, both of which will be discontinued. Atlassian will also discontinue Hipchat Server and Data Center and will be working with Slack to provide a migration path for customers of all four products.

Back in September 2017, at its release Stride was announced to be replacing Hipchat Cloud (and possibly Hipchat Server / Data Center). In fact, it was even touted as the “Slack killer” according to Reuters: https://www.reuters.com/article/us-atlassian-stride/atlassian-launches-stride-the-latest-would-be-slack-killer-idUSKCN1BI1R6.

How did we get here? What made Atlassian change course?

Atlassian has decided to focus on what they do best: organizing teams through their JIRA, Confluence, and Bitbucket (and other) tools, while discontinuing their real-time chat tools. The adaption of Stride among not only our clients, but across multiple teams has been lackluster.

There are several possible reasons why, being full-time Stride users internally in our firm:

Adoption: many clients and users have been hesitant to adopt Stride, citing lack of general add-ons/apps/extensions, and Atlassian storing data in the cloud. While definitely not a downside to small times, large organizations and government agencies prefer to control their data. This is why most have stayed with the Hipchat tools. Stride was only intended to be a cloud-based chat tool and was not planned to move a server / self-hosted environment anytime soon.
Usability: Stride’s user interface was simplified from Hipchat, however, because it was a relatively new tool and still under development until recently, users found its lack of integration with JIRA Server / Confluence server to be
Ever Present Defects: We love Atlassian, and all the great functionality they have provided through their tools. However, after Stride came off its Beta and was released into production, it has had bugs. Common for any new application hitting the marketplace. However, this puts a damper on customers adopting Stride.

With all this said, Stride and Hipchat helped make Atlassian the collaboration powerhouse it has become. Atlassian will now be focusing on improving its tool suite, and moving even further into the collaboration space. The relationship they established with Slack will only strengthen their position as they go to take on the tech giants Microsoft and IBM.

Now is the time to begin planning your migration to Slack. Atlassian will be reaching out to customers identifying this migration process.

Are you looking to migrate to Slack or another tool off Hipchat or Stride? As solutions partners, we can definitely help you, as there are plenty of add-ons available in the marketplace. Feel free to reach out to us!

Authored by Michael Brown – Atlassian Solutions Expert & Founder: Ascend Integrated. www.ascendintegrated.com

GitHub Acquisition by Microsoft

by Mike Brown | Jun 13, 2018 | Ascend Blog

The unthinkable happened last week: GitHub, a version control application used by developers to host and provide open source code / applications, has been acquired by one of the least open source companies, Microsoft for $7.5 billions in stock. With the acquisition, developers can only speculate the underlying changes to user policies, terms of use, pricing models, usability, etc. This also raises questions around Microsoft’s move into the Open Source technical stack and their moves into the space, first Linux Kernel and now its acquisition of GitHub.

If you use Github currently, what are your thoughts? Are you planning to stay with Github, or thinking of moving to another system altogether? Let us know!

Ascend Supports Launch of Miami AUG

by Ben Dickshinski | Mar 17, 2018 | Ascend Blog, Project Atlassian

When we opened our new office in Miami we saw an opportunity to support the launch of a Miami-based Atlassian User Group. This new space has improved our outreach efforts, and with this new AUG we want to be advocates for the use of Atlassian solutions in this vibrant and growing community. Small technology firms are booming in South Beach and we’re excited to be part of it.Yesterday we hosted the first Miami AUG, and used the event to discuss tips and tricks for getting the most out of the Atlassian ecosystem and showcased their newest tool: Stride. We enjoyed seeing some local users again, and were excited to meet some new ones. We hope that as we support further AUGs this community will grow and collaborate.

The date of the next AUG is TBD, so stay tuned.

Atlassian DC Team Tour

by Mike Brown | Mar 8, 2018 | Ascend Blog

For 2018, Atlassian has set up multiple team tours to various cities around the world showcasing and discussing product functionalities, use cases, and providing partners with the opportunity to feature their services.We will be one of the sponsors for the event, showcasing our services and capabilities alongside other Atlassian Solution Partners. Our experience ranges from implementing JIRA instances for tracking and managing policy development, to Confluence implementations for managing your security documentation and helping you maintain your Authority to Operate (ATO) certification. Sign up, and come by our area and chat with us…we look forward to seeing you there!

Migrating Your Atlassian Tools to a Cloud IaaS Provider

by Mike Brown | Mar 7, 2018 | Ascend Blog

Recently we’ve been working with our partners migrating the Atlassian Tool Suite (JIRA / Confluence / Bitbucket) from their server based instances to a Cloud Infrastructure Virtual Private Server (VPS) as a Service (IaaS) such as Azure, Amazon EC2, DigitalOcean, and Google Cloud. Based on our experience, we compiled a list of some points to contemplate before deciding to migrate from your physical server:

Instance Sizes: What sizes do you need?
Migration Costs: What expenses are you incurring moving to an IaaS?
Security Considerations: Migrating your SSL and ensuring your payment information is secure.
Disaster Recovery Policies: What types of disaster recovery policies do these IaaS providers have? Does it meet your needs?
Schedule & Time: When is the right time to migrate? How do you plan it?

Let’s expand on these points more:

Instance Type & Sizes

Are you looking to deploy a Data Center instance, or just a Server based instance? Depending upon this answer you may be able to use Amazon EC2’s or Azure’s Data Center deployment platform. These IaaS providers have developed a complete template for deploying Data Center instances in under one hour, with a complete set up and optimized server configurations. For single server instances, review the number of users and number of concurrent users you have during high, medium, and low periods of usage. Do you need an 8GB instance with 4 CPUs, or can you get away with a 4GB instance with 80GB of SSD space? Instance / memory, Disk space, and data transferred are all parameters to consider before choosing an instance type. Other questions to ask: Do you need a separate database server or RDS instance? Its normally recommended to separate your Application and Database servers, but something you need to consider. Also, what type of OS are you comfortable using (and does the IaaS provider have it)? All of this will help you determine the technical aspects of your instance, and will directly impact your hosting costs.

Migration Costs

Consider the expense and costs from several approaches: licensing costs, instance costs, and maintenance costs. Atlassian Tool licensing costs generally do not change moving from your local / server instance to an IaaS as you are simply moving from one server instance to another. Instance costs vary differently between providers, DigitalOcean’s costs are different from those from AWS EC2 and Azure. Be sure to research different types of instances, and determine what instance type is optimal for your team. Finally, maintenance costs, you will not be required to maintain a physical server in a data center. This is taken care of by the provider. You will just need to ensure your instance’s OS remains updated and security patches are applied. Your days of moving and replacing physical servers in a freezing data center are over, you’re off the hook!

Security Considerations

Always make sure you maintain any security policies and procedures you had working in your local instance. You will need to import your SSL certificate into the IaaS provided instance, and update any Apache / IIS / NGINX configurations. Be sure the instance version you install in the IaaS matches the version you have installed locally as well. Review the types of continuous monitoring tools your instance may come with, or if you can install and connect your tools to these IaaS instances. Finally, when you create your core administration user account, be sure to use an email and password that is secure and kept within your organization. Ensure other members of your team have company accounts and share instance data / configurations with them. With that, keep the number of users who have access to the instance configurations to a minimum. You do not want too many cooks in the kitchen.

For the Federal contractors and employees, is it FedRAMPed?!

…Some common, but important points to think about!

Disaster Recovery Policies

Review all disaster recovery policies, procedures, and types of DR architectures your IaaS provider supports. How is your Virtual Private Server (VPS) backed up? EC2 enables support for multiple types of DR architectures and procedures. DigitalOcean provides the capability to back up your entire instance (server configurations, OS, web server configurations, and Atlassian applications) with the click of a button. Determine how much a server snapshot may cost to store with the provider, and factor this into your expenses. Be sure to read about all services provided for each IaaS provider.

Always remember, your Atlassian Tool data and configurations can be backed up using a scheduled backup job. Be sure to set these policies at the application level as listed below for JIRA, Confluence and Bitbucket.

Schedule & Time

Plan to migrate your Atlassian Tools to the cloud IaaS during a period of low usage (weekends, holidays). This ensures no one is attempting to log issues or create spaces / pages in your instances. Be sure to shut down your current implementations before migrating so no data is lost while your Atlassian Tools are down for maintenance. If it is an external / customer facing instance, be sure to have a re-direct page providing customers with contact information or a contact form to record any issues / bugs while your tool is migrated. Ensure you provide ample notification for customers and / or internal users. Communicate out 2 weeks in advance at least and field any questions from users. And remember, always create a full backup of your instance!!

While this is by no means a comprehensive list, we hope this blog post helps you and your team as you begin considering the migration to an IaaS. As always, feel free to reach out to us if you have any questions!

Atlassian Summit 2017 Recap

by Mike Brown | Feb 26, 2018 | Ascend Blog, Project Atlassian

New User Interfaces for Cloud Products

The Atlassian Tool Suite for the Atlassian Cloud is getting a face lift. Over the next several months, new user interfaces for many of the tools in the Cloud (specifically Confluence, JIRA Core, JIRA Service Desk, and JIRA Software) will be released. Booths were set up near the entrance of the Exhibit Hall for users and passersby to test and provide feedback for the new user interface. While these new User Interfaces are not making it to the server instances yet, it paves the way for a redesign of the Atlassian User Interface.

Sessions and Classes

Breakout sessions were informative, and provided insight into many aspects of the Atlassian Tool Suite, from tools and techniques used at large tech firms and systems such as Netflix and LinkedIn, to developing custom add-ons, integrations, and improving performance in JIRA and Confluence. You can check out over 10 hours of recorded breakout sessions here…just don’t watch them all at once: Wednesday Sessions and Thursday Sessions.

Will we see you in Barcelona next year (2018)?

We hope you had a great time last week. Find us on Twitter and share your favorite experience at Atlassian Summit. We look forward to seeing everyone again in Barcelona for the 2018 Summit!

Day(s)

Hour(s)

Minute(s)

Second(s)

Jira’s Scalability: What to Expect

by Mike Brown | Feb 26, 2018 | Jira

As 2017 came to a close our team at Ascend Integrated asked ourselves a simple question: How does the Jira ecosystem exist within a small team? As many project management solutions have gone all-in on Enterprise solutions, Atlassian has maintained that Jira is prime for small teams while also possessing supreme scalability through the SAFe methodology within Jira. In this blog, we’ll explore how small teams can utilize Jira to its fullest extent.

Price

One of the most important features that make Jira small-team-friendly is cost. As many agile teams look to transition from the sticky-note on the whiteboard phase over to a project management tool, cost becomes a major factor. The cost for the cloud instance of Jira for 1-10 users is only $10 per month. Plus, adding users is quite easy and will cost you an additional $7 per user up to 100 users. As your team grows, your cost per user actually decreases. We would also recommend you go with annual pricing if you know that you will be using Jira for the foreseeable future.

Flexibility

Agile teams need the ability to work with speed, cohesiveness, and autonomy within the context of a single platform. Jumping between different project management tools wastes time and can cause confusion between departments. With Jira as your central hub, you have the ability to connect to products like Confluence and BitBucket. Jira’s seamless integration with these tools will allow your team to store development documentation, decompose team silos through open communication, and track development issues throughout the development lifecycle. Working with project managers, back-end engineers, and designers has never been easier thanks to these integrations.

Functionality

We’ve discussed price and flexibility, including two great integrations with Confluence and Bitbucket, but how does Jira itself standout from a user perspective? Jira’s custom workflows, JQL functionality, and personalized Kanban and SCRUM boards allow for members from all teams and skill levels to utilize Jira in a way that best suits their team while simultaneously tying back to the same projects. The beauty of Jira is that you can make it as simple or complex as your team needs, meaning once you of understanding vast amounts of customization at your disposal, you have complete autonomy over your workflows, visualizations, and tracking initiatives.

The Case for Collaboration

Jira certainly isn’t the only project management tool with flexibility and scaling ability, however, it is the best tool currently available with added documentation and repository integrations and some serious out-of-the-box usability for a small-team budget. If your team is looking for a low-risk project management solution to start off the new year, then we strongly suggest giving Jira a try!

Atlassian Summit 2017

by Mike Brown | Aug 25, 2017 | Ascend Blog, Project Atlassian

The Atlassian Summit in San Jose is fast approaching! Between the excitement of the keynotes, partner day, bash, and the exhibit floor partners and decision makers, the week will be filled with opportunities for networking and education on agile and the Atlassian tool suite.

As an Atlassian Silver Solutions Partner, we’d like to take a moment to share some thoughts on what we’d like to see this year at Summit:

New JIRA Capabilities: JIRA has expanded greatly in functionality since 2015 and its continued growth is a testament to a strong following and user base. We’d like to learn what Atlassian is planning for JIRA 7.5 and beyond!
Confluence Integrations: Confluence has had limited integrations with other Atlassian tools in the past. What can we expect going forward?
Bamboo’s Next Steps: Where are we going with Continuous Build and Integration? What will happen with Bamboo, and will Bitbucket’s build capabilities be expanded to incorporate more CI capabilities?
Trello: What will the future of Trello look like, now that Atlassian has purchased the firm? How will it be incorporated into the Atlassian tool suite?
Future Integration Capabilities: In 2015 we got Atlassian Connect, but what does the future of the Plugin SDK look like?
Atlassian Cloud capabilities: Will we be able to integrate LDAP to the Cloud? And what about the ability to create our own URLs?

If you have any questions in the meantime regarding the Atlassian tool suite, visit our site and learn more about the tools and our capabilities: https://ascend.zellecloud.com/what-we-do/atlassian/.

Integrating JIRA and SSO Using CAS

by Mike Brown | Aug 1, 2017 | Ascend Blog, Project Atlassian

By default, Atlassian JIRA has an internal directory, integrates with LDAP / Active Directory, and integrates with a Single Sign On (SSO) solution: Crowd. However, a growing number of administrators are looking to integrate their Atlassian solutions across their enterprise Central Authentication Service (CAS). We decided to write this blog based on the original work put together by the JASIG team: CAS Configuration. The original code repository can be found here if you’d like to build the JAR files yourself: https://github.com/apereo/java-cas-client. A more detailed account along with code snippets can be found on our blog here: https://ascend.zellecloud.com/ascend-blog.

While the JASIG team created an excellent entry, we wanted to build on its success by adding easy-to-find download links, updated XML entries, and some additional details or directories / locations. This entry includes details on integrating with JIRA 7.x running on a Linux-based server.

The five steps we are covering here include:

Shutdown JIRA + Know your File Locations
Copy the JAR Files
Modify web.xml
Modify seraph-config.xml
Start JIRA

While this is meant to be an overview and will help in getting your JIRA to communicate with your CAS system, it is not meant to be a full setup of CAS, or a full JIRA configuration / set up as well. This article is for semi-advanced users and administrators. But, with that said if you have any questions as you go through it, please feel free to reach out to us: info@ascend.zellecloud.com.

Step 1: Shutdown JIRA + Know your File Locations

First, make sure JIRA is shut down.

All files discussed here will exist in the following locations (note, JIRA_INSTALL by default is set to the /opt/atlassian/jira/atlassian-jira/ directory). The list of the files to be modified / copied are below as well as their locations:

seraph-config.xml: JIRA_INSTALL/WEB-INF/classes
web.xml: JIRA_INSTALL/WEB-INF/
CAS Client for Java Core: JIRA_INSTALL/WEB-INF/lib (needs to be copied here)
CAS Client for Java Atlassian Integration (for JIRA 7): JIRA_INSTALL/WEB-INF/lib

NOTE:
You can download the updated CAS clients (v3.3) that will be used along with the Jira7 JAR files from our Bitbucket repository here (download both files): https://bitbucket.org/mbrown_ascend/jira-cas-integration/downloads/

Step 2: Copy the JAR Files

After you have downloaded the files above (CAS Client for Java Core v3.3.3 + CAS Client for Java Atlassian Integration v3.5), copy both of these JAR files both into the JIRA_INSTALL/WEB-INF/lib/ file directory.

Step 3: Modify web.xml

Open up web.xml in your favorite text editor. We used VIM for most of these modifications. Around line 374, just above the “THIS MUST BE THE LAST FILTER IN THE DEFINED CHAIN” comment, add the following code (Wherever it says to add your specific information):

<!-- CAS:START - Java Client Filters -->
 
<filter>
   <filter-name>CasSingleSignOutFilter</filter-name>
   <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
</filter>
<filter>
  <filter-name>CasAuthenticationFilter</filter-name>
  <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
  <init-param>
    <param-name>casServerLoginUrl</param-name>
    <param-value> Include your CAS login here </param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value> include your JIRA url here </param-value>
  </init-param>
</filter>
<filter>
    <filter-name>CasValidationFilter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
        <param-name>casServerUrlPrefix</param-name>
        <param-value>Include your CAS login here</param-value>
    </init-param>
    <init-param>
        <param-name>serverName</param-name>
    <param-value>include your JIRA url here</param-value>
    </init-param>
    <init-param>
        <param-name>redirectAfterValidation</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
 
<!--- CAS:END -->

Next, around line 627, there will be a filter mapping for your login, something like this:

    <filter-mapping>
        <filter-name>login</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher> <!-- we want security/login to be applied after urlrewrites, for example -->
    </filter-mapping>

Above the filter mapping code listed above, copy and paste the following:

<!-- CAS:START - Java Client Filter Mappings -->
 
<filter-mapping>
   <filter-name>CasSingleSignOutFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>CasAuthenticationFilter</filter-name>
    <url-pattern>/default.jsp</url-pattern>
</filter-mapping>
<filter-mapping>
    <filter-name>CasValidationFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
 
<!-- CAS:END -->

You can just copy / paste this code directly. After you have finished, save the web.xml file (in the VIM editor type ESC and then “:wq”).

Step 4: Modify seraph-config.xml

Next, you must make the following modifications to the seraph-config.xml file. In your seraph-config.xml file, there should be series of parameters. This is where you will make the modifications. Look at the code below, once again any area below that states “add your CAS URL…” is what you will need to modify.

<init-param>
    <!--
      The login URL to redirect to when the user tries to access a protected resource (rather than clicking on
      an explicit login link). Most of the time, this will be the same value as 'link.login.url'.
    - if the URL is absolute (contains '://'), then redirect that URL (for SSO applications)
    - else the context path will be prepended to this URL
 
    If '${originalurl}' is present in the URL, it will be replaced with the URL that the user requested.
    This gives SSO login pages the chance to redirect to the original page
    -->
    <param-name>login.url</param-name>
    <!--<param-value>/login.jsp?os_destination=${originalurl}</param-value>-->
    <param-value>add your CAS URL here</param-value>
</init-param>
<init-param>
    <!--
      the URL to redirect to when the user explicitly clicks on a login link (rather than being redirected after
      trying to access a protected resource). Most of the time, this will be the same value as 'login.url'.
    - same properties as login.url above
    -->
    <param-name>link.login.url</param-name>
    <!--<param-value>/login.jsp?os_destination=${originalurl}</param-value>-->
    <!--<param-value>/secure/Dashboard.jspa?os_destination=${originalurl}</param-value>-->
    <param-value>add your CAS URL here</param-value>
</init-param>
<init-param>
    <!-- URL for logging out.
    - If relative, Seraph just redirects to this URL, which is responsible for calling Authenticator.logout().
    - If absolute (eg. SSO applications), Seraph calls Authenticator.logout() and redirects to the URL
    -->
    <param-name>logout.url</param-name>
    <!--<param-value>/secure/Logout!default.jspa</param-value>-->
    <param-value>add your CAS LOGOUT URL here</param-value>
</init-param>

After you have finished with this modification, scroll down to around line 93, and comment out SSOSeraphAuthenticator and JIRASeraphAuthenticator lines:

<!-- CROWD:START - If enabling Crowd SSO integration uncomment the following SSOSeraphAuthenticator and comment out the JiraSeraphAuthenticator below -->
    <!--
    <authenticator class="com.atlassian.jira.security.login.SSOSeraphAuthenticator"/>
    -->
<!-- CROWD:END -->
 
    <!-- CROWD:START - The authenticator below here will need to be commented out for Crowd SSO integration -->
    <!-- <authenticator class="com.atlassian.jira.security.login.JiraSeraphAuthenticator"/> -->
    <!-- CROWD:END -->

Add the following to this section instead:

<authenticator class="org.jasig.cas.client.integration.atlassian.Jira7CasAuthenticator">
        <init-param>
            <param-name>casServerUrlPrefix</param-name>
            <param-value>include your cas server here</param-value>
        </init-param>
        <init-param>
            <param-name>serverName</param-name>
            <param-value>include your JIRA server URL</param-value>
        </init-param>
</authenticator>

From there, save and close the file.

Step 5: Start JIRA

After you start JIRA instance, go to a browser and type in your JIRA URL. You will be re-directed to your CAS Client.

If you are having issues with your configuration, please reach out to us anytime! We have completed CAS configurations in multiple environments using different versions of CAS. If you have any questions about this blog or about integrating your Atlassian Tool with multiple SSOs, send us an email at info@ascend.zellecloud.com.

« Older Entries

Next Entries »