Why Do We Need an Automation Server?
Why Do We Need an Automation Server?
Automation helps keep your production rolling and is the solution for the desired continuous delivery process many small dev teams need.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
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.
Automate the Build
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.
Receive Fast Feedback
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 part is to discover the problem as soon as possible before another developer checks out the broken code increasing the problem.
Reliable and Secure
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, especially 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.
Easy Environment Setup
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.
Deploy to Test Environments
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 for operations to test the delivery, but also for developers to test new features. After all, we don’t want nasty surprises on production.
An extra advantage is the possibility of developers without operation knowledge to run the deploy to a test server. One less ticket to the list of the operation guy.
Deploy to Production
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 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 …
PS.: The Cyborg Developer initiative offers a FREE email course about software automation in 3 steps. You can subscribe here. You will also receive tips and tricks about automation directly to your mailbox (relax, I hate spam as much as you hate it).
Published at DZone with permission of Rodrigo Moutinho . See the original article here.
Opinions expressed by DZone contributors are their own.