It is an honor to have you as a recipient of the very first newsletter from JahnTech, where we help individuals and organizations with webMethods projects.

Mission

The mission of this newsletter is to deliver relevant content (almost) every week. This often means posts on LinkedIn that might otherwise be buried in your feed.

In addition we will add other technical or business content, that does not really fit LinkedIn, but might be interesting for you. Examples would be

• technical tips for running your own small business on a budget,
• moving from Windows to Linux for the desktop,
• interesting open source projects

Your input

This newsletter is for your. So if you miss something, think something is not helpful, or have any other suggestion, please provide feedback. You can do that via email or the contact form on our web site.

And now to the content ...

While you can start simple with just one package, this soon becomes a problem. Here is real-world advice how to structure your code base. This reduces complexity, makes your solution much easier to maintain, and reduces the risk of bugs. And as a special bonus, you end up with a real integration platform.

This is a newsletter-exclusive blog post. Regular followers of the blog will have access later.

Click this link to start reading.

Here is how I do CI/CD for webMethods Integration Server. This approach has been battle-tested over the last 15 years and works for all scenarios I have seen so far.

• All developers have their own environment and commit their changes into the VCS, usually multiple times per day.  
• The CI server (e.g. Jenkins) picks up those changes, builds the package, and runs the unit tests.
• On success, a package ZIP file is created and uploaded to the binary repository (e.g. Nexus, Artifactory). You can also take GitHub here, but be aware that it is used in a fundamentally different role, compared to its usual VCS functionality.
• On further test environments the package ZIP file is installed from the binary repository and tests are executed. These environments do not interact with the VCS, that is solely the job of the CI server.
• Once all tests have been passed, the package ZIP file gets promoted from snapshot to official version (often called "release"). That can happen automatically for Continuous Deployment. Or you do it manually for additional control over the time of the update.
• Once release status has been reached, you use the exact same package ZIP file to create a new container image, update your running VMs, or deliver a new version to your customers. All this usually with automation.

The approach has the following advantages for me:

• Conceptually simple with clear steps and responsibilities.
• Tool-agnostic and flexible.
• Compatible with standard approaches from e.g. the Java world.

This was also posted on LinkedIn. Feel free to engage in the discussion there.

In-depth blog post

If you want to dive deeper into this topic, there is also a new blog post available on our website.

Dave Plummer hosts one of my favorite YouTube channels. Here is this week's pick.

A few curated links that might be useful for you:

• IBM community forum for webMethods
• David Heinemeier Hansson (creator of Ruby on Rails) on effort estimation for software development
• Gregor Hohpe: The Economics of Writing Technical Books