18 December, 2018
We have been frequently asked by companies that are planning or are developing a software product about the common issues found trying to achieve a good production workflow, good teamwork and the security of properly handling the code base.
During our years of expertise we developed a strong vision about the most important tools that you need to use if you want to build software in a controlled way.
These tools encourage the implementation of a Software Configuration Management (SCM) strategy within your organization. In turn, this will have a great positive impact in many aspects, some of them technical, but also in many functional and workflow oriented ones.
Today most of software engineers take these tools for granted. But there are cases where companies with small development teams or organizational debts need some help figuring out these stuff. In that spirit we are writing an overview of this topic.
Most of the important problems that could come up are solved by properly installing, configuring and using this tools.
One key fact is that these tools are important regardless of the language or platform that you’re using.
First step: Secure your code
You have invested a lot of resources in building your product and you have a few customers using it. The source code is the most important part of that product, so the first issue you have to consider is how to store your code in a secure manner while helping improve the way your team work together without conflicts.
The solution to this is using a Version Control Software. In the beginning there were many different options to choose from, but these days almost everyone is using Git. It’s one of the most advanced tools for handling code for large teams and it’s easy to find candidates with experience using it.
Second step: What about the packages?
It’s almost impossible to find an organization that builds software without a VCS, but the same cannot be said about handling the binaries or artifacts that you create to distribute your software. Most engineers don’t even know there are tools that can be used for this. And why should they consider using such a tool?
In order to answer this, first we need to think about what are the steps involved in writing software:
- We begin by writing the code. You can use a minimal tool for doing this, like a simple notepad application, or you could use a heavy IDE with modern code generation techniques, but you almost always end up in tons of text files.
- Then, depending on your platform you might need to compile the code into a binary or intermediate format. That is a process that takes a source code as an input, and produces binary files as the output. This step might not be required if you’re using an interpreted language as Javascript or PHP. But even in those cases, there are usually a transpilation process that creates new forms of code optimized to run in different browsers, and environments.
- Next you test the application in your local environment.
- If everything is ok, and you’re ready for the production deployment phase. This involves taking the artifact that you tested locally or in a test environment and placing it in the server that is going to expose your application.
To be completely sure that there are no problems with the generated artifact, the best is to always perform the build in a clean environment (we’ll explain this later), and in order to avoid repeating this process unnecessarily, the best is to store it in a safe place. This is when the binary repository shows its strength. This tool will store the artifacts in an organized and reliable way so you can download them when you need to deploy, but also when you need to build another software based on a library, for example.
Final step: Continuous Integration
Having the source code and the produced artifacts in place is only the beginning. Automating the construction of the applications and libraries will give you many advantages:
- Having a clean and centralized place where the software is going to be built. Usually in many companies, the senior developer or the technical leader is the one that builds the artifacts that are going to production. But what if he or she forgets some work in progress or experiment, and then some unwanted behavior is accidentally introduced in the production ready artifact?
- The building pipeline can be triggered upon changes on the code. This can help in finding possible issues earlier, thus reducing time spent following up on them when found in production, and of course it finally produces better quality deliverables.
- The building recipes can be standardized, so no wheels are going to be reinvented in that matter.
- You can control who triggers builds and deployments, and have logs about those actions. That at the end means better control of the changes that have some impact in important environments, such as staging, testing, etc.
There are many alternatives for this kind of software, but one of the most well known is Jenkins CI. This open source project stands out due to its very large and active community, a vast list of plugins and extensions, addressing almost all of the problems that can arise when configuring this important part of the SCM strategy.
Bonus track: Versioning scheme
But that is not all, you also need to define how to version your software and libraries, how to handle the release of your artifacts, how to manage dependencies, etc.
For that there are many tools, depending on the platform. For Java developers, Maven is almost a de facto standard, but you can also count with Gradle and Ivy. For .NET platform, you have NuGet, and for Javascript world, you have NPM, Bower and Yarn. All of them can be configured to be used with the binaries repositories, and the CI servers available.
Given the difficulty that can emerge when defining this process in your company, the best is to have the advice of experts.
We have years of experience in this subject, and helped many customers in defining and implementing their SCM strategy, so feel free to contact us and get more information.
See you all in the next post.
Join the conversation!