When I was asked to write this article, the idea was to write about what should be done in DevOps vs. what shouldn’t be done, but call me an optimist, and the simple fact that using DevOps in a project already seems positive in itself, we are going to review less good practices vs. their optimal form instead, so let’s get started.

Don’t always apply the same formula to every project: I so often see how the same methods are applied among clients and projects, but what some people may not know is actually how little they have to do with each other. In DevOps, what runs like clockwork for one project, may not for another, and an analysis of the projects needs is always necessary. For example, how many programmers will be working at the same time, how many environments are suitable for the specific project, if it has a quality assurance team, the frequency of the production deployments, if you’re going to work in Cloud or on premise environments…these are only some of the many factors to consider and that do not allow us to reuse the same methods among projects.

Automise what you can: In DevOps, always automate where you can, in order to reduce release times and avoid human error. So, where possible, manual deployments of environments should be avoided, as well as updating data bases manually. Basically, everything ‘manual’ should be avoided.

Your work doesn’t stop at the deployment: Let me explain, you can get there, analyse the needs of your client, implement what you believe is a suitable methodology that adapts to that project, everyone is happy…but…we can always improve the flow so that deliveries are more constant and of better quality, so like DevOps, you don’t only have to introduce a good methodology for the project, if not, you continue polishing it bit by bit, either analyzing logs, metrics, feedback from developers or people from the system, until reaching a certain point where it becomes very difficult to further improve the project.

Use package management: In my case, I use VSTS, referring to Nuget and the VSTS feed, but there are many other available tools. You always have to avoid uploading dlls in projects, so an ideal system would be the use of nuget packages, and knowing how to create the necessary builds for them to be generated automatically (remember my previous point; avoid anything “manual”). At this point, the best practice would be the use of feeds, in order to control security, distribution and the automation of our packages. A less good practice would be the use of a site that provides those packages, but means we would lose some of the advantages mentioned above.

Protect your branches: It’s time consuming when you syncronise the branch, and if it turns out that it doesn’t comply you have to look for the person who didn’t put the “;” so they can fix it and upload it…uff, so much work. A good practice is having as many branches as environments (although this is debatable and depends on preferences). However, what shouldn’t be negotiable is whether or not you should apply a continuous integration policy in your branch, and launch various builds, in order to check that the code complies and that all the tests are correctly passed (I’ll talk about this later). This ensures that the quality of the code that you upload to the main branch is the minimum acceptable. This also depends on your preferences, but as good practices in branch policies go, this is where checkin descriptions come in, that need validations of the person responsible (if you work with quite junior teams) or that the checkin is assigned with a task.

Correctly use builds and releases: it will not be the first time that I see a build responsible for compiling code, passing some tests, assembling the artifact and the deployment in the server/turn site. Since we have the tools, we are going to use them well, the builds are for continuous integration and the releases for deployments into environments. This allows us to be able to organise everything correctly, and return to previous states with very little effort.

The tests are fundamental: yes, like DevOps, you don’t need to know how to program, nobody is asking you to do the tests. However, if it’s your job you should demand that the tests be done, because there’s little point including validations in your builds, in order to pass the tests, when it turns out that the project doesn’t even have tests. The best practice is for the tests to accompany the development, to be able to trap errors in the early stages and not the users in production, so put special effort in making developers understand the importance of tests from the beginning.

Talk, talk, then talk some more: as we mentioned in the first point, not all projects are the same, and you as DevOps have to be in the middle of everything. The developers, who complain that they lose a lot of time because they have to validate the code (which nobody likes doing). Systems and infrastructure, who want everything to be secure and they don’t like you being there in the middle. The client, who wants to see their project one month into production and someone else who usually appears, your job is to speak with all parties, to try to make life easier at times or to make them understand that everything being done is being done for the good of the project. So, how do you achieve this? Yes folks, speaking with all the parties involved is what you have to do.

I could go on and on, and like I mentioned at the beginning, each project is a different world and things considered important in some projects won’t be important in others, but a priori, I believe that we have covered the most important points (I’m sure i’ve missed something). I will leave you with my first reflection, only for the mere fact of including DevOps in your project; it’s beneficial, and the only thing you will have to gradually do is improve the flow, in order to improve quality, speed of delivery and reductions in production maintenance. I can say that for sure 😉


Written by: Alberto Picazo