release procedure

[Oleg Ostanin-2]

Hi,

I'd like to start a discussion about Apache Ignite release procedure.

I'm working on ticket Ignite-5249 "The release build procedure should be
placed on the CI/CD server and available to run for the release engineer."

https://issues.apache.org/jira/browse/IGNITE-5249

Currently we have three options for release:

1. Release engineer can do all the necessary steps on his local machine. It
will require installing tons of soft like maven, doxigen, candle and so on.
Also building .net part of the project will require access to Windows OS.
Build steps will not be transparent for community. Environment will not be
the same for each release which can lead to the compatibility issues.

2. All the steps (including signing) can be done on the public continuous
integration server. Environment will be the same for each release, all the
steps will be transparent for community, but it will require uploading at
least one private gpg certificate on the server. This is the high security
risk and I'm mentioning this option only for the sake of completeness.

3. Building of the project can be performed on the public continuous
integration server and then artifacts can be downloaded on the local
machine and signed and deployed to the staging repository from that local
machine by running maven commands. No sharing of any credentials and
certificates will be needed, environment will be the same for each release,
all the steps will be transparent for community, artifacts created on the
CI server can be verified by check-sums after uploading to the repository.

Please, let me know if you have any suggestion or any questions about
anything related.

[Anton Vinogradov]

Vote for #3

On Sun, Aug 6, 2017 at 3:37 PM, Oleg Ostanin <[hidden email]> wrote:

> Hi,
>
> I'd like to start a discussion about Apache Ignite release procedure.
>
> I'm working on ticket Ignite-5249 "The release build procedure should be
> placed on the CI/CD server and available to run for the release engineer."
>
> https://issues.apache.org/jira/browse/IGNITE-5249
>
> Currently we have three options for release:
>
> 1. Release engineer can do all the necessary steps on his local machine. It
> will require installing tons of soft like maven, doxigen, candle and so on.
> Also building .net part of the project will require access to Windows OS.
> Build steps will not be transparent for community. Environment will not be
> the same for each release which can lead to the compatibility issues.
>
> 2. All the steps (including signing) can be done on the public continuous
> integration server. Environment will be the same for each release, all the
> steps will be transparent for community, but it will require uploading at
> least one private gpg certificate on the server. This is the high security
> risk and I'm mentioning this option only for the sake of completeness.
>
> 3. Building of the project can be performed on the public continuous
> integration server and then artifacts can be downloaded on the local
> machine and signed and deployed to the staging repository from that local
> machine by running maven commands. No sharing of any credentials and
> certificates will be needed, environment will be the same for each release,
> all the steps will be transparent for community, artifacts created on the
> CI server can be verified by check-sums after uploading to the repository.
>
> Please, let me know if you have any suggestion or any questions about
> anything related.
>

[Konstantin Boudnik-2]

There's also #4:
 - providing an official environment, comprised of the toolchain,
compilers, libs, etc,. The same environment (read "a container") could
be used by an individual developer, RM, and/or in CI system for
builds, tests, etc. And then you can have #3 pretty much for free!

We are doing this in Bigtop for a much more complex environment, set
of components and supported OS. I am sure it would be easy to do in
Ignite.
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <[hidden email]> wrote:

> Hi,
>
> I'd like to start a discussion about Apache Ignite release procedure.
>
> I'm working on ticket Ignite-5249 "The release build procedure should be
> placed on the CI/CD server and available to run for the release engineer."
>
> https://issues.apache.org/jira/browse/IGNITE-5249
>
> Currently we have three options for release:
>
> 1. Release engineer can do all the necessary steps on his local machine. It
> will require installing tons of soft like maven, doxigen, candle and so on.
> Also building .net part of the project will require access to Windows OS.
> Build steps will not be transparent for community. Environment will not be
> the same for each release which can lead to the compatibility issues.
>
> 2. All the steps (including signing) can be done on the public continuous
> integration server. Environment will be the same for each release, all the
> steps will be transparent for community, but it will require uploading at
> least one private gpg certificate on the server. This is the high security
> risk and I'm mentioning this option only for the sake of completeness.
>
> 3. Building of the project can be performed on the public continuous
> integration server and then artifacts can be downloaded on the local
> machine and signed and deployed to the staging repository from that local
> machine by running maven commands. No sharing of any credentials and
> certificates will be needed, environment will be the same for each release,
> all the steps will be transparent for community, artifacts created on the
> CI server can be verified by check-sums after uploading to the repository.
>
> Please, let me know if you have any suggestion or any questions about
> anything related.

[Oleg Ostanin-2]

Hello Igniters, I'd like to know which release option is preferred for the
community. I've done some research and some tests and I think the most
transparent way is option #3.

On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <[hidden email]> wrote:

> There's also #4:
>  - providing an official environment, comprised of the toolchain,
> compilers, libs, etc,. The same environment (read "a container") could
> be used by an individual developer, RM, and/or in CI system for
> builds, tests, etc. And then you can have #3 pretty much for free!
>
> We are doing this in Bigtop for a much more complex environment, set
> of components and supported OS. I am sure it would be easy to do in
> Ignite.
> --
>   With regards,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <[hidden email]>
> wrote:
> > Hi,
> >
> > I'd like to start a discussion about Apache Ignite release procedure.
> >
> > I'm working on ticket Ignite-5249 "The release build procedure should be
> > placed on the CI/CD server and available to run for the release
> engineer."
> >
> > https://issues.apache.org/jira/browse/IGNITE-5249
> >
> > Currently we have three options for release:
> >
> > 1. Release engineer can do all the necessary steps on his local machine.
> It
> > will require installing tons of soft like maven, doxigen, candle and so
> on.
> > Also building .net part of the project will require access to Windows OS.
> > Build steps will not be transparent for community. Environment will not
> be
> > the same for each release which can lead to the compatibility issues.
> >
> > 2. All the steps (including signing) can be done on the public continuous
> > integration server. Environment will be the same for each release, all
> the
> > steps will be transparent for community, but it will require uploading at
> > least one private gpg certificate on the server. This is the high
> security
> > risk and I'm mentioning this option only for the sake of completeness.
> >
> > 3. Building of the project can be performed on the public continuous
> > integration server and then artifacts can be downloaded on the local
> > machine and signed and deployed to the staging repository from that local
> > machine by running maven commands. No sharing of any credentials and
> > certificates will be needed, environment will be the same for each
> release,
> > all the steps will be transparent for community, artifacts created on the
> > CI server can be verified by check-sums after uploading to the
> repository.
> >
> > Please, let me know if you have any suggestion or any questions about
> > anything related.
>

[Alexey Dmitriev]

+1
option #3 looks good

On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <[hidden email]> wrote:

> Hello Igniters, I'd like to know which release option is preferred for the
> community. I've done some research and some tests and I think the most
> transparent way is option #3.
>
> On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <[hidden email]>
> wrote:
>
> > There's also #4:
> >  - providing an official environment, comprised of the toolchain,
> > compilers, libs, etc,. The same environment (read "a container") could
> > be used by an individual developer, RM, and/or in CI system for
> > builds, tests, etc. And then you can have #3 pretty much for free!
> >
> > We are doing this in Bigtop for a much more complex environment, set
> > of components and supported OS. I am sure it would be easy to do in
> > Ignite.
> > --
> >   With regards,
> > Konstantin (Cos) Boudnik
> > 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> >
> > Disclaimer: Opinions expressed in this email are those of the author,
> > and do not necessarily represent the views of any company the author
> > might be affiliated with at the moment of writing.
> >
> >
> > On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <[hidden email]>
> > wrote:
> > > Hi,
> > >
> > > I'd like to start a discussion about Apache Ignite release procedure.
> > >
> > > I'm working on ticket Ignite-5249 "The release build procedure should
> be
> > > placed on the CI/CD server and available to run for the release
> > engineer."
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-5249
> > >
> > > Currently we have three options for release:
> > >
> > > 1. Release engineer can do all the necessary steps on his local
> machine.
> > It
> > > will require installing tons of soft like maven, doxigen, candle and so
> > on.
> > > Also building .net part of the project will require access to Windows
> OS.
> > > Build steps will not be transparent for community. Environment will not
> > be
> > > the same for each release which can lead to the compatibility issues.
> > >
> > > 2. All the steps (including signing) can be done on the public
> continuous
> > > integration server. Environment will be the same for each release, all
> > the
> > > steps will be transparent for community, but it will require uploading
> at
> > > least one private gpg certificate on the server. This is the high
> > security
> > > risk and I'm mentioning this option only for the sake of completeness.
> > >
> > > 3. Building of the project can be performed on the public continuous
> > > integration server and then artifacts can be downloaded on the local
> > > machine and signed and deployed to the staging repository from that
> local
> > > machine by running maven commands. No sharing of any credentials and
> > > certificates will be needed, environment will be the same for each
> > release,
> > > all the steps will be transparent for community, artifacts created on
> the
> > > CI server can be verified by check-sums after uploading to the
> > repository.
> > >
> > > Please, let me know if you have any suggestion or any questions about
> > > anything related.
> >
>

--
Alexey Dmitriev, VP Engineering
*GridGain Systems*
www.gridgain.com

[dmagda]

Honestly, #3 and #4 look pretty similar for me. Considering that all the environment is already set for #3 I would go for it.

—
Denis

> On Aug 23, 2017, at 8:37 AM, Alexey Dmitriev <[hidden email]> wrote:
>
> +1
> option #3 looks good
>
> On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <[hidden email]> wrote:
>
>> Hello Igniters, I'd like to know which release option is preferred for the
>> community. I've done some research and some tests and I think the most
>> transparent way is option #3.
>>
>> On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <[hidden email]>
>> wrote:
>>
>>> There's also #4:
>>> - providing an official environment, comprised of the toolchain,
>>> compilers, libs, etc,. The same environment (read "a container") could
>>> be used by an individual developer, RM, and/or in CI system for
>>> builds, tests, etc. And then you can have #3 pretty much for free!
>>>
>>> We are doing this in Bigtop for a much more complex environment, set
>>> of components and supported OS. I am sure it would be easy to do in
>>> Ignite.
>>> --
>>>  With regards,
>>> Konstantin (Cos) Boudnik
>>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
>>>
>>> Disclaimer: Opinions expressed in this email are those of the author,
>>> and do not necessarily represent the views of any company the author
>>> might be affiliated with at the moment of writing.
>>>
>>>
>>> On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <[hidden email]>
>>> wrote:
>>>> Hi,
>>>>
>>>> I'd like to start a discussion about Apache Ignite release procedure.
>>>>
>>>> I'm working on ticket Ignite-5249 "The release build procedure should
>> be
>>>> placed on the CI/CD server and available to run for the release
>>> engineer."
>>>>
>>>> https://issues.apache.org/jira/browse/IGNITE-5249
>>>>
>>>> Currently we have three options for release:
>>>>
>>>> 1. Release engineer can do all the necessary steps on his local
>> machine.
>>> It
>>>> will require installing tons of soft like maven, doxigen, candle and so
>>> on.
>>>> Also building .net part of the project will require access to Windows
>> OS.
>>>> Build steps will not be transparent for community. Environment will not
>>> be
>>>> the same for each release which can lead to the compatibility issues.
>>>>
>>>> 2. All the steps (including signing) can be done on the public
>> continuous
>>>> integration server. Environment will be the same for each release, all
>>> the
>>>> steps will be transparent for community, but it will require uploading
>> at
>>>> least one private gpg certificate on the server. This is the high
>>> security
>>>> risk and I'm mentioning this option only for the sake of completeness.
>>>>
>>>> 3. Building of the project can be performed on the public continuous
>>>> integration server and then artifacts can be downloaded on the local
>>>> machine and signed and deployed to the staging repository from that
>> local
>>>> machine by running maven commands. No sharing of any credentials and
>>>> certificates will be needed, environment will be the same for each
>>> release,
>>>> all the steps will be transparent for community, artifacts created on
>> the
>>>> CI server can be verified by check-sums after uploading to the
>>> repository.
>>>>
>>>> Please, let me know if you have any suggestion or any questions about
>>>> anything related.
>>>
>>
>
>
>
> --
> Alexey Dmitriev, VP Engineering
> *GridGain Systems*
> www.gridgain.com

[Sergey Kozlov]

Not sure we can go with #4: the binary release requires compilation under
Windows and Linux (for platform artifacts). It means at least two
containers and looks like overcomplicated. Also  windows requires a license
even it start somewhere in a virtual environment.

my vote for #3 as most simple solution

On Wed, Aug 23, 2017 at 9:22 PM, Denis Magda <[hidden email]> wrote:

> Honestly, #3 and #4 look pretty similar for me. Considering that all the
> environment is already set for #3 I would go for it.
>
> —
> Denis
>
> > On Aug 23, 2017, at 8:37 AM, Alexey Dmitriev <[hidden email]>
> wrote:
> >
> > +1
> > option #3 looks good
> >
> > On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <[hidden email]>
> wrote:
> >
> >> Hello Igniters, I'd like to know which release option is preferred for
> the
> >> community. I've done some research and some tests and I think the most
> >> transparent way is option #3.
> >>
> >> On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <[hidden email]>
> >> wrote:
> >>
> >>> There's also #4:
> >>> - providing an official environment, comprised of the toolchain,
> >>> compilers, libs, etc,. The same environment (read "a container") could
> >>> be used by an individual developer, RM, and/or in CI system for
> >>> builds, tests, etc. And then you can have #3 pretty much for free!
> >>>
> >>> We are doing this in Bigtop for a much more complex environment, set
> >>> of components and supported OS. I am sure it would be easy to do in
> >>> Ignite.
> >>> --
> >>>  With regards,
> >>> Konstantin (Cos) Boudnik
> >>> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> >>>
> >>> Disclaimer: Opinions expressed in this email are those of the author,
> >>> and do not necessarily represent the views of any company the author
> >>> might be affiliated with at the moment of writing.
> >>>
> >>>
> >>> On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <[hidden email]>
> >>> wrote:
> >>>> Hi,
> >>>>
> >>>> I'd like to start a discussion about Apache Ignite release procedure.
> >>>>
> >>>> I'm working on ticket Ignite-5249 "The release build procedure should
> >> be
> >>>> placed on the CI/CD server and available to run for the release
> >>> engineer."
> >>>>
> >>>> https://issues.apache.org/jira/browse/IGNITE-5249
> >>>>
> >>>> Currently we have three options for release:
> >>>>
> >>>> 1. Release engineer can do all the necessary steps on his local
> >> machine.
> >>> It
> >>>> will require installing tons of soft like maven, doxigen, candle and
> so
> >>> on.
> >>>> Also building .net part of the project will require access to Windows
> >> OS.
> >>>> Build steps will not be transparent for community. Environment will
> not
> >>> be
> >>>> the same for each release which can lead to the compatibility issues.
> >>>>
> >>>> 2. All the steps (including signing) can be done on the public
> >> continuous
> >>>> integration server. Environment will be the same for each release, all
> >>> the
> >>>> steps will be transparent for community, but it will require uploading
> >> at
> >>>> least one private gpg certificate on the server. This is the high
> >>> security
> >>>> risk and I'm mentioning this option only for the sake of completeness.
> >>>>
> >>>> 3. Building of the project can be performed on the public continuous
> >>>> integration server and then artifacts can be downloaded on the local
> >>>> machine and signed and deployed to the staging repository from that
> >> local
> >>>> machine by running maven commands. No sharing of any credentials and
> >>>> certificates will be needed, environment will be the same for each
> >>> release,
> >>>> all the steps will be transparent for community, artifacts created on
> >> the
> >>>> CI server can be verified by check-sums after uploading to the
> >>> repository.
> >>>>
> >>>> Please, let me know if you have any suggestion or any questions about
> >>>> anything related.
> >>>
> >>
> >
> >
> >
> > --
> > Alexey Dmitriev, VP Engineering
> > *GridGain Systems*
> > www.gridgain.com
>
>

--
Sergey Kozlov
GridGain Systems
www.gridgain.com