Building an entire DevOps infrastructure can seem daunting when you’re looking at the whole system, which is why it is important to break down the processes step-by-step and apply the best DevOps tools for the situation. I recently was sent on a month-long mission to do an A-to-Z implementation of the entire Atlassian suite (using Crowd, Jira, Confluence, Bitbucket and Bamboo) on a customer site. The company wanted to use the Agile methodology to manage the implementation of their IT projects, from the documentation creation, test automation (unit and functional) to the in-production deployment.
There was no need to reinvent the wheel because the steps in this process are more or less well-known — spelled out by experts in the ecosystem who use different methodologies. But building a DevOps infrastructure from the ground up highlights the integration between the different Atlassian products, detailing the strengths of the Atlassian suite compared to other products when it comes to DevOps adoption.
DevOps tools for the documentation
Agility requires that you constantly feed the development teams with information. Jira Software offers many features that simplify and facilitate the interactions between the Product Owner and the developers:
- A scrum backlog and the ability to refine and prioritize Stories.
- The creation and launch of sprints – in just a few clicks.
- Agile boards that adapt to your development process.
- Reports detailing the work which was done (notably, sprint reports).
Confluence is the collaborative tool that manages your documentation; therefore, it is a reinforcement to Jira Software. Gone are the days of unorganized Word documents, PDF, and Excel files. There’s no need to worry about directories on different servers without structured tracking. And you don’t have to search through a stack of emails to find the needed information. Everything is centralized in Confluence and linked directly to the development project.
For new projects, I created a dedicated Confluence space that is restricted only to the relevant team. Under this space, the initial business requirements are written in a new page. All the major functionalities which can be an Epic are created on this page. The corresponding functional specifications are written in another page, yet they are at the same hieratical level as the business requirements and are structured in the same manner.
Confluence allows you to create a new Epic issue in Jira for each functionality simply by selecting the text in the Confluence page:
When a table in a page for a feature is created, if the Epic is already linked to that page you can then select part of the table, thus creating one story per line. This will be directly linked to the Epic. You only need to select the columns containing the title and description.
The issues are automatically created in your project, linked to the Epic and are ready for use in your backlog. What’s more, each Jira issue contains a link that will take you to the Confluence page where you can fully detail the requirements and even use visualizations. Jira tickets are visible form the Confluence page of the Epic, thus giving you a global view of all related Stories and their progress. There is one entry point for the documentation and you don’t even need to go into Jira to create new Stories. You just need to create a new table add a line for each new request, and then repeat this process. It’s simple and efficient.
DevOps tools and development process
Continuous Integration and development methodologies like Test Driven Development have significantly contributed to quality development. Yet these methods are sometimes difficult to both understand and implement. This is the situation we came against when using GitFlow.
For someone who is a novice at Git, its philosophies can be bewildering. If you add into the mix Git Flow – which organizes the development of new features, releases and bug fixes – at this point part of your teams might be lost. Therefore, you need to organize your processes and train your main stakeholders – including but not limited to the developers, product owners and release managers.
We used Bitbucket, which like GitHub or GitLab allowed us to manage remote Git repositories. We defined a project by application or program and then created the repository deemed necessary (frontend, backend and service). Then we configured permissions at the project level (who could view and edit) and the repository level (for the different Git actions by refining the branch type).
We defined a first branching model in Bitbucket to implement GitFlow. In this model, the master, development, features, releases and hotfix branches all coexist.
This model provides a better organization for your repository. Consequently though, GitFlow requires a certain level of training and rigor on the part of the development team. Out-of-the-box, the feature providing the link between Jira Software and Bitbucket help guide developers and avoid errors. Below are two concrete cases where this integration between Jira Software and Bitbucket helps teams.
DevOps tools and developing Stories
Once the Sprint has been defined, it kicks-off and the developer takes a Story from the Sprint Backlog. He goes to the issue screen and clicks on “Create Branch.” He chooses a branch from Develop and chooses Feature as the type of branch. He only needs to checkout the local repository from the information in the remote repository (git checkout). All in two clicks!
In the same vein, the commits must contain identifiers for the corresponding Jira issue in order to be accepted. The challenge here is to teach these good practices to the developers.
DevOps tools for launching a release
Now we’ve moved to the part where the team just finished a Scrum sprint. The developers, Scrum Master and Product Owner agree on the functionalities offered by the product and have given the green light to put it in production. The team creates the following:
- A release branch from the develop branch that is named from the version number
- The same version number in the release of the Jira project links all the relevant Stories of this sprint, and potentially the previous sprint as well if it hasn’t been released.
The above are simple actions – just click a few times and enter information in a couple of fields, and you’re done. It is possible to set the functional scope of the release in both Jira and Bitbucket, thus facilitating work for the documentation (which we recommend Confluence) and for the product owner to run tests. If bugs are detected, they can easily be included in the same release.
DevOps automation tools for Continuous deployment
Here’s where Bamboo comes into play! Because of the integration with Bitbucket and Jira Software, we can automate certain tasks which are too time consuming for the developers.
The builds
In this case we’ve opted for a single build with a single deployment. This simplifies the configuration and thus makes everything more manageable.
In this build plan, a script verifies the type of branch the commit was pushed and carries out certain actions:
- The develop branch acts as the base branch. At each commit, the build plan is launched for each commit to create the deliverable.
- A plan is created manually for the master branch. When a commit is detected on this branch, the deliverable is created and published.
- A plan is created automatically for each feature branch. A compilation of the project and a code review are done with each commit on one of these branches.
- A plan is created automatically for each release branch and hotfix. These plans are manually launched by the developers to create the deliverable.
DevOps tools for following a Story’s development
After being able to easily create a feature branch, we can associate it with a Jira issue key. This allows us to effortlessly link it to the associated build plan.
Without really having to do much, we have additional traceability of our products.
DevOps workflow tools for after the release
In the same way, the view of the issues associated with a release presents the Jira branches, but also the builds that have been made. The people concerned on the business side can therefore know if the issues have been deployed in staging and preproduction (which practical for ongoing testing which makes frequent releases easier).
DevOps tools for the deployment
Each build can then be deployed on a clean environment. We created a deployment plan with the repository and created the necessary environment inside. Once these deployments are made, they are linked to the corresponding Jira issues. Everything is available within the ticket, including the summary of the associated release.
Finding the best DevOps tools for your needs
Having the right DevOps tools is crucial when transitioning to the Agility methods, such as continuous delivery, continuous deployment and continuous integration. And this is where the Atlassian suite really delivers. The integrations between the applications streamline the entire process. Regardless of how your business needs and team evolves, the documentation is always hosted in Confluence and linked to Jira issues. During the development lifecycle, the work done to these issues (code, build and deployment) is logged directly. Everything can be traced effortlessly, thus allowing people to direct their effort towards more important aspects of their jobs.
But there is not a guarantee that a DevOps methodology will be adopted, even when the right tools are installed. It’s imperative to define the proper processes that the tools and people will implement. This relies on having solid communications within the team, which can be facilitated with workshops and ongoing meetings with all the involved stakeholders. This helps to quickly address and resolve any technical and functional roadblocks.
Getting your DevOps process right and your tools configured is not by any means a small undertaking, which is why Valiantys is here to help. Click below to get in touch – we’d love to hear about your DevOps journey!
