Orbit is our first desktop application. As Orbit is a project that evolves continuously, it was necessary from the beginning to enstablish an optimized development workflow and think about how to deploy it. Moreover the first release of Orbit had a strictly short time to market, forcing us to adopt a flexible development worflow.
Scenario
Let's start with the following scenario: an user files an issue for a bug in Orbit and we need to fix it. The workflow is more or less this:
- Replicate the bug: this includes writing a new test in order to automate the replication.
- The code is changed to fix the bug.
- Tests are run to verify the bug is fixed and no other bugs are introduced by the changes. Orbit supports multiple OS so the tests must be run for each of them.
- A performance issue could have been caused as the code was changed, we need to check it by running performance tests. This requires also to simulate multiple clients with realistic behaviour of the usage.
- The program is packaged for Windows and OSX.
- Packages are distributed to the partners' servers.
- The client is updated.
The manual way
During the first stage of development most of these steps are executed manually, which means:
- The developer tests the application by hand, checks if the bug is really fixed and ensures nothing is broken. Actually it is always a good idea to try manually if the bugs are fixed, still regression tests by hand are simply inefficient and people usually test just some of the features of the software assuming most of them are not affected by the changes.
- Performance tests are run inside the team: the new version is distributed to the collegues and it is checked if everything is still working fine. Probably it is better to run it for a few days before going on. This means: the time loss affects the team, not just the dev.
- Installation packages are handly crafted, best luck you need to run a few scripts. This probably doesn't require so much time, still it raises the probability to have some errors: wrong code version, miss some metadata changes, the packages is not customized properly etc...
- Package distribution is handled manually.
- Users are notified to let them known about a new version of the software to download and install.
The workflow below is probably the worst case scenario (let's say I've trouble finding a worse one). The time and the cost required is high and generally this system makes the entire team less efficient as the people have to care about many boring stuff.
The automatic way
Automotion comes here to help us! All the steps of the workflow just described can be automated (unit tests, integration tests, performance tests, packaging, distribution of the packages, software self-upgrade) and also the triggers to make each step of the pipe run can be automated, so the dev after the fixing can just push a button and a software takes care of the rest: saves the changes and logs them, runs tests automatically, builds the packages and distributes them, and finally the desktop client updates itself.
Obviously this extreme automotion can be slowed down: before distributing the packages it might be helpful let someone check the new release and take the decision to go on or not. Still it's much easier to slow down the automatic workflow once you have it instead of speed up the manual one.