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.
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:
Anyone can see the website being deployed to MyBit.io by inspecting the relevant Pull Request build on Travis.
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.
Conclusion
Web applications are tricky things. They require a thousand moving parts that are always prone to break at any moment. Due the nature of today’s applications architecture, more often than not, whenever a small piece breaks, the entire ‘machine’ breaks down too. Thus, to ensure the machinery stays perfectly oiled and working, continuous delivery makes sure that every change is double checked. After we have checked everything, we release the machinery for the community to test it.
Unfortunately, some steps of this process still require interaction with the MyBit team. Assigning tasks still requires the knowledge and capabilities of the team, as well as an understanding of expectations, in order to move forward quickly. The final decision on whether a change is deployed or not still falls to the MyBit team.
That being said, we’re building a future where we can move all decision making onto the application — giving ultimate governance to the community. Tasks can be assigned and developed automatically through a development platform like Gitcoin or Bounty0x. Dashboards can be created where reputable members of the community can decide whether these changes are incorporated into the final version. We’re still only seeing the first indications of what truly automated continuous deployment looks like.
On a side note, anyone that’s interested in learning about the Github terminology, and continuous delivery workflow, should check out the Atlassian guides for Git workflows and Continuous Delivery guides.
We’ll continue to work hard developing the MyBit platform. Every day, the team comes together from all over to world to continue to push our vision of an automated future. To survive, the application will need to grow on its own until one day it can be monitored and updated through decision-making councils and a fully-decentralized infrastructure. In short, a truly automated system to power the automated economy.
