I wanted to explain, why enterprise software development comes with a lot of overhead and why it still makes sense.
We recently needed to set-up a new micro-service that will be the basis for new features in the future. You could argue, that you would only need a git repository and there you are, but that's not quite it. In fact, there is a lot more to it that I am going to explain in this article.
So let's start:
OK, that's the most basic part, we set up an empty git repository that will contain the new service.
Then, we create an empty application stub. For spring boot, we'll use start-dot-spring-dot-io, cheers to Josh Long.
Now we need build jobs on a continuous integration server like Jenkins, not just one of them. We need a continuous (C) job that builds the server after a code change (push trigger), we need a nightly (N) build that will regularly build the code even without code changes and that does some extra work as well as a couple of extra scan jobs, we'll come to that later.
Static Code Checks
During both C and N builds, we'll perform a static code analysis (e.g. SonarQube). Enabling a quality gate here will fail the build if code coverage is to less or there are too many issues (code smells, bugs, complexity etc).
Based on my experience, both coverage and found issues should not be treated too seriously (like "We need 100% coverage"). However low coverage (< 60%) and a high number of issues is usually is a good indicator for code that is less maintainable and has a high risk of producing bugs in production.
Open Source Library License Check
This part is crucial and legally obliged. Otherwise, companies could get sued.
Source Code License Check
Another legally-induced scan will check if the written source code contains parts or whole files that have been copied from open source projects without referencing to the project and it's license. This BTW also applies to StackOverflow. It's license is CC BY-SA which requires proper attribution.
Violations will also fail the build.
Security Vulnerability Check
This is the next step in the build pipeline. The used libraries will be checked automatically against the vulnerability database. Any CVEs will show up in the build result. Depending on the severity, it may also fail the build. This part is obviously very important but also very tedious. This scan could break a build at any given time without any code changes just because a new vulnerability has been found. This happens very often every one or two weeks. The scan will usually show what part is actually affected, if there is a new version without the issue or how to work-around the vulnerability.
The final deployment artifact is virus scanned and the report attached to the binary artifact.
For every backend service, we also build and deploy a docker image. This is used for testing as well as deployment.
Software quality is also very important. See my article Everything That's Not Tested Will Break if you're interested in details.
- Unit Tests
- Integration Tests
- System/Use Case Tests
- UI End2End Tests
- Performance Tests
Even for an empty service, we will create a dummy endpoint that will be tested in system and performance tests.
Different Deployment Scenarios / Databases
Since we are not the one-product-start-up, we need to support a couple of different deployment targets that range from zip-based on-premise over docker based deployment up to multi-cloud deployment.
That will be mixed with multiple databases that we support. and results in a wide range of Docker and non-Docker-based test environments.
Depending on the features planned for a service, we will also need to apply for a new license module that will allow customers to use the new features.
Each service will get one ore more new permissions that allow users or other services to communicate. Those will be created at service start-up automatically. So even for a stub service, we will set this up.
Phew, all of this needs to be done before writing the first feature!
I want to show people interested in how this might look like in larger companies.
Moreover, I'm curious how you actually handle the above topics. I could imagine, that in a couple of smaller companies this might just be filed under "We don't need that". Others might solve it in different ways. We are always looking to automate individual tasks as well as the whole process but it's not that easy since all steps involve a lot of different system.
So, please comment if you have questions or suggestions!
I am very confident, that when writing software that will be delivered to customers and run on the Internet, most - if not all - of the above is actually required to create software products of high quality without a high legal and security risk.
Photo by langshoots on Unsplash.
Top comments (19)
Empty Application, Build Jobs, Static Code Checks, Security Vulnerability Check don't take more than a couple of minutes. Setting these things up are basically automated.
Open Source Library License Check. Not needed. There is a pre-defined set of libs available for us to use. If we need something else, we should open a ticket.
Of course, we could still copy-paste whole OS libs... But that's another check you mentioned.
Could you go into more detail about how you automate the creation of all of that?
We have a code generator to create an empty application.
We use Jenkins to automate our build pipeline as much as possible. We have pre-defined Groovy verbs to run the build, to run the tests, to run different kind of checks (static code analyzer, vulnerability checks), to create and publish tarballs.
Most of the times, you can just use the default template in the beginning, you remove some of the possibilities, or add some other pre-defined stuff based on the docs. Of course, you might need more specialized features, but usually not before you start creating an application.
There are many people working on maintaining and improving our pipeline framework, there is a lot of work behind, but these aspects of setting up a new application are easy.
Setting up the networks, getting (virtual) machine resources, or creating a new database is more time-consuming.
Thanks for the insights. We actually don’t have anyone dedicated to help on automation. Each team does it on its own and no one has the time to really generalize it. But I think we should really start doing it!
Be careful when you do so. Genericizing is great, one-size-fits all is dangerous. Id rather see teams write ops code that needs to exist rather than build be forced to design their application around a broken ops model.
I'd say your company is in the upper 5% of "Enterprise" if thats your process. It also sounds like software is your product. Most large companies will just delegate those decisions to a vendor, and are so beholden to antique process that CI and unit testing are regarded as unnecessary expense.
Actually we’re a small part of a huge company. Our business unit however really only does software. So I can’t speak of others that much. I assumed that most large software focused companies need to do all the tasks because of the legal an financial risks. Do you have actual insight regarding the 5%?
I'll clarify, it's the top 5% of companies I'm referring to in terms of technical maturity
and fast followers. Most large enterprises don't develop software as a product, they develop or buy it to support their main line of business. They by and large also fail to understand that in 2019, every company is a technology company.
My actual insight comes from a few decades of doing development and architecture for those types of companies over numerous verticals. I've seen very few that actually accomplished a CI/CD pipelines and have worked with two recently that have objectively failed at their "devops" transformations outright due to politics and human cost.
Should they be doing it? Absolutely. They don't do it, however, because their decision makers regard development as a pure cost center. Their project management triangles point due south at cheap. Anything that isn't "delivering something the customer can see" is regarded as waste.
In that regard, any company doing the things you've outlined consistently or at all is in a respectable minority. I definitely agree it is all valuable.
Thanks for the clarification!
You may be assuming than Jan was referring to developing software as an enterprise company (though reading his reply it looks like you are correct).
All of this also applies to developing software for enterprise customers, regardless of your company's size.
Software Development Process and SDLC Process
Identification of Required Software
An organization should identify their specific requirements. They should have a clear picture, that for which requirement they are opting for the software. Team members should discuss them and then identify the business issues.
Analysis of the software requirements
After, identifying the requirements, conduct a proper analysis. Don’t decide in hassle, the foremost step is to figure out the challenges but now, sort out the ways to overcome them. Thinking logically, will surely help build the software that will solve those issues.
Practically, have a theoretical knowledge about software and have a logic by applying virtually in your mind that how it is going to sort your major issues. The decision’s at a fast pace can lead to you to high investment, after knowing about the software, try to figure out the features that are required for your business. As customized software decreased the cost of software development and offer features that are required for the business.
Detailed Specification of the software requirements
After analyzing your requirements, it’s time to specify your needs in detail. The detailed specification helps to bring clarity among organizations and also with hired software development companies. Sometimes, verbal communication can lead to high miscommunication but detailed knowledge on paper leads the development process to an accurate and reliable method.
So, don’t depend on the virtual imagination plan it in a Professional and specified way.
Software is more than design and it should support the high functionality. Designing also plays an imperative part but the layout should be easy to use. The elements should not be so complex, as the software should be designed in such a way that every member of the organization and department can use it.
It should not be so complex with the technical issues as well as with the combination of color and fonts. To integrate the proper software design, designing architects work on it to design it perfectly. The design process is also further divided into three major parts:
*Interface Design *
Programming and Coders
Programmers are also known as coders and they are only responsible for the functionality of the software. They generate source code to run a different specific program with one other like merging databases, routing communications, and work on the reflect of text and graphics in a proper way on the screen.
Basically, software developers use popular programming languages like Java and C++.
Before launching the software to the enterprise it’s the developer’s responsibility to check the software functionality manually. Software development is a long process and involves various steps designing, coding, merging data and these all activities are related to each other. So, before launching the software to the companies test it manually as well as on public devices.
Hi, and thanks for writing that. Could you explain what the intention is? I mean, are those points how you handle SW development at your company or how you think it should be generally or point you think I’ve missed? Thanks
One small area where I differ on process is related to how you setup your CI. We typically disallow developers from doing direct pushes to our git repos, but instead we push changes into review. We use gerrit for this, but you could also do this with a github pull request.
We then use our Jenkins job(s) to build/test the code. Only after it passes some level of automated testing AND leads approve through code review do we have our jenkins job push the code into the repo. This way we ensure that the tip of the git repo is not broken.
This depends on the product, service and BE/FE. Our team always does very deep reviews, it’s part of our Jira workflow. However, we don’t do prevent developers from pushing stuff. This actually never led to any problems. If it’s red, then one need to fix it. We have strong team ownership. I probably would use the process you described if we don’t have any staging and deploy right into prod.
We also mostly commit directly on develop because using feature branches just results in too much merging effort.
What product do you use for Security Vulnerability Check? Snyk.io is nice but comes with a price tag. We introduced the service from owasp but it's not as shiny.
We develop in-house software. I count this as a plus because it simplifies things a lot.
Hi, we use Sonatype iQServer (formerly CLM Server).
And yes come with a price tag because they know that when companies get sued or lose customer faith it will cost them much more 😕
it's hard to find a good developer and get the best solution
Some comments may only be visible to logged-in visitors. Sign in to view all comments.