Skip to main content
TYPO3

Our Internal Workflow

Author
Published

In today's post we'd like to give you a glimpse into how we work, which tools we use and what the benefits of these workflow are to us. If you find this article helpful, you may also want to check out our TYPO3 YouTube channel. There, you'll find answers lots of frequently asked technical questions, instructional clips and all sorts of helpful videos. 

Basic Conditions / Setup

First of all there are some basic conditions to our work. We have a core of six people working directly for the TYPO3 GmbH at the moment, one of them part-time. Our main office is in Dusseldorf, where half of these people have their work space. The other half works remotely and is only present at the office once a month for a few days. Additionally we have people not directly working for the GmbH involved in our projects. For example these may be developers working on the reimbursement tool or as our server admins, who are paid by us but aren't employed at the GmbH. Some of the projects we are working on are open source software projects - this blog extension is a good example - so other contributors are welcome.

So in short we have the following basic conditions that determine our workflows and tools:

  • distributed team (one timezone)
  • remote work
  • ability to allow fine-grained access to the infrastructure
  • integrated workflows (documentation, CI, ticket system and repository hosting should work well together)

Software Decisions

Basically we decided to try working with the full atlassian stack, as we knew Jira as the best ticketing system for our requirements and expected good integration of the other atlassian tools out of the box - we don't want to spent a lot of time on our infrastructure if there is a possibility to get our demand met by an existing tool stack. We are using the following tools:

Basic Sprint Workflow

As in a lot of software companies today we are using an agile workflow, for the most part directly derived from the Scrum methodology. This means we have sprints (two week cycles of planned work), dailies and retrospectives. As mentioned before part of the team is mostly doing remote work, so all of our meetings take place online. We aim for a real life meeting once a month (preferably on a sprint planning day). 

On a "normal" day we have our daily at ten o'clock. As we are prone to forget the time while coding we have a Slack reminder setup at five to ten that reposts the link to the Google Hangout and reminds us to get ready for the daily. Usually we are having video chats as it feels more natural to be able to see the others. Regular dailies don't last much longer than 5-10 minutes, because they are just status updates for the team. During the day people post pull requests or requests for feedback in the slack channel - and sometimes we are even using a normal phone to call each other ;).

On a planning day we use the same hangout as for the daily but switch the Jira view from sprint to backlog. Mattes defines the most important topics for the company to work on before the planning starts - but everybody else may chime in with their important tickets (for example if there's some server configuration that needs to be done). After having defined what we want to work on for the next two weeks, we go and start working - planning usually doesn't take longer than an hour.

Development Workflow at TYPO3 GmbH

Of course we are also developing things at TYPO3 GmbH. Starting with elasticorn (which was a side project we needed for easy management of Elasticsearch indices of the TYPO3 website) and this website and blog we needed to be able to work collaboratively on various repositories. We decided to use "Git Flow" as git workflow. The nice thing about using git flow with the tool stack we have is that Atlassian supports it - meaning we get full support for feature branches out of the box. For example you can just click "create branch" on a story in Jira and it creates the matching feature branch. If bamboo is configured to run builds for all branches of this repository you can directly see wether your feature branch still builds successfully - and you don't only see that in the ticket or in Bamboo but also in the pull request. As a reviewer you have everything you need to dutifully review the code (the Jira ticket, linked confluence pages, build status) without us having to configure anything - it all just works.

Sidenote: Bamboo is even able to take the feature branches, merge them to develop, run the build and report back on wether the build would still succeed after the merge. So you basically get the security of a green build before the feature gets merged.

Handling Service Requests

As you may know we also have products including service requests and the possibility to ask us "anything" via our service portal. That service portal consists of multiple Jira Service Desks for our various products (and open source extensions). When you create a ticket there we'll get notified by email and the ticket appears on our big wall screen. Depending on the severity of the issue and the product it's reported for we configured different response times. Jira is automatically able to track time to first response and time to resolution with some nice graphics. As we are sprinting not every ticket is solved right away but we strive for a reply within one week. If it's critical we add it to the currently running sprint (we don't plan 100% of our time...), otherwise it gets added to the backlog and fixed in due time ;).

Open Source Tools and Contribution

When developing software at TYPO3 GmbH we always consider releasing it as open source - that's why this blog is now available in the TYPO3 Extension Repository and the repository for it is public. But Open Source means more to us than just publicizing the code - it also contains the possibility to take part in the development, give feedback and ask for features. As we described above we are using a toolset matching our internal development workflow - and as we release our software only when we consider it usable - all of our software gets developed on that stack. Fortunately its very easy to open these tools for others. Let's take the blog as an example again - you can just report issues and give feedback via service desk and request an account in our system for taking part in the development. Once you have that account you are member of a group called "blog contributors" which automatically gives you access to the corresponding Jira project, Bamboo builds and of course to the repository as all users and groups are managed by Jira and just used in the other tools. 

Conclusion

We tried to find a software stack supporting our workflows which requires as little maintenance and work as possible while still having a wide range of features for all the different use cases we are faced with. We think we have found that stack and it's working out quite well. Hopefully our glimpse into our working mode and structure was enlightening to you. Feel free to ask us for details if something is unclear (either here in the comments or via service desk)

Finding answers to frequently asked technical questions

You'll find answers to other frequently asked technical questions, instructional clips and all sorts of helpful videos on our TYPO3 YouTube channel. Come along and join us there. If you find this useful, please share the link on your network.