The Configuration as Code plugin is an opinionated way to configure Jenkins based on human-readable declarative configuration files. Writing such a file should be feasible without being a Jenkins expert, just translating into code a configuration process one is used to executing in the web UI.

When asked what stops them from safely and regularly deploying every change into production environments - everybody seems to have their own reasons. Organizational, cultural, historical, technical, contractual.. Some go as far into denial as saying : "Oh, we don't need continuous delivery. In fact most companies out there don't really need it." But the underlying reason is of course the lack of confidence. Nobody wants to be the culprit for a system outage. According to a number of industry surveys the average cost of one hour of downtime is around 75000 USD. There's a lot at stake! So instead we choose to move slower, to add controlled handoffs and build home-grown guardrails. To hire more Ops engineers and call them SRE to feel more secure. Rarely discussing the price of establishing and maintaining all of these over time.

...

Engineers who've experienced true CD can't really fathom any other way of delivering software. As @giltayar puts it "CD ... is a total game changer. It changes how you perceive software development and delivering features... I did CD and EVERYTHING about how I developed changed. It was magical."

Jenkins has several "hidden" features that can be enabled with system properties. This page documents many of them and explain how to configure them on your instance.

Palisade works by reading two files in the root of your repository:

• A CHANGELOG.md file that describes the changes made to the program
• A VERSION file that contains the current version of the program (ideally following semantic versioning)

Every time Palisade is run, it will check the git repository for version tags based on the contents of the VERSION file. If it finds that the current version has already been tagged, Palisade will do nothing and exit with the exit code 0. If Palisade finds that there is a new release, the software will then read the changelog file, scrape it for release notes, then use those release notes when creating a new release on GitHub.

You need two things to effectively move fast: a culture of psychological safety and smart investments in tooling. Employees need to feel empowered to speak up if things are moving too fast—if they are concerned about why a feature is being built and to identify gaps in the processes. They need to feel they won’t be blamed when something breaks. Building this requires empathy, open communication, and teamwork. This psychological safety is the foundation of being able to move quickly and quickly recover when things break.

Next up is selecting the right tooling and processes. Invest in tools that make things easier. Tools should be useful, usable, and change the underlying problems, not create more.

I’ve used the term *Feature Factory* at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

Most web apps need login information of some kind, and it is a bad idea to put them in your source code where it gets saved to a git repository that everyone can see. Usually these are handled by environment variables, but Docker has come up with what they call Docker secrets. The idea is deceptively simple in retrospect. While you figure it out it is arcane and difficult to parse what is going on.

When you are solving a difficult problem re-ask the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.

Vanna is an internal feature flagging service used at PBS. It helps deliver new features to users quickly and safely. This is an example client implementation for browser based Javascript.

More info in this article at Dev.to.

It’s a situation many of us are familiar with: a large legacy, monolithic application, limited or no tests, slow & manual release process, low velocity, no confidence… A lot of refactoring is required but management keeps pushing for new features. Now what? We talked to Michiel Rook, a Java/PHP/Scala contractor and consultant about the challenges that walk hand in hand with continuous deployment.