Packaging and delivering software to the customer are common issues to any company. An automation server will speed up this process, configuring it once and running as many times as needed.
We are always reading about millions of deploys per day that the biggest companies in the world are doing. But large gaps between deliveries is a common pain for small teams. Most of the time they are focused on creating new features to the app forgetting to improve the delivery. That is where stress arises, at the deployment time.
Understanding the benefits of an automation server is crucial to improving this process. There is no need to stop everything to configure it, although it would be very interesting. However, spending a few hours per week to automate and configure your server would transform your delivery.
At non-automated environments, builds are done on developers’ computer falling into the trap of “it works on my machine”. Even using a version control system there aren’t guarantees that everything would work fine. If you forget an important file on the commit, your workspace continues to build but you have just broken the repository.
Here starts the Continuous Integration. The Automation Server could use the same commands used by developers to build the software and execute unit tests. After every new commit done into the source control the server will ensure the stability of the software. And if every commit is too much to your project there are ways to execute this process periodically.
An alternative is running the build after every new commit and executing the test suite a few times a day. Your build can take a few minutes and the tests hours.
Each project has a specific scenario to deal with. It’s up to you to judge and configure the best alternative.
Every task done by the server could generate reports and notifications. If a new commit breaks the build the developer receives a warning notification. Maybe it’s only a forgotten file at the commit but sometimes it’s a problem not identified before.
Builds aren’t the only problem. Everything may be working fine until the test before deployment. Why not execute tests multiple times per day and prevent this type of stress closely to delivery dates? Check often the business rules and identify any inconsistency in the project.
These notifications are very flexible warnings for the commit author or for the whole team. The essential is to discover the problem as soon as possible before another developer checks out the broken code increasing the problem.
Human beings have feelings. They have bad days, personal problems, pressure for results, many types of distractions, and so on. It’s common to forget a step mainly on a daily task. A well-defined configuration creates a stable process. The machine will never miss a single step.
Combined with this configuration the project earns a secure environment. Before the automation, only a few or maybe a single employee had the server access. But now only the Automation Server does tasks eliminating random accesses by users. Depending on the company the access is restricted via SSH blocking user/password access. It forces tasks automation, reducing bugs due to little manual adjustments.
Manual installations tend to create snowflakes server. Each one has a unique setup and behavior being the main cause of unknown bugs.
An automated installation allows the creation of homogeneous servers. Configuring a new server won’t be painful anymore. Even better, a disaster recovery due to hardware problems would be done by a consistent process. No more stress remembering what was done at the last installation.
Creating test environments using the same process as the production will enable deployments before sending it to the final customer enhancing your software quality.
This process is a great opportunity to operation guys test the delivery but also to developers test new features. After all, we don’t want nasty surprises on production.
An extra advantage is the possibility of developers without operation knowledge run the deploy to a test server. One less ticket to the list of the operation guy.
The main cause of stress is the production deployment. All the hard work needs to be right delivered to give the user the best experience.
After all the effort made in the test environment, the team has the confidence to replicate everything to production. All the steps executed by a single process.
But at the end, a chance of error still remains according to “Murphy’s Law”. So prepare an automated rollback process to avoid these sad events.
All previous topics will speed up any process. Avoiding manual builds and receiving fast feedback will maintain the team focused on what matters to the company. Not forgetting the developers’ happiness on having an awesome playground to make tests and a stress-free delivery.
There are many tool options on the market to start your Automation Server. Jenkins is an Open Source and one of the most used one. Written in Java it has a great variety of plugins to support almost anything on your project.
Travis CI would be a good option for projects hosted by GitHub due to your native support. And Bamboo a wise choice for Atlassian users owing to integration with JIRA and lots of other software they have. Another option for Jet Brains’ fans would be Team City.
Choose the tool that fits your project best and …