Beyond the Blueprint: The Quest for the Ultimate Project

The Miracle Maker (Makers) team joins another kick-off meeting, one more meeting, like tons they went before in the last years. They hear the same old story, “It is an important project,” “We learned from previous mistakes,” “We are going to apply good practices, follow the standards, and write unit tests,” “We will do proper CI/CD, and we will have UAT environment.” “This time, it is for real.”

The Makers team looks at each other, and we can see what is going on in their minds as if we were watching a 3D movie. They are betting on how long it will take for the plan to blow up.

Why? There is never time to do this right, even though it is cheaper, reduces error, and is faster in the long run.

Creative ways in how projects were stored?

Usually, there is a source code repository with versioning (VCS) … or not.

The source code could be on the remote machine, where developers do remote desktop and their development. The source code is safe until the device says goodbye.

Another way is to self-host a VCS server. Back in the day, more than enough organisations deployed SVN, CVS, Mercurial, Visual Source Safe, or others because they were “free,” “open source,” or “just because.” The years 2000 were a mess.

A more rudimentary way was exchanging zip files or using the “Dropbox” service to store and share files. Very creative. 🤣

But having a source control is better than a remote machine, no doubt about it, even with the challenges.

With the turn of the year 2010s, Git and TFS became kings. But companies stuck with their VCS just changed today. It is okay as long the source code is safe. Remember that they moved from one (or more) machine(s) with the code accessible with a remote desktop to having the VCS in devices within the infrastructure. Their complexity is increasing.

With the turn of the year, the 2020s, primarily due to the pandemic, organisations are moving to CVS providers in the Cloud, and they gather almost immediately redux the CAPEX and the OPEX. Azure DevOps and GihHub are the lords, but there are a few runners-up (in my opinion, not-so-good).

So our code is safe. Great. Now what?

Creative ways of deploying the code artefacts

The following strategies and procedures are still being used today. Believe it or not, and that is scary.

My most amusing is to update the code directly on the server. Someone needs to do something: go to the production server and do the problematic update. Done! The change is not on source control, but the business stakeholder is happy.

Another (very) standard procedure is to the changes and the software development in your local machine. Do all the tests locally, and it works.

Next step? Deploy from the local machine straight to the production machine. Done. At least the code is in source control, and the business stakeholders are happy again.

Fortunately, many organisations walk this path and conclude that this can be done like this.

At the end of the 2010s, DevOps culture was born. They become the ultimate promise of delivery in heaven. Although the principle from which the culture was born, soon enough, the business stakeholders devirtuate the meaning and the value.

Now, the developers write the code, the code is pushed into the server, and then some scripts are executed to build, test, and analyse the code. Eventually, some hands will be performed to be deployed on the server.

Now, the Developers and DevOps teams have reached a bumper: The deployment to the Production environment is done at night, usually on Thursday or Friday.

Integration and Deployment automation

I’m a sucker for automation. I hate doing repetitive tasks and needing to have the standard of the projects. I dislike all creative developers and DevOps operators who decide to do stuff in their way, reinventing the wheel seven times a day, every day of the year. They are just wasting the Team’s time and the company’s money.

Not following the standards, not following the same procedures, and not applying the same protocols make automation harder without need. There are better ways.

Creating multiple scripts for each project, technology, and Team wastes time. Anyone developing software solutions can ensure that you may have five or six different types of projects to build, so why do we need hundreds of other scripts for each project? It could be more efficient.

2023 Out-Box-Box Solutions

Makers Team already knows the project will go south. The “promises” within the meeting are as empty as the air in space. The stakeholders will keep pressing to deliver fast rather than well to have something to show off for an annual bonus, even though the application is a paper sheet going to the trash.

The Makers team knows what has to be done, how to do it right, what should be introduced, and what should be deprecated or removed, so they do genuinely agile development.

If the project and the Team follow the standard procedures and structures and apply them to a genuine Agile Development Platform, they can reach the following benefits:

• All projects follow the same format.
• All projects follow the same convention rules.
• All projects have the same pipeline before the pull request is ready for analysis.
• All projects have unit testing.
• All projects have static code analysis.
• All projects have security analysis,
• All projects have dependency vulnerabilities analysis.
• All projects have an integration pipeline.
• All projects have a deployment pipeline.
• All projects can deploy the exact version of the artefact to all environments.
• All projects can deploy into production during business hours without losing service.
• And many other benefits.
• All these solutions work regardless of whether you are on-permisses or in the Cloud.

The first step makes the path. A full deployment for a medium application (around 20k lines of code) can take up to 10 minutes from the PR being accepted until it is available in the production environment without losing service.

Conclusion

Technology does age and becomes deprecated. Either you stay and vanish or evolve, innovate, and invest. In some cases, it is hard to apply the change; at that point, it is recommended to partner up with an organisation that makes your pain theirs, and their success becomes yours.

After all, Miracle Makers love to sleep at night.