Víctor García, DevOps Engineer
Blog post series: part 6 (the very last one)
You can read the previous post here.
![]()
Most of you have probably heard talks or read articles on the Internet about continuous delivery, continuous integration and all of these cool agile methodologies where everything relies on automation.
For the skeptics, here at Tuenti you can see that sooner or later, they pay off.
Maybe you can think that changing your development workflows and the developer culture would take a lot of effort. Ok, it may not be straightforward, but it’s worth to try.
I’m not going to explain why doing smaller but more frequent releases is better, or why doing things manually is not the way to go, or why continuous integration reduces the number of bugs because you probably are tired of hearing the same again and again and because you can easily find that information by googling it.
Here are some tips that might help you make such changes in these more complicated settings:
If everything is automated, it should be easy to gather information and show it company-wide; the release state, the next code that will be released, what that code does, what bugfixes it will include, who the author is, its risks, how to test it, etc.
Create a dashboard that everyone can see (a good design will help), so you can make them aware of, for example, when a new feature is going to be released. This way, for example, the communications/press team can make an announcement or the marketing people can prepare campaigns in time. Otherwise, they will ask you personally and in most of the cases, this is a waste of either your or their time.
Here is a list of some of the things we would still like to do:
Blog post series: part 6 (the very last one)
You can read the previous post here.
Success
There is nothing I can say other than the fact that all of this has been a great success for the company. The new process and all of the changes we introduced have improved developer throughput, has speed up the development workflow, has nearly achieved continuous integration and delivery, and in the end, we work better. The site and mobile apps have fewer bugs and overall, we’re very proud of what we’ve done:- Self service dev environments: disposable, ready to use, less support required
- All manual processes automated: less time, fewer errors, more accounting
- Well known processes: used in every project, less support required
- Automated pull request: ensure testing and “ever green trunk” what in turn improves continuous integration and people integrate more often.
Buzzwords on the Internet and in Talks: Continuous Delivery/Integration, Agility, Automation...
Most of you have probably heard talks or read articles on the Internet about continuous delivery, continuous integration and all of these cool agile methodologies where everything relies on automation.
For the skeptics, here at Tuenti you can see that sooner or later, they pay off.
Not Following Them? Why Not?
Some of you may think that in your company, things are working just fine the way they are and that you don’t need to change them. You may be right, but what you might not know is that things could be even better. Why not always be ambitious and go for the very best?Maybe you can think that changing your development workflows and the developer culture would take a lot of effort. Ok, it may not be straightforward, but it’s worth to try.
I’m not going to explain why doing smaller but more frequent releases is better, or why doing things manually is not the way to go, or why continuous integration reduces the number of bugs because you probably are tired of hearing the same again and again and because you can easily find that information by googling it.
How to Change
In newer, smaller companies, changing processes is not as hard as it is in bigger companies with old workflows and old people that are used to working with prehistoric methodologies.Here are some tips that might help you make such changes in these more complicated settings:
- Sell your idea by demonstrating success stories from other companies, clearly stating why change is better.
- Start implementing something that makes the developers’ lives a bit easier.
- Make small changes (Minimum Valuable Product). Bigger changes involve many ruptures in the process and developers won’t like them.
- If they like your first MVP, you won’t have problems getting an opportunity to continue with those changes.
- Developers will depend on you, be nice to them. Always be helpful and understanding when it comes to their problems. You can even do polls to find out what’s annoying them the most or what it is they need.
- Automate everything. It ALWAYS pays off.
Transparency for Everyone
When someone in your company (techies, product managers, CTO, CFO... whoever) needs information are unable to get it, you have a big problem.If everything is automated, it should be easy to gather information and show it company-wide; the release state, the next code that will be released, what that code does, what bugfixes it will include, who the author is, its risks, how to test it, etc.
Create a dashboard that everyone can see (a good design will help), so you can make them aware of, for example, when a new feature is going to be released. This way, for example, the communications/press team can make an announcement or the marketing people can prepare campaigns in time. Otherwise, they will ask you personally and in most of the cases, this is a waste of either your or their time.
And Now What? Next Steps and Projects
We automate almost everything but there are tons of things left to do and tons of way to improve/optimize the current tasks and operations we’ve automated.Here is a list of some of the things we would still like to do:
- Open source flow: Many people have requested this from us, and we are willing to do so but at the moment there are some parts of the code that are far too much coupled with Tuenti-specific things. We would need to do some refactoring before open sourcing it.
- Speed up the pull request system: By testing more than one pull request at a time. For example, if there are two pull requests, A and B, the idea would be to test A and B together and also A only, if A+B is successful, Flow integrates two instead of one, if A+B fails and A is successful, Flow integrates one, if all of them fail, there is nothing to integrate, but it’s demonstrated that this case is the least frequent because in most of the cases the pull requests are successful.
- Code risk analysis: Analyze this risk in the pull requests system so we can cherry pick pieces of code according to their risk and better plan releases. For example, we could do low risk releases only on Fridays.
- Improve the development environment by virtualizing in different ways: Tuenti-in-a-box is not always enough to provide a full development environment because of resources consumption that is too high or because it’s not ready for other kinds of environments like Android or iOS developers. We have been thinking about improving the virtualization system, and instead of using VirtualBox, we would like to try some lightweight virtualization providers like LXC. It’s worth researching because we think there is room for great improvements here.