Skip to main content

Step 1: Jira, Confluence and Scope

I decided to use both Jira Software and Confluence. Jira Software is what most people associate with Jira - it's a ticketing system where,  fundamentally, tasks get put onto cards, those cards are assigned to people who then do them and check them off on the list. Sounds straightforward (like most of IT) but the details make it a little more complicated (again, like most of IT). Confluence is a documentation tool that is meant to be a way for teams to document seemingly everything. Like most of the software, there seems to be several ways to do the same thing.

Turning to Jira, I created a new project and chose to do a scrum project. I was thinking of doing a simple Kanban board which is a simpler process, but if you're going to do something, do it full bore.

Project created, I was presented with a menu consisting of

 - Scrum Board - Empty since we haven't set anything up yet
 - Backlog - Ditto
 - Active Sprints - Ditto
 - Reports - Ditto
 - Releases - Ditto
 - Issues and Filters - ditto
 - Pages - This was a documentation page which allows the user to connect to Conflunce
 - Components - Empty
 - Add Item - This allows adding new items to the project menu such as a link to Confluence, URLs or github repos.
 - Project Settings - To modify settings for this project.


Setting up Issues

I started to set up the project in terms of tasks, stories, epics, themes, and components. Under the latest level of scrutiny that I wanted to apply to the process, I started to question the actual difference between the different levels. Roughly put:

Tasks: the smallest level of atomicity of work on a project as to be a complete piece. Tasks might have checklists that go along with them but at that point the checklists are actions whose only context is the task. Tasks can be broken down into Sub-Tasks if needed.

Story: A way of communicating a tangible part of the project in a way that is clear, from a particular point of view and allows us to group together tasks.

Epics: At it's simplest, a group of stories

Initiatives: A way of grouping epics

Themes: Large areas of focus that might cross multiple projects,

Components: A way of grouping anything whether it be the narrative elements above, production teams, technology elements or whatever.

Bug: Something we thought was done but evidently isn't since it isn't working correctly.

Generically, all of these are called "issues". After being created, an issue is given a type which is one of the above.


Setting Up Jira

Given that I had a single specific project in mind, I figured that that itself was the Initiative. Without deciding which label to assign to them, I came up with the following "pieces" of my "initiative" which were more or less as follows:

  1. Project Management - Jira and Documentation
  2. Online Repo and Security - Git (at the moment Code Commit on AWS)
  3. Site Files - Our React, ColdFusion and other files which make up our site
  4. Local Scaffolding - The developer environment needed for the devs to do their work.
  5. Test Server Deployment - An online testing site which was the product of one CI/CD workflow. This is meant to simulate a site where a client or non-dev can see progress or check out features without having to set up a dev environment. 
  6. Production Deployment - This is the production site which is the end product of it's own CI/CD process which serves static files from CloudFront from an S3 bucket while the CF portion is served from a different server, providing that all tests etc pass. 
  7. Production Infrastructure - Issues of scaling, redundancy, db backups, failover etc. 
I decided that these could either be Epics or simple Containers. I decided that Containers seemed easier so I went that direction. 

Setting Up Confluence
There are many ways to link to Confluence but each of them required having a Confluence Space already set up. I decided to set up the space as if it was going to be an internal facing system. As a result, I created a "Software Project Space" and called it CICDBlog.

Jumping back over to Jira, I clicked on "Pages"  and then clicked on the ... icon in the upper right where I could connect the project to my CICDBlog space. Nothing specifically said that I was connected but the list of articles was consistent with what was in the Confluence space.

Final Thoughts
The project is shaping up as is a method of approaching the items. The jira ticket names might also double as blog post titles. 




Comments

Post a Comment

Popular posts from this blog

Creating Stories and Tasks in Jira: Personas and our Software Development Team

Part of the CI/CD Development Series The next step is developing who is on our hypothetical development team. Given that it has a React front end and ColdFusion as the Server Side language, I came up with the following personas, all of which have their own needs and considerations for our development environment. I've listed all the jobs that need doing, not the people involved since, even on a small team or a team of one, these "hats" are all worn by someone, even if it's the same person. Personas for our Project Dev Ops Coordinator - The person responsible for smooth and accurate deployments CF Developer - The person responsible for the API and fulfillment code development and maintenance. React Developer - The person responsible for the front end development Database Coordinator - The person responsible for the schema, data, up time and, presumably the testing databases used by the developers. Lead Developer - The person responsible for coordinat...
6 comments
Read more

As the Dev Ops Manager, I need to start planning our CI/CD release process

Part of the CI/CD Development Series Once we have our Deployment Diagram designed, we need to figure out out to get from here to there. If the end point is the appropriate server environment, the starting point is the developer with his/her hand on the keyboard. These steps take place on a variety of machines, within various process and can changes based on what files are checked in or not. At the moment, we've only created the early basics as seen below. The Beginning of our Deployment Activity Chart Even though there is quite a long way to go there are some elements which we have already been determined. For example We have determined the broad strokes of our technology stack. This is going to be React on the front end and ColdFusion on the server side. We have determined that we are going to be using linting on both the CF and React paths. CFLint for the CF and ESLint for the Javascript We have determined that we are going to be formatters - CFFormat for CF and...
Post a Comment
Read more

As the Dev Ops Coordinator, I need to set up our git repo into several branches with the appropriate permissions for each one

Part of the CI/CD Development Series The core of every CI/CD process is the code repository whether it be Git, Mercurial, SVN or whatever. The general idea is that it allows multiple developers (or whomever) to access your code in the appropriate way in the appropriate level. This can either be the ability for anyone to pull an open source project but not write to the repo directly or full access to a developer on your team to create branches, push to master or anything that needs doing. For our project, we're using git although the hosting provider was up for discussion between Github, Bitbucket by Atlassian or CodeCommit on AWS. We decided to go with AWS for two reasons. 1. We are going use other tools in AWS as part of the build so we decided to keep it all together. 2. We needed to solidify the ins and outs of using IAM for the process. Basic Steps Create the Repo Create the branches we need Use IAM to apply the appropriate permissions to each branch and to set up ...
1 comment
Read more