Building up : Automate

Many battles are to be fought in projects so it's key to choose your battles and avoid as many as you can. Styleguides and guidelines are, as we saw previously, key to ease the day to day work by avoiding extra work.

The next step, or a parallel one, is to automate things that can be. There are many ways to handle this : many will turn to Jenkins, others to Github and Gitlab actions and tasks, and others will turn to other, dedicated CI services.

Running tests

The first part is usually to get tests run in a regular manner, but best is to do so at every push and merge to the code repository.

This is key to give quick feedback to the team about how code change affect the code base. As pointed out in the introduction there are many ways to do this, each team will decide the best solution for them. There is really something for every taste : proprietary and commercial, open source and hosted, open source and self hosted, even proprietary and self hosted.

Most git hosting solutions (again, a mix of the above) will have a way to connect or get connected with the CI solution picked. That's how the team can know quickly how things are going. Then you can also tie the CI solution to your chosen team chat. Again, it's about keeping the team up to date with how the tests are running.

Packing, delivering

If tests run fine, then there is probably a good opportunity to prepare whatever archive, blob or container is used to deploy the one or the many services built by the code base.

Again, the CI is a good way to do that. If tests are usually a typical example of the use of a CI service, preparing releases is one that should become one. Preparing releases by hand or a lone script on a specific machine is a recipe for disaster : scripts get lost, laptops get damaged, team members go on holiday, and even fall sick. In all those previous cases you can be basically left with a lot of difficulties to deploy a release at a critical time, or during weeks.
Using a CI service and automating steps for preparing releases is key to improve reproducibility of those steps. And since CI services, especially the self hosted kind, have plenty of compute and memory capacity it's generally faster than developer laptops or workstations.

Once a release is built, the next step is to get it running on production or other environments. Again, it's all about getting things out of specific laptops and scripts into services that are either scaled automatically or can be brought back online quickly. Those steps can be gathered into one place (the CI service) or tied to multiple (chat rooms, git hosting, ...).

Bells and whistles

And this brings us to the next step, which is often considered to be a "nice to have" but does make big differences when all those little steps are brought together.

This can be many things actually : from the sending messages to the chat rooms, to triggering deploys automatically, starting CI worker instances in the morning and shutting them down in the evening, handling DB backups, restarting testing and QA environments regularly, ... The list can go on.

What all those have in common is, again, to simplify the life of the team by replacing all kind of manual tasks, not only with scripts, but with scripts triggered and run by events or schedules.

If team members spend time scattered across the board to take care of many things then that's as many context changes that are required. Context changes are counter productive and will cause trouble one way or another. Simplifying things for the team is the role of automation. There are many ways to do it, again, it's mostly a matter of starting, experimenting, finding what works for the team and moving on from there.

Just like the previous steps it's a culture that will need to evolve through the different events the team will live. Retrospectives will give the team the opportunity to reflect on how things are going, what is the next part that needs to be automated, and what automation needs improvements.

Epilogue

You should start to see a pattern in these articles : from my point of view all these are parts of the technical culture of the team and project. Those articles are meant to give little pushes to teams that are struggling or wondering where to go from where they are : easing your day to day pains is not so difficult, most of the time, the biggest issue is to get started somewhere.

Automation is a big help to get things moving faster, to get quick feedback on how things are going (tests), to get things prepared (releases, environments setup) and to get things running (deployments). That's as many things developers should not have to actually worry about.

Fancy talking more on this topic ? Contact me to discuss how I can help your team establish or refresh a CI/CD pipeline.

Need help ?

We specialise in helping small and medium teams transform the way they build, manage and maintain their Internet based services.

With more than 10 years of experience in running Ruby based web and network applications, and 6 years running products servicing from 2000 to 100000 users daily we bring skills and insights to your teams.

Wether you have a small team looking for insights to quickly get into the right gear to support a massive usage growth, or a medium sized one trying to tackle growth pains between software engineers and infrastructure : we can help.

We are based in France, EU and especially happy to respond to customers from Denmark, Estonia, Finland, France, Italy, Netherlands, Norway, Spain, and Sweden.

We can provide training, general consulting on infrastructure and design, and software engineering remotely or in house depending on location and length of contract.

Contact us to talk about what we can do : sales@imfiny.com.