Building an Automated, Open-source and Decentralized Application

When building a decentralized application, it's necessary for its development to be able to work on an automated way, without relying only in a specific individual.

au·to·ma·tion the use of largely automatic equipment in a system of manufacturing or other production process.

What does automation mean when building an application? If we take the formal definition by Google, automation is the enhancement of a production process through the addition of a series of systems. Although this usually applies to manufacturing processes, in the software development industry we use the same principles by creating processes that improve the development of a product.

At MyBit, we use a Continuous Integration and Delivery system as part of the development of the MyBit platform. Every step of the application is double checked by our integration layer to ensure these changes satisfy our own internal requirements. After all checks have been passed, we then deploy the application externally to use it as the production application for our users.

The following article describes how we go from identifying issues or future features of our application, to having these changes deployed. Bear in mind some processes are still in progress, so there might be some hiccups along the way.

Identifying issues

The first step for starting the automated process is to visualise any bugs or issues the application has. In a previous article, we showcased how you can help MyBit by reporting issues you might have encountered on our website or application.

After successfully seeing how we can integrate Github issues with Asana (our project management tool) through Unito, we can then enable issue tracking for all our major projects, like the MyBit Platform smart contracts.

By doing so, these issues are then reported to our internal board in Asana, where we can assign and organise them as part of our next step in the process, which is Week Planning.

Assign them to our workflow

After an issue has been reported in any of our projects on Github, it’s then shown on our Asana board, ready for grooming, which is an Agile Development practice that allows teams to organise and plan their work around small sprints. In our case, we do weekly sprints and try to estimate our work every Monday to see what we can tackle that week.

Our Asana board allows us to organise ourselves per week based on the reported issues. Anyone can report an issue to our projects through Github.

The work is then assigned to the most suitable person in the team, who will then organise it into a Week Sprint, and tackle the task as required. When the work is done, the individual will perform a Pull Request against our project, and the Continuous Integration process begins.

Triggering reviewable and testable builds through Continuous Integration

In most projects, we have a series of tests that ensure any addition to the application does not break the current functionality of the system. These can be from command line tests to visual regression tests. For instance, in the case of our website, we are more worried about visually comparing the changes made against the production site more than anything else.

Continuous Integration In software engineering, continuous integration (CI) is the practice of merging all developer working copies into a shared mainline several times a day.

By definition, CI allows us to visualise these tests results. At MyBit, we use both Travis and CircleCI to test each project. Here are the links to the MyBit website builds.

When a change is made against an application through a Pull Request, both Travis and CircleCI create a browsable URL that can be tested and reviewed. These URLs are being built with Zeit.co's Now, giving us the potential for instant deployments. The following Pull Request shows how a build can be seen by anyone (as proof that any changes made were completed properly).

Merging and deploying

After successfully checking that the changes made:

Do not break any existing code or the nature of the application

Do not expose any technical or visual issues

Have been reviewed, and approved, by at least one contributor

We can then proceed to our production deployment process. These processes all take place in the open, and can be done by simply creating another Pull Request in Github. The only difference is that for production deployment, requests can only be made by MyBit team members and need to follow our Git Forking Workflow.

In short, a deployment to production looks like this:

In addition to our normal test reviews, Production Builds require additional tests — such as visual continuity with the production URL and our staging URL (unless it's meant to do that, of course).

Anyone can see the website being deployed to MyBit.io by inspecting the relevant Pull Request build on Travis.

After merging the deployment to production Pull Request, Travis communicates with Zeit, where our production website is located.

The workflow concludes after the deployment and production Pull Request is merged — until it starts again, with a new feature to develop or a new bug to squash. In practice, we start and finish this process multiple times every week, if not every day. Anyone at MyBit can deploy to production from Day 1.