7

I personally made the unwise choice of cramming five different apps into a single database about 20 years ago. I then had to deal with the repercussions of that. The bad news is, this is really hard. The good news is, modern tools make it easiser, but not easy. So, first, absolutely get a single source of truth. You're using SQL Server, so there are a bunch ...


7

I would direct you to my post Coupling docker registry and source control where dmaze answered from the official forums.docker.com. Commit hash and branch name or tags suffices. In your Dockerfile, use a LABEL to record the source of the build. That probably includes the commit hash from distributed source control (git, Mercurial), the branch name if ...


3

IMO these could be possible synonyms for scripted, in the context of your question here: in a textual format, which you can edit in some editor, like YAML, XML, JSON, PHP, etc. NOT in a binary format, the result of some build process (like a .EXE file, etc). And I bet the reason for the "key prerequisite" (as in your quopted text), is that in the end you ...


3

It seems to me that your customers should be dictating the versioning. Both teams seem to be heading towards the same thing but only partially understanding the customer impact. For development, when they significantly re-architect components, there is risk because this could corrupt data or leave core features in a malfunctioning state - this should be ...


2

How to ensure that each tag has a unique semantic version number for the specific images? One could create a tag that consists of multiple elements, e.g. a combination of a timestamp, git commit hash and semantic version. The latter has to be set manually, while the first two could be automated. Such a tag could look as follows: 20171015141729-...


2

The two approaches whilst somewhat overlapping solve two different problems: Feature flags allow you to decouple the action of deployment from the action of release. i.e. you can push a change to an API that adds functionality to support a new feature, then when your product owner wants to release it all they need to do is toggle the feature on. API ...


2

Disclaimer: I'm not a RDBMS DBA and I have zero experience with MSSQL. Everything below is a hypothesis. Each app should have it's own stored procedures in migrations, and shared procedures should be in their own repo with a separate migration list. This adds a necessary isolation and the ability to use benefits of common ones with optional toggling on per-...


2

Version bumps should happen every single build. Waiting until a formal release and releasing everything as 1.0.0 is an option, but you should still know what build you are using in your alpha/beta. Ultimately, the developer will have to determine if a major release increment is needed. You should only do a major release bump if you introduced a breaking ...


2

First a couple key points: Tags are mutable in most registries, so v1 today may be different from v1 a month ago. However clients do need to pull this tag again to see the updates. Multiple tags may point to the same image. So stable and v1 could point to the same image. Pointing to a digest ensures the image is immutable, however you will not receive ...


1

I suggest to follow the principles that are defined in the Semantic Versioning 2.0.0 documentation.


1

While I generally do not recommend GitFlow these days, fully automated way to do what you ask is possible to achieve with an external system. Below I will describe how to do it with Reliza Hub (which is the one I'm developing - but you may find other options). Here is the idea - You create your project in Reliza Hub and choose versioning schema, i.e. semver....


1

Simplest answer is to just revert the commit. AWS Code Commit is standard Git and will support everything Git allows you to do. I.e. find commit hash: git log -n1 commit 444c954e458cc446e2a7a1f2659adf71bdf55580 (HEAD -> my-branch, origin/my-branch) Then do the revert: git revert 444c954e458cc446e2a7a1f2659adf71bdf55580 git push It'll revert your repo ...


1

This is not the default behavior of git so you have made some local config change to cause this to happen. Look in your ~/.gitconfig to see if there's anything that doesn't make sense to you. Try commenting it out. The core.pager setting is one of the first things I would check. This stackoverflow question has a variety of options for dealing with this ...


1

I know this question was asked a long time ago but I still want to answer it. How products are build, versioned and delivered depend highly on the combination of the used tools, the infrastructure and the processes that have been established in your company. This also means there is no general way to it. However there are of course best practices like ...


1

The best way is of course (like Zeitounator comments) to use a inventory var. Either you use the version number in the docker-compose task as a variable or you create a Jinja2 template docker-compose.yml.j2 and use the variable there. That's what I do. Example: all: hosts: host1.prod: image: "xyz/12" host2.dev: image: "xyz/latest" ...


1

I just needed to set publish = true I then enconter another issue for creating seprat versions but finding this answers my initial question


1

Your string isn't being interpolated at the correct time because it's in single quotes. Instead it's being passed to the checkout method as an un-interpolated string. By the time the checkout method interpolates the string, the perf variable is out of scope and so interpretation of this variable falls back to a blank string. Something like this is what ...


1

I've just done this and so far it's working well for us. Basically we use a Jenkinsfile and retrieve the version from the POM (which is using semantic versioning) and remove the snapshot. stage('Build Docker Container') { steps { script { pom = readMavenPom file: 'pom.xml' pom_version_snapshot = pom....


1

we now want to release faster And from your comment: Basically, since the artifacts depend on each other, we need to release them in the correct sequence. And since there's a lot of them, it takes some time. I think you're having an X/Y problem. Yes, versioning plays a role, but it seems like you would benefit from solving the source of your problem ...


1

In my opinion the software version should not be updated if the documentation changes, while the software itself does not change. I do not prefer to use different versioning for technical documentation and software as the docs are related to a certain software version. Different versioning will result in confusion. In conclusion, one could use the same ...


1

I suppose that you use one of the DevOps tools for CI/CD like Jenkins, I suggest the following approach, If you use something like Jenkins- You can configure your job such a way that you can use Jenkins environment variable "BUILD_ID", which retrieves the build id of the job when triggered to tag it to your image. This way you can version control your ...


Only top voted, non community-wiki answers of a minimum length are eligible